There are lots of different ways to write test cases. This article will give you examples of common structures which you can use and adapt to suit your need.
A simple template for test cases
This is a fairly common structure that contains a number of important points. The test case has multiple test steps, some of which have expected result and some which do not.
You should have 3-8 test steps in a test case. If you only have a few test steps, you should probably consider making a checklist instead – it’s not worth your while to keep track of a lot of small test cases when a checklist will do the job just as well.
When testers report defects based on the test case, they should indicate which test step failed, in order to make troubleshooting easier.
When you write a test case, you don’t need to specify the expected result for each test step if the result is obvious. In the above example there are unnecessary outcomes of several test steps. For example, ff the browser doesn’t open, the tester won’t be able to proceed to the next step.
If your test case has too many test steps you ought 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, the developer will have to backtrack and repeat all the test steps, which he or she might not do by accident, or out of laziness.
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.
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. An example of a pre-condition is that to change the customer’s address you have to enter a customer first. You can use this field to reference to other test cases, for example by entering a test case ID here.
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. An example of pre-condition for a bunch of test cases could be to put the system in a certain state, for example, loading a certain set of customers into the system before testing begins.
Referencing test data
If you put your test data in a separate file and reference it from the test case, you’ll be able to use a single test case to test many different variations of the data. This is a better solution than explicitly stating test data in the test case.
A test data file can be created in Excel, in Notepad, or included in a database. In the test case above, the “Testaccounts.txt” file might consist of one column for the user name and one for the password. Each line in the test data file represents a unique combination of inputs. The test case will be very efficient because only one test case is needed to test multiple combinations. It also means that the choice of which test data to use is not just left up to the tester’s discretion.
More technical test cases
More technical test cases, such as system level testing, may refer to tests of the database or other system components.
Suggestions for further reading
- Read our article on “How to develop a template for test cases” and which is also on our site – http://www.reqtest.com/blog/newsletters/how-to-develop-a-template-for-test-cases/
- If you’re still writing test cases in Word, we highly recommend you look into real testing tools instead, such as ReQtest. See www.reqtest.com for more information.
- Now that you’re using ReQtest, read these two articles, one about How to create test cases in ReQtest – http://www.reqtest.com/blog/howto/how-to-create-test-cases-in-reqtest/ and the other about how to and execute test cases in ReQtest – http://www.reqtest.com/blog/howto/plan-and-execute-test-cases-in-reqtest/