| Test Case ID | Test Case Name | Description | Pre Conditions | Execution Steps | Expected Result | Actual result | Status | Comments |
| STT001 | Feature_name OR Requirement number/Name as per SRS or client documents. | Details about that mentioned feature. | It can be describe in multiple points. | Use case to perform | As per requirements. | Current result | Fail/Pass | //Coments |
Let us look at each parameters should include good test cases:
A. Test Case ID
This field is defined by what type of system we are testing. Standard rules are as follows:
- If we are making a test case for a general application which doesn’t belong to any specific module then ID would start as STT001.
- If we are making test cases for a module specific system then ID would start from STT001.
- If the test case has more than one expected result then we make it as version number wise. E.g. STT001.1, STT001.2 etc. All these test cases are sub part of STT001.
In this way we can maintain all the test case IDs and if in future any requirement gets changed or added then we can just add new test cases following the standard rules without changing the test case IDs of previously written test cases.
B. Test Case Name
This field can contain
- Name of the feature you are testing
- Requirement number from the specifications
- Name of a particular Button or input box
- Requirement name as classified in client’s document
The main advantage of maintaining this field is, if a requirement gets changed in future then we can easily estimate how many test cases that change will affect and we change/remove the corresponding test cases accordingly.
C. Description
This field has the summary of what each test case is going to do, it explains what attribute is under test and under what condition e.g. If a text box is under provigil online test, which allows only number and alphabets then description can be written as “Random special characters (@,#,$,^,*) are entered”, if we want to test a negative scenario.
D. Pre-Conditions
when the system needs to be in a particular base state for the function to be tested, these pre-conditions should be defined clearly.
Pre-conditions could be:
- A certain page that a user needs to be on
- A certain data that should be in the system
- A certain action to be performed before “execution steps” can be executed on that particular system
Pre-conditions should be satisfied before the test case execution starts.
E. Execution steps
These are the steps to be performed on the system under test to get the desired results. Steps must be defined clearly and must be accurate. They are written and executed number wise.
F. Expected Results
These are the desired outcomes from the execution steps performed. Expected results should be clearly defined for each step. It specifies what the specification or client expects from that particular action.
G. Actual result
This field has the actual outcomes after the execution steps were performed on the system under test. If the results match with the expected ones then we can just write “As expected”, otherwise we need to mention the exact result observed.
H. Status
This field can have following values based on the actual result we got, they are:
- “Passed” -The expected and actual results match
- “Failed”- The actual result and expected result do not match
- “Not tested”- The test case has not been executed
- “Not Applicable The test case does not apply to the feature any more since the requirement changed or modified
- “Cannot be tested”- This may be because the precondition is not met. There could be a defect in one of the steps leading up to the function under test.
I. Comments
This column is for additional information. So for e.g. if status is set to “cannot be tested” then tester can give the reason in this column.
