How to Develop a Test Case Template

If you have a good template for test cases, it will become much easier for your team to write test cases which can be understood and used by everyone. In this post you will learn how to develop test case template for test cases.

In essence, a template is a collection of key headings, and this article will give you some advice about which of these are the most important ones.

You can use the headings mentioned below in Word and Excel files if you still use those applications for testing activities, although you know you shouldn’t do that.

Alternatively, if you use a test management tool such as ReQtest, this article will help you improve your test case template.

What should a test case template look like?

Here’s an example of an already filled out test case template.

The example above contains the main headings that a test case needs for most cases. However, there are many more headings which could be useful and you can find these below.

You probably won’t need all these fields in every situation, so start with a few fields and add others to the test case template later as the need arises. You can get started initially using just the fields in the example above.

ID (identification)

The ID field makes it easier to cross-reference test cases, both with one another and from defect reports. The ID obviously has to be unique, i.e.: there can never be more than one test case with the same ID number.

The most common approach is to use a continuous sequence, so that test cases are identified as 1, 2, 3, and so on. You don’t have to prefix the ID with a code (like UM01 for the first test case in the user module), but some people do use prefixes to make it easier to see which part of the system a test case belongs to.

If you have access to a good test management tool, you won’t need to use prefixes, since the tool will automatically assign an ID number to each test case.

Some people put the test case number in the test case title, to make it easier to sort the test cases for example, however, it’s better to keep ID as a custom field and use the tool’s sorting functions, because it can get pretty difficult to keep the numbering consistent and sequential as the number of test cases grows.

Title

The title should provide a concise, revealing description of the test case, such as “Add customer”.

The title is important because it’s often the first or only thing you see when you are scanning a list of test cases for example.

You should gather the test cases in a test management tool, or in a document (often referred to as the test specification). Clear titles are key to helping testers quickly find the right test cases.

Pre-conditions

In the pre-conditions heading, you should explain any activities that the tester needs to carry out before he/she can execute the test steps. They may need to add test data, perform other functions, execute other test cases, or navigate to a particular part of the system.

The pre-conditions field isn’t relevant to every test case, so you may want to include it in the test case template but not make it mandatory. If you don’t describe pre-conditions accurately, the testers may not be able to conduct the test. If you have several cases that all have the same pre-conditions, you should move the pre-conditions to a test run or test specification instead, to avoid writing the same instructions repeatedly.

Test Steps

The Test Steps section gives the tester a numbered list of the steps to perform in the system, which makes it easier to understand the test case.

It is recommended to have 3-8 test steps per test case, although sometimes you might need a smaller number of test cases with a larger number of test steps. Too many steps make it difficult for developers and testers to reproduce the steps in the event that a bug report is filed against the test case.

Expected Results

The tester needs to know the expected result in order to assess whether the test case is successful. The optimal level of detail in this field varies from situation to situation.

One of the most common problems is the wording of the expected outcome, especially if the description is so vague that it’s not possible to tell whether the test case has succeeded. Ensure that the wording is clear and concise.

Post-conditions

The person executing the test case needs the Post-conditions field to know how to restore the system to its original state and not interfere with subsequent testing. For example, if the test case adds a customer, the tester might need to remove that customer. In many systems it is not possible to add two customers containing the same data. If you do not remove the customer, it is not possible to execute the test case again. Removing the newly-added customer after  executing the test steps is a typical post-condition.

If the test case involves deleting a login account, you may need to recreate it. If the same post-conditions is used in several test cases it’s more efficient to move it to a test run or test specification instead of adding it to each test case.

Test Data

You can enter test data directly in the test data field, or refer to a separate file that contains test data for one or more test cases. For example, you can store test data in a text file or in an Excel spreadsheet.

By using a test data file, you avoid hard coding test data in the test case, so a single test case can be used to test several sets of test data.

Priority

Priority indicates how urgent and/or important a test case is. All test cases can’t be of equally high priority, and priority can help determine the order in which you run them.

Priority is also useful when you run up against time constraints during test execution – you can just run the highest priority test cases, for example.

You can use a simple scale like high/medium/low, or the MoSCoW scale (Must, Should, Could, or Won’t be executed).

Priority should naturally be based on requirements, but if the requirements aren’t already prioritized, the test group should propose a prioritization that the client reviews and approves.

Requirements Reference

This section refers to the requirement that the test case is testing (for example “14” if the test case tests requirement ID 14).

By using specific references to particular requirements, you can create a traceability matrix that, among other things, can show you whether you have test cases that cover all requirements.

With a test management tool it’s easy to create and maintain references to requirements, test cases, and defect reports.

Version

The field for Version contains the test case version number (not the system version number!). It’s used because the conditions for the test case may change when the test case changes.

A defect might not be caused by a problem in the system, but by the tester using an outdated version of the test case.

Author

The (first and last) name of the person who wrote the test case. People reading the test case may want to contact the author to ask questions or get clarification.

Subsystem/functional area

The part(s) of the system related to the test case. Sometimes also called program or component.

Fields which are not included in the test case template

The following fields aren’t normally included in the test case since they are typically handled by a test management tool or manually documented in a test log if a tool is not used.

The reason this information doesn’t belong in a test case is that test cases contain static information which doesn’t change. The result of the test run is dynamic information that changes every time the test case is run.

Mixing static and dynamic information is a huge challenge, especially if you use Word and Excel for test and requirements management. However, if you’re using a test management tool such as ReQtest, it will probably be able to integrate static and dynamic information effectively.

Actual results (outcome)

Either “Approved” or the ID number of the defect report.

Name or signature

Details about which tester conducted the test case.

Date

Date the test case was performed.

In conclusion

A good test case template will make it easier for you to write good test cases, but of course, there’s no guarantee that your test cases will be any good just because you used a good template.

You need to base your test cases on a variety of testing techniques, and have them reviewed by qualified team members. Developing test cases in pairs is one effective way to improve quality although many others exist. Meanwhile, you can also learn how to write effective test cases.