Header of Test Case
:
We
always fill the body of the test case first before filling up the header of the
test case.
1) Test case name :
2) Requirement number
:
32.3
3) Module name :
Amount Transfer
4) Pre-condition :
Test Engineer should
know the balance of user A and user B
Pre-condition
is a set of actions or settings that you should have done before executing step
number 1.
For ex, If
in an application, we are writing test cases for add users, edit users and
delete users – the precondition would be – see if user A is added before
editing it and deleting it.
5) Test data :
The
data we should have before executing step number 1. Ex – username, password, account number of users.
The
test lead may be give the test data like username or password to test the
application. Or the TE may himself generate the username and password.
6) Severity :
It
can be major, minor or critical.
To
analyse the severity of the test case, it depends on the header.
Choose
the severity according to module. If in the module, there are many features. In
that, even if 1 feature is critical, we claim that test case to be critical. It
depends on the feature for which we are writing the test case.
In
Gmail,
Compose
mail -> Critical
Sent
items -> Minor
Feedback
-> Major
In
a banking application,
Amount
transfer -> Critical
Feedback
-> Minor
We
write severity because we can prioritize our execution based on the severity of
the feature.
7) Test case type :
It
can be functional test cases or integration test cases or system test case or
positive or negative or positive and negative test cases.
8) Brief description :
Following test case
ensures that Amount Transfer feature is not allowing more than balance.
Test
engineer has written test case for a particular feature. If he comes and reads
the test cases for a moment, he will not know for what feature has written it.
So, this gives a brief description of for what feature test cases are written.
Step number is important. If say, step number 10
is failing – we can document defect report and hence prioritize working and
also decide if it’s a critical bug.
Footer of a Test
Case :
1) Author : Who wrote this test case
2) Reviewed by :
3) Approved by :
4) approval date :
Test Case Review :
Test Case Review process / Peer
review process :
Customer
gives requirements – development team start developing the product looking at
the requirements – testing team start writing test cases looking at the
requirements. Test engineer (you) are writing test cases for a particular
module based on the requirements. Once all the possible test cases have been
written for that particular module, you send a mail to the Test lead saying
that you have finished writing test cases for that module. Now, what the test
lead does is – he tells someone in the same testing team to review your test
cases. The reviewer reviews all your test cases looking at your module’s
requirements and in case of any mistakes sends it to you and also to your test
lead. You correct all the mistakes and send a copy of the
While reviewing, the reviewer checks
the following,
1)
Template – he checks whether the template is as
per decided for the project
2)Header :
a)
Checks whether all
the attributes are captured or not
b)
Checks whether all
the attributes in the header are filled or not
c)
Checks whether all
the attributes in the header are relevant or not
3) Body :
a)
Check whether all
possible scenarios are covered or not
b)
Check whether the
flow of test case is good or not
c)
Check whether the
test case design techniques are applied or not
d)
The test cases
should be organized in such a way that it should less time to execute
e)
Check whether the
test case is simple to understand and execute
