Creating a Template For Your Test Cases

Creating a template for your test cases is one of the smartest decisions you could take to ramp up your productivity and simplify the process of writing new test cases.

The key benefit of using a template is that it provides a consistent and logical format that can be used across test cases, making it easier for everyone on your team to understand test cases and ensuring that essential information isn’t inadvertently left out.

But first, what’s a template? Basically, it’s an generic outline for your test cases and it normally consists of a number of important headings under which you write the relevant information for that section.

In this article, we share some key headings the ReQtest team finds to be the most of useful to keep in mind when writing test cases. You can easily use these in Word and Excel files if you still write your test cases the old-school way (Though we really think you shouldn’t!).

Alternatively, you can set up an automated template with these headings using a test management tool such as ReQtest that helps you make writing test cases a cinch.

 

A typical test case template

The example below shows you what a generic template looks like. As you can see it’s a pretty straightforward affair consisting of five common fields that can be used with practically every test case you could think.

ID	14
Title	Add customer
Pre-conditions	Sign in with sales authorisation.
Test steps	Select the client module. Enter customer information. Click “Add”.
Expected results	A message appears in the program’s status bar. The message reads “New customer added”.

Naturally, there are many more headings you could use for your test cases and the number and type of headings used depends on the complexity of the project, it’s nature and your work process.

The five headings in our example are the ones you’ll probably use all the time, so they make a good starting point for your first template. You can always add on more headings later and with tools like ReQtest doing so is a just a matter of couple of clicks.

Let’s take a closer look at each heading we’ve used.

•  ID – This field makes it easier to identify and cross-reference test cases by giving each one a unique identifier that can be used as a shorthand to refer to a specific test case.

The most common method of identifying test cases in a project is by numbering them in the order they’re written (1, 2, 3, etc.), however you could use prefixes and additional numbers to identify the system a the test cases belongs to (1.1, 1.2, 1.3, 2.1, etc.).

Test management tools like ReQtest make it easier to identify test cases since they automatically assign a unique identifier to each test case created.

• Title – The title provides a concise and accurate description of the outcome of a test case, letting you know in an instant what a particular test case is all about when you’re scanning through the finished list for later reference.

• Pre-conditions – The pre-conditions heading tells you what activities a test has to perform before they can start executing the steps listed in the test case. In some cases the pre-conditions field may not be necessary so you should consider it as an optional heading.

Note: If you have several cases with the same pre-conditions, we’d suggest you move the pre-conditions to a test run or test specification and thus avoid writing the same instructions repeatedly.

• Test steps – The test steps heading contains a numbered list of the steps required to perform the test case. Ideally, each test case shouldn’t include more than eight steps.

 

Other headings you can use in a test case template

• Expected results – This heading describes the expected outcome of a successful test case and should be worded in such a way that doesn’t give rise to ambiguity as regards to what constitutes a successful or failed test.

• Post-conditions – The post-conditions field lets the tester know how to restore the system to its original state and thus conduct the same test again or carry on with other tests.

• Test data – In the test data heading you can place any data that will be used by the system to execute the steps listed in the test case. This can also be a link pointing to a text file or spreadsheet containing the test data.

• Priority – Indicates how urgent and/or important a test case is using priority scales like high/medium/low or MoSCoW.

• Requirements reference – In this section testers can cross-reference the test case with the requirements it is addressing, thus improving traceability. With a test management tool like ReQtest it’s easy to create and maintain references to requirements, test cases, and defect reports.

• Version – Lists the test case version number, allowing testers to quickly realise when they’re using an outdated version of a 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 shouldn’t be included in a test case template

The headings listed below do not belong on a test case template, but are usually handled by a test management tool or inputted manually documented in a test log.

• Actual results (outcome) – Either “Approved” or the ID number of the defect report.

• Name/Signature – Details about which tester conducted the test case.

• Date – The date on the test case was performed.

 

Writing a test case template

A test case template will make it easier to write good test cases, however the exact way how you should structure your template depends largely on the testing techniques you use when carrying out test cases.

It’s a good idea to let colleagues review your template and tweak it based on their suggestions until the finished product is one that enjoys team-wide consensus.

Ultimately, the templates you use will be as good as your test cases. Developing test cases in pairs is an effective way to improve the quality of your test cases and we also suggest you check out this other article we’ve written which tells you how to write effective test cases.