17 December 2014

The Tester's Guide to Writing More Effective Test Cases

This is a guest post by Ulf Eriksson.

Ulf is one of the founders of ReQtest, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf’s decades of work in development and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy which he has abided to for a number of years in his professional life as well as in private. 

Ulf’s goal is to life easier for everyone involved in testing and requirements management, and he works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest easy and logical for anyone to use, regardless of their technical knowledge or lack thereof. 

The author of a number of white papers and articles, mostly on the world of software testing, Ulf is also slaving over a book, which will be compendium of his experiences in the industry. Ulf lives in Stockholm, Sweden.

There as many ways to write test cases as there are testers out there.

Nevertheless, well-written test cases share certain features in common, namely the fact that they spell out concisely, clearly and completely what needs to be done in order to implement them and what to expect next.

One of the simplest and most effective way to write better test cases is to devise a template of your own that serves as the basic infrastructure of all your test cases. Not only will this speed up the process and increase productivity, but it will also ensure that you never miss out on any critical information in your test cases.

In this article, I present a collage of common test case writing strategies which you can use and modify to suit your style.

10 tips and tricks to improve your test cases

1. A template is a handy and versatile way to structure your test cases which instantly covers all the important points that have to be mentioned. The template shown below is a fairly common structure with multiple test steps, some of which have expected outcome and others which don’t.

2. A typical test case usually has around three to eight test steps. Any less and it’ll probably be too vague to be of any practical use, whereas if it’s too long then there’s an increased risk of missing out on important steps when a developer has to retrace his or her steps after getting an error.

3. If you do have a test case which is very short, consider writing it in the form of a checklist instead as it’s easier to create and will work just as fine.

4. On the other hand, I recommend that testers break down complex cases into a series of smaller ones.

5. When reporting defects based on a test case, testers should remember to indicate which test step failed and led to the defect. This is done in order to make it easier to identify the problem when troubleshooting it later.

6. When writing test cases, you can save some time and trouble by not specifying the outcome of each test step when this is obvious or else included in the step description itself.

7. Few test cases require certain pre-conditions to be met before they can be executed. If using a test management software like ReQtest you can easily hide unused field in order to improve the readability of the test case.

8. If you have a test run where each test case uses the same pre-conditions, then consider inserting the pre-conditions at the beginning of the test run instead of inserting them into each individual test case.

BONUS: Cross-referencing test data
9. Put test data in a separate file and attach it to the test case or test run. In this way you’ll be able to test different variations of the data on a single test case.

10. You can create test data file with Excel, Notepad, or directly in a tool like ReQtest. In the image above, Testaccounts.txt contains two columns, one with a list of usernames and another with the corresponding passwords. Each line in the test data file is a unique combination of inputs which can be sequentially tested on the same test case. Another benefit of this method is that you control the test data that is used on the test case. You can also include a test data file as an attachment.

Check out these other blog posts Ulf and Mark Debono wrote about writing better test cases:

No comments:

Post a Comment