Test Case Writing: Best Practices & Template

When starting the journey of testing out your software to improve quality and customer satisfaction, companies and stakeholders might have a lot of questions and require help answering them. Perhaps the first thing that comes to mind is not necessarily how to write test cases, but rather “What are they?”, “Why are they important?”, and “When should we do this?”.

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?

1. To have better test coverage or test case coverage.
2. To have better consistency in test execution or test case execution.
3. To avoid training new testers on the product or requirement.
4. To avoid missing scenarios and defects.
5. Test cases show developers and customers that we have tested the application for all possible scenarios.
6. Test cases are the basis for automation.
7. Test cases can help to do testing in an organized way.

When Do We Write Test Cases?

1. When a customer or client gives a new requirement.
2. When a customer wants to add a new feature.
3. When a customer wants to modify existing features.
4. While testing, if the tester comes up with new, creative scenarios.
5. 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:

BODY of Test Case Template:

FOOTER of Test Case Template:

Test Case name:

The test case name should be unique for every test case in the following format:

Projectname_Modulename_scenario 

Let us take an example of the Facebook Photo upload feature; we need to name the test case:

Facebook_uploadphoto_checkphotoisdisplayed

Release name:

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 on the release name.

Requirement number:

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.

Module name:

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.

Pre-condition:

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:

1. Software is installed correctly or not
2. Internet connection
3. Browser’s settings options
4. Roles and Permissions
5. Username and password

Test Data:

The tester will create test Data before executing the test case. Test data can be created manually or with automation tools.

Postcondition:

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:

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:

1. Critical
2. Major
3. Minor

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.

Brief Description:

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.

Step Number:

The tester will write a unique step number for every individual step.

Action/ Description:

An action consists of all the navigation steps.

Input:

Note whatever data the tester enters into the application in the input field. Example: URL, Username, password, etc.

Expected result:

The tester will write the expected result by looking into the requirement before executing test cases.

Actual result:

The tester will write the actual result after the test case execution by looking into the result or outputs.

Status:

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.

Comments:

If the status is failed, then the tester should write the comment by giving the reason why the status failed.

Author:

The tester who writes the test case is the author.

Reviewed by:

The tester who reviews the test case.

Approved by:

Any person who approves test cases.

Approval date:

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 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.

Happy Testing!