What is a test case?
A test case is a step-by-step procedure that tests a given feature for all possible scenarios related to a particular requirement. Test cases are brief and detailed, consisting of all the navigation steps within the header, body, and footer.
Why do we write test cases?
- To have better test coverage or test case coverage.
- To have better consistency in test execution or test case execution.
- To avoid training new testers on the product or requirement.
- To avoid missing scenarios and defects.
- Test cases show developers and customers that we have tested the application for all possible scenarios.
- Test cases are the basis for automation.
- Test cases can help to do testing in an organized way.
When do we write test cases?
- When a customer or client gives a new requirement.
- When a customer wants to add a new feature.
- When a customer wants to modify existing features.
- While testing, if the tester comes up with new, creative scenarios.
- While testing software, if you find any defect and if the test case is not present, we should update the test case for the defect.
Now, let’s examine the Test Case Template.
While there is no standard test case template, we can prepare a flexible test case template in a test case management tool or MS Word or MS Excel.
HEADER of Test Case Template:
|Test Case name / Test Case ID:|
|Test case type:|
|Test case Execution hours:|
BODY of Test Case Template:
|Step No||Action/ Description||Input||Expected result||Actual result||Status||Comments|
FOOTER of Test Case Template:
Test Case name:
The test case name should be unique for every test case in the following format:
Let us take an example of the Facebook Photo upload feature; we need to name the test case as:
The tester should write the release name for every individual test case in the test case template.
The project team, testing team, and development team will decide the release name.
A business analyst converts customer requirement specifications to system requirement specifications, then writes every module and component’s requirement number. The tester should copy and paste the requirement number into the test case template for every individual test case.
The business analyst will list all modules in the SRS. Testers should copy and paste module names from the SRS to the test case template for every individual test case.
The settings or actions that should be/will be done before executing the test case. As a part of
Pre-condition, we will check the following settings:
- Software is installed correctly or not
- Internet connection
- Browser’s settings options
- Roles and Permissions
- Username and password
The tester will create test Data before executing the test case. Test data can be created manually or with automation tools.
In postconditions, we must state the expected result. Post-condition of one test case can be used as a pre-condition for other test cases.
Severity measures the impact of the bug on a customer’s business. Testers will assign a level of severity to every individual test case based on how critical and important the feature is to the customer’s business. Test Cases will be executed based on severity. There are three levels of severity:
Test Case type:
The tester will write the test case type for every individual test case stating whether the test case type is functional, integration, system, ad hoc, etc.
This section describes the complete test case and its behavior.
Test Case Execution hours:
The tester will note the test case execution hours after executing test cases. Test Case execution hours = Time is taken to write test case + Time taken to execute the test case.
The tester will write a unique step number for every individual step.
An action consists of all the navigation steps.
Note whatever data the tester enters into the application in the input field. Example: URL, Username, password, etc.
The tester will write the expected result by looking into the requirement before executing test cases.
The tester will write the actual result after test case execution by looking into the result or outputs.
If the actual result matches the expected result, then the status is “pass”. If not, the status fails. If the test case is not executed, then we mark the status as not executed.
If the status is failed, then the tester should write the comment by giving the reason why the status failed.
The tester who writes the test case is the author.
The tester who reviews the test case.
Any person who approves test cases.
The date of test case approval.
Again, there is no standard template for test cases. Instead, use the above information as a guide to creating a template that works for you.
Here I am attaching my template, which is very simple and easier to understand. Moreover, it can be modified based on the requirement and level of testing and other parameters.
To make the above statement true, we need to follow the test case process is a very important one. The following diagram narrates some good characteristics of test cases:
Below are my additional inputs for writing effective test cases. By following these tips, test case and test case coverage can be improved:
- Always start to write test cases with a positive flow; writing randomly is not recommended.
- Start writing the test cases from the navigation steps.
- In the expected result, use the words “should be” or “must be”.
- Hard coding is not recommended; write generic test cases initially.
- Writing the test cases in simple language is highly required.
- Test cases should be as simple that a new tester should execute them without.
- Other testers should review test cases to improve the test case suite.
- Apply test case design techniques when writing test cases.
- Test cases should be written in a test case template.
Thanks for reading, I hope the article helped you to understand test cases and how important they are in your projects.