5 Tips to Write Foolproof Test Cases Every Time

Test cases are often written so simply that someone could walk in off the street and use them to test your system.

But honestly – how often do you literally bring folks in off the street to run your test cases?

When you actually do bring in an outsider to test your application, it’s usually because you want to know specifically how a complete novice would spontaneously use your application.

But even then, the spontaneity would be completely lost has soon as you jam your step-by-step test case into your off-the- street tester’s hands.

There are many different ways to write test cases. This article gives you five tips which you can use and adapt to your needs in order to create and manage test cases more efficiently.

#1 – There’s no need to specify the expected result when it’s obvious

When testers report defects based on the test case, they should indicate which test step failed, in order to make troubleshooting easier.

However, when you write a test case, you don’t need to specify the expected result for each test step if the result is obvious.

So what should you include in a test case?

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.

#2 – Consider breaking up a long test case into several smaller ones

If your test case has too many test steps you might want to think about breaking up the test case into a set of smaller ones.

If the test case contains a long list of test steps, and an error occurs somewhere, the developer will have to backtrack and repeat all the test steps, which he or she might not do, either by accident, or because he/she is just being lazy.

#3 – If there are only few test steps write a checklist instead

Having too many test steps can be a disadvantage for the tester, too. The tester may have to repeat each one of the test steps to ensure that the bug is fixed. You should aim to have between 3 to 8 test steps in a test case.

If you have only a few test steps, you should consider making a checklist instead; keeping track of a lot of small test cases might not be worthwhile.

Checklists are similar to test cases but they are much more simplified. It’s typical for a test case to contain lots of fields and contents such as the subsystem or priority, and additionally, you’ll usually have several steps in your test case, each step to be validated.

Checklists are different; they consist of steps just as test cases but don’t have any of the fields and content such as type of test case or subsystem, which we find in a test case. Typically, checklists don’t belong to a specific subsystem or else are more of a general instruction to the tester.

If you have only a few test steps, consider making a checklist instead.

Furthermore, when working with checklists or test cases remember you can filter out test cases by a number of parameters, for example, the subsystem concerned, auditor, created by, priority, etc.

A pro of checklists is that they are very easy to create and you can write them rapidly as they are not as complex as a test case, but the downside is that you do not get as much follow up as you can from test cases.

Check out tutorial, in which  you know how to create a checklist in ReQtest.

#4 – Use agile software to create and manage test cases instead of writing them in Word

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 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, it will help you improve the way you create and manage test cases. In fact, if you’re still writing test cases in Word, we highly recommend you look into real testing tools instead, such as ReQtest.

A test management tool will help you improve the way you create and manage test cases.

#5 – Group similar test cases into a test run and put the pre-conditions at the beginning

Sometimes the test case template contains a field for pre-conditions. In practice only a few of the test cases need them, so the field is often left empty. With a test management tool you can easily customise the look of your forms and create templates that save you time and effort when writing test cases.

Test cases are often grouped in test runs. A test run is simply a collection of test cases that testers should perform in a particular order. Rather that inserting pre-conditions into each test case, you could put them in the beginning of a test run instead.

By moving repeated preconditions to a test run or test specification instead you’ll avoid writing the same instructions several times.

Concluding remarks

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

I’ll share plenty of interesting and useful testing techniques with you in the future. In the meantime, following these five tips will surely help you write fool-proof test cases.

Recap

1. When you write a test case, you don’t need to specify the expected result for each test step if the result is obvious.

2. If your test case has too many test steps you might want to think about breaking up the test case into a set of smaller ones.

3. If you have only a few test steps, consider making a checklist instead.

4. A test management tool will help you improve the way you create and manage test cases.

5. Rather that inserting pre-conditions into each test case, put them in the beginning of a test run instead.

What’s Next

The simple test case template

The picture below shows a fairly common test case template structure which illustrates a number of important points raised in this article.

As you can see, this test case which was created in ReQtest is rather simple. There are multiple test steps, some of which have an expected result and some of which do not.

Let us know if you have more tips you’d like to share with fellow testers in the comment section.

Remember to share this article with your colleagues if you think that they could use some tips to write better test cases too!