WRITING GOOD TEST CASES

1. As far as possible, write test cases in such a way that you test only one thing at a time. Do not overlap or complicate tes
2. Attempt to make your test cases ‘atomic’.
3. Ensure that all positive scenarios and negative scenarios are covered.
4. Language: Write in simple and easy to understand language.
5. Use active voice: Do this, do that.
6. Use exact and consistent names (of forms, fields, etc).

Characteristics of a good test case:

1. Accurate: Exacts the purpose.
2. Economical: No unnecessary steps or words.
3. Traceable: Capable of being traced to requirements.
4. Repeatable: Can be used to perform the test over and over.
5. Reusable: Can be reused if necessary.

Tips for Writing Effective Test Cases for Any Application

1 Test Case Naming Conventions
2 Description
3 Assumptions and Preconditions
4 Input Test Data

5 Cover all Verification Points in Test Design Steps

6 Attach the Relevant Artefacts
7 Expected Result

8 Legible & Easily Understandable by Others

9 Review
10 Reusable

11 Maintenance & Updates

12 Post Conditions
ay that you test only one thing at a time. Do not overlap or complicate test cases.

scenarios are covered.

tand language.

ds, etc).

ments.
ver and over.

Application
Name the Test Cases so to represent the module name or functional area you are going to verify in that test case.
Enter as much information as possible in Description!
Make sure to add as much information as possible for any conditions to be met before running the test case.
To make your life easy as a tester (and your fellow-testers!), wherever applicable, you can give Test Data to be used for th
This saves a lot of time in the long run as you won’t have to hunt a new test data every time you need to execute the test.
The Test Design Steps should not only cover the functional flow but also each verification point which should be tested!
wherever possible you should attach the relevant artefacts to your test case.
Each test design step should clearly mention what you expect as outcome of that verification step.
So, while writing test cases, mention in detail what page/screen you expect to appear after the test and, any changes you
You can also attach screenshots or specification documents to the relevant step and mention that the system should work
You should write Test Cases that:
• Are Simple and easily understandable by everyone (including YOU!)
• Are to-the-point! You don’t have to be writing essays! (wherever you feel any Test Case is going beyond a certain amoun
• Still have enough coverage

Review can be done by peer testers (termed as ‘Peer Review’), BA, developers, product owners or any relevant stakehold
You should write test cases keeping in mind that they could be re-used in the future for some other project/teams.
On that note, before writing a new Test Case for your project/module, always try and find out if there are Test Cases writt
Always consider updating the existing Test Cases (if any) before you start writing New Test Cases!
Post-conditions basically specify the various things that need to be verified after the Test has been carried out.
In addition, post-conditions are also used to give guiding instruction to restore the system to its original state for it not to
Serial Test Suite ID Test Case Test Case Related Prerequisites Test Test Data
Numbers ID Summary Requirement Procedur
e
Expected Actual Status Remarks Created Date of Executed Date of
Result Result By Creation By Execution
Test
Environment
Column Serial Test Suite Test Case Test Case Related Prerequisites
Names Numbers ID ID Summary Requirement

Definitions/ Test case The ID of The ID of The summary / The ID of the Any prerequisites or
Explanation Count the test suite the test objective of the requirement this preconditions that
to which this case. test case. test case must be fulfilled
test case relates/traces to. prior to executing
belongs. the test.

Example 1 TS001 TC001 To verify that RS001 1.User is

of a clicking the authorized.
Test Case Generate Coin
button generates 2.Coin balance is
coins. available.
Test Procedure Test Data Expected Result Actual Result

Step-by-step procedure to The test data, or The expected result of the The actual result of
execute the test. links to the test test. the test; to be filled
data, that are to be after executing the
used while test.
conducting the test.

1. Select the coin 1. Denominations: 1. Coin of the specified 1. If the specified

denomination in the 0.05, 0.10, 0.25, denomination should be quantity is valid,
Denomination field. 0.50, 1, 2, 5 produced if the specified the result is as
Quantity is valid (1, 5). expected.
2. Enter the number of 2. Quantities: 0, 1,
coins in the Quantity field. 5, 10, 20 2. A message ‘Please enter a 2. If the specified
3. Click Generate Coin. valid quantity between 1 quantity is invalid,
and 10′ should be displayed nothing happens;
if the specified quantity is the expected
invalid. message is not
displayed
Status Remarks Created By Date of Creation Executed By

Pass or Fail. Any comments on The name of the The date of creation The name of the
the test case or test author of the test of the test case. person who
Other statuses can be execution. case. executed the test.
‘Not Executed’ if
testing is not
performed and
‘Blocked’ if testing is
blocked.

Fail This is a sample John Doe 1/14/2020 Jane Roe

test case.
Date of Execution Test Environment

The date of The environment

execution of the (Hardware/Softwar
test. e/Network) in
which the test was
executed.

2/16/2020 OS: Windows Y

Browser: Chrome
N