test case review checklist

division : project :
item id / name :

general
s# items status
1. test cases follow agreed standard format. (this will be based on the agreed upon format
specified in the sqap or as specified in the standards and guidelines document)
2. the test cases are complete with respect to the specifications document on which they
are based.
3. test data is mentioned explicitly for each test condition.
4. test data for a test condition is complete in the sense that values for all inputs required
for testing that condition are specified.
5. 'expected result' section of each test case is complete and unambiguous.
6. test cases exist for covering error conditions that can occur.
7. all the messages / error codes specified are correct and same as in the specifications
document
8. pre-conditions for executing a test case or a set of test cases are specified.
9. it is specified which test cases are to be executed together (or in a specific order).
10. database object (e.g. tables, columns, stored procs, indexes) names wherever used are
correct and qualified if required.
11. privileges/permissions required for executing a test case and validating the results are
specified.
12. test cases exist for checking performance of various operations e.g. data retrieval and
updation, report printing
13. generic test cases e.g. those related to look and feel, validations, navigation, menu &
toolbar handling, error reporting, etc are identified and documented separately.
14. all queries have been resolved
15. for support and maintenance projects, regression test cases have been created /
identified ensuring that the unchanged functionality is not adversely impacted by the
changed code.

unit test cases - general

s# items status
1. test cases are written as per program specifications
2. test cases have been written to provide planned coverage in testing.
3. if branch or condition coverage, then there are atleast two test cases each covering the
true and false processing of the branch/condition being tested
4. behaviour at boundary values in loops is being tested for
5. test cases have been written to test all error handling code in the program.
6. test cases exist for testing the size of text fields on reports and screens. (test data has
large numeric values, widest characters and long character strings)
7. test cases for testing classes in object oriented systems are as per the state transition
diagram for that class

test cases for screen programs

s# items status
1. test cases exist to check the screen layout against the program specification
2. test cases exist for checking cursor navigation and tab order
3. test cases exist for verifying the type of input in each field e.g. numeric only. (verifying
field validation)
4. a test case is there for validating the behaviour of each control (e.g. push buttons, radio
buttons, list boxes etc.) on the screen
5. test case exists for testing processing to be performed at the time of exit from the
screen.
6. is there a test case for checking the resizing of the window (if applicable).
7. test cases exist for testing processing for all relevant modes.(insert, update, delete etc.)
8. test cases exist for checking for processing when mode changes
9. processing attached to each menu item is being tested for.
10. if same processing is to be performed by different options e.g. menu item, push button
and function key, test cases for testing this synchronization are there.
11. test cases exist for checking program’s response to invalid keys anywhere in the screen.

note: put “ü”, “x”, “-”, “na” in the status column for checked and found ok, checked
and found not ok, not checked and not applicable respectively.
test cases for report programs

s# items status
1. test cases exist to check the report layout (header, detail, summary, margins) against the
program specification
2. test cases exist for checking that page breaks and control breaks do occur at the
conditions specified in program specifications
3. test cases exist for testing control break totals
4. test cases cover processing at page breaks
5. test cases exist for checking that format of data being reported is as per program
specifications
6. test cases exist for checking the correctness of data being reported.

integration test cases

s# items status
1. test cases are written as per functional specifications and the hld document
2. test cases cover the entire functionality of the integrated module.
3. test cases exist for testing the interfaces between the programs in the module (the flow
of data from one program to another)
4. there are test cases for checking the integrity of the global variables or database being
accessed.
5. test cases follow the order of integration (top-down, bottom-up or any-other) as defined
in the hld document.

functional test cases

s# items status
1. test cases are written as per the ra and hld document
2. all the requirements have been translated to test cases
3. test cases exist for checking automatic recovery procedures e.g. checkpoints, data
recovery, restart, reinitialization
4. test cases exist for testing the time taken to repair if recovery requires human
intervention
5. test cases exist for verifying protection mechanisms in the system.
(test cases written to violate built-in security controls e.g. database table locks,
passwords, encryption)
6. test cases have been written for stress testing ( test cases written to test high frequency
of transaction entry or many simultaneous transaction entries etc.), if stress testing is
planned in project plans
7. test cases have been written for testing performance (response time etc.) at high
transaction volumes, if performance is an issue

checked by : date :

note: put “ü”, “x”, “-”, “na” in the status column for checked and found ok, checked
and found not ok, not checked and not applicable respectively.