Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 5

Practical-9

Aim: Designing test cases for your software definition.

Tools Used: Microsoft office word.

Theory / Description:

Test Case :

 A test case is a document which has a set of conditions or actions that are
performed on the software application in order to verify the expected functionality of
the feature.

 After test scripts, test cases are the second most detailed way of documenting
testing work. They describe a specific idea that is to be tested, without detailing the
exact steps to be taken or data to be used. For example, in a test case, you
document something like ‘Test if coupons can be applied on actual price‘. This
doesn’t mention how to apply the coupons or whether there are multiple ways to
apply. It also doesn’t mention if the tester uses a link to apply a discount, or enter a
code, or have a customer service apply it. They give flexibility to the tester to decide
how they want to execute the test.

Benefits of Writing Test Cases :

Page 1
 The key purpose of a test case is to ensure if different features within an application
are working as expected. It helps tester, validate if the software is free of defects and
if it is working as per the expectations of the end users. Other benefits of test cases
include:

 Test cases ensure good test coverage


 Help improve the quality of software,
 Decreases the maintenance and software support costs
 Help verify that the software meets the end user requirements
 Allows the tester to think thoroughly and approach the tests from as
many angles as possible
 Test cases are reusable for the future – anyone can reference them
and execute the test.

 So, these are a few reasons why test cases are extremely useful in software testing.
Test cases are powerful artifacts that work as a good source of truth for how a
system and a particular feature of software works.

Test Case Design Techniques :

 An efficient test case design technique is necessary to improve the quality of the
software testing process. It helps to improve the overall quality and effectiveness of
the released software. The test case design techniques are broadly classified into
three major categories:

Specification-Based(Black Box Techniques): This type of techniques can be used to


design test cases in a systematic format. These use external features of the software such

Page 2
as technical specifications, design, client’s requirements, and more, to derive test cases.
With this type of test case design techniques, testers can develop test cases that save
testing time and allow full test coverage.

Structure-Based(White Box Techniques): These techniques design test cases based on


the internal structure of the software program and code. Developers go into minute
details of the developed code and test them one by one.

Experienced-Based Techniques: These techniques are highly dependent on tester’s


experience to understand the most important areas of the software. They are based on
the skills, knowledge, and expertise of the people involved.

Test Case Guidelines :

1. First understand the requirements & while writing test cases do not assume any
requirements by your own. Raise the question which is not clear in requirement or
requirements are misleading or incomplete, feel free to ask questions to your
business analyst or client. Don’t ask to developers on this.

2. Prior to design the test cases figure out all features of application.

3. Ensure that test case should cover all functionality mention in requirement
document. Use traceability matrix to make sure that all requirements are left
untested.

Page 3
4. Avoid repetition of test cases which help to get exact scope of testing.

5. Generic test cases should be collected & combine together in test suite, which
helps to minimize the effort of writing standard common test cases every time and
can be used over the project life cycle.

6. Testing Priority should be assign to each test case. Select the Test case priority
depending upon how important the test case is for that Feature, component or the
product. In execution queue, high priority test cases should be picked first then
medium and then Low priority test cases.

7. As end users or clients are always interested in reports, so test cases should be
group properly (PhaseI, II wise, Module wise, Sprint wise or User story wise if Agile
methodology), so end user will come to know about Quality of the product based
on test case execution (number of test cases Pass/Failed).

8. While writing test cases Keep in mind all your test cases should be simple and
easy to understand. Don’t write explanations like essays. Be to the point.
9. Keep in mind input data for test cases is very important part in testing, your test
cases should validate range of input data. Also check how system behaves in the
normal & abnormal conditions.

10. While writing test cases you should concentrate on real life scenarios first which
end user going to use day to day life activity and accordingly test cases should be
prepare.

11. Every test case may or may not have defect linked but each defect should have
test case linked.

Test Case Format :

The primary ingredients of a test case are an ID, description, bunch of inputs, few
actionable steps, as well as expected and actual results. Let’s learn what each of them is:


o Test Case Name: A test case should have a name or title that is self-
explanatory.
o Test Case Description: The description should tell the tester what they’re
going to test in brief.

Page 4
o Pre-Conditions: Any assumptions that apply to the test and any
preconditions that must be met prior to the test being executed should be
listed here.
o Test Case Steps: The test steps should include the necessary data and
information on how to execute the test. The steps should be clear and
brief, without leaving out essential facts.

o Test Data: It’s important to select a data set that gives sufficient coverage.
Select a data set that specifies not only the positive scenarios but negative
ones as well.
o Expected Result: The expected results tell the tester what they should
experience as a result of the test steps.
o Actual Result: They specifies how the application actually behaved while
test cases were being executed.
o Comments: Any other useful information such as screenshots that tester
want’s to specify can be included here.

This is the typical format that testers follow when they write a test case. Along with
these parameters, testers can include additional parameters like test case priority, type of
test case, bug id, etc.

Test Case Design Checklist :

Creating an exhaustive checklist having test cases covering all the possible scenarios and
tracking it throughout the project life cycle would help you achieve the optimal software
quality.

Page 5

You might also like