When writing test cases for your project, it’s often easy to forget what is important. This article is aimed at reminding experienced testers or informing new ones of what the key items are, to ensure we are being efficient in writing our tests.
Who will be executing the test scripts? Will the scripts form part of a Regression Pack? Will the scripts be used for anything else (e.g. training manuals)?
These questions are meant to kick start your thought process when writing test cases. Essentially, the person who writes the test is not always the person who executes it. As such, Test Cases need to be written so that anyone of any level can read, understand and be able to execute the test case. The aim of this is that no matter the level of the tester, the outcome will always be the same. When writing your test, if you approach this with ‘baby-steps’ in mind and make no assumptions that the person who executes it is has any prior knowledge of the project, and you shouldn’t go far wrong.
Every single test case should be Unique, Measurable and Specific. If you aren’t quite clear what this means, I’ve defined this below for you.
Where possible, keep test cases reasonably short. A long number of test steps can add complexity to the scenario, it can make the tester feel like they’ve been executing the same test forever and it can affect the accuracy of progress and defect reporting. Break your test scripts down into smaller scenarios if possible and although this will mean more test cases, they will be quicker to execute and will produce more accurate statistics of test results.
The inclusion of data in your test steps can be very useful. It saves time and energy sourcing the test data. It makes test execution more efficient.
Before you do this though, you need to understand a few things. Can the data go out of date? Is a database refresh likely to occur? If the data is likely to change however it may be easier to create a database or reference sheet to store your test data in one place. This means that if you need to change the data, you can do it in one place rather than have to trawl through your test cases to make the change individually.
Test Management tools often cater for the information which should go into a test case by providing fields for testers to enter the details which need.
Those who have completed their ISTQB Foundation course will know that IEEE829 states that the following should be included in a Test Case: