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 corrected test cases both to the test lead and to the reviewer. It need not be that all mistakes pointed out by the reviewer be correct, if you feel they are wrong, then you need to give proper justification as to why your test cases are correct. Once the reviewer says all the test cases are fine, he sends a mail to the test lead saying all the test cases are fine. The test lead then approves your test cases and sends an approval mail to you saying that all the test cases are fine and to start executing the test cases.

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