Writing test cases isn't always easy. But if you follow these five tips, your test cases will improve dramatically.
1. Write Actual Test Cases
This may seem obvious. But the most critical best practice for test cases is to actually write them.
Ad hoc testing is great for gathering more information about issues and for discovering how a program works. But it should not form the basis of your testing efforts.
If you need help writing test cases start with the Institute of Electrical and Electronics Engineers (IEEE) standard 829 (IEEE 829—Standard for Software Test Documentation).
Back to top2. Beware of Templates
Search for test case templates, and you will receive thousands of results.
Everyone is looking for shortcuts to help them write their test cases quickly, so they can get to the "important" work of performing the tests.
However, while templates can serve as a guide to help you to clearly define the case, do not allow yourself to lapse into autopilot and simply fill in the blanks. Make sure that you consider your software's unique features and the best way to test them before filling out a form.
Back to top3. Write Test Steps Anyone Can Follow
It is easy to cut corners when writing a test case that you will be running. You can skip over steps and summarize the required data or setup. But if someone else is following that test case, you'll be in trouble.
So, write test steps that anyone can follow (just in case you're not the one performing the test case).
By assuming that you will hand the test case to someone else to perform, you force yourself to write to the appropriate level of detail.
Back to top4. Frame Test Objectives as Hypotheses
In a scientific experiment, a hypothesis proposes a relationship between two or more variables.
A test case is an experiment and the test objective is the equivalent of a hypothesis.
The following is an example of a formalized hypothesis that uses an if/then structure:
If migraines are related to caffeine, then people with a higher intake of caffeine will have a higher frequency of migraines.
So, if your test objective is "Delete messages from the inbox", you're in trouble.
The following is better:
Back to topVerify that if a message is in the inbox then it can be deleted using all three available methods, regardless of its state (read or unread).
5. Write Invalid Test Cases
Do not simply write test cases that the software should pass.
For example, if the cell in a spreadsheet should hold 1,000 characters, do not simply write a case which checks just for that number of characters. Test outside the boundaries as well.
When testing invalid tests, the software passes if it handles the invalid condition gracefully. It fails when the condition results in data loss or a crash.
Therefore, if you enter 1,001 and characters into a spreadsheet cell and receive a message explaining that you can only enter 1,000 characters, then the software passes the invalid test.
If, however, the software shuts down unexpectedly without an error, then it fails the test.
Aim for an equal mix of valid and invalid tests. You can find ideas for invalid tests in the error message log or by looking for boundary conditions.
Back to topThe Best Way to Write Test Cases in Software Testing...
There's a right way to write test cases — and a wrong way. Download the "How to Succeed (and Fail) at Test Case Management" white paper. you'll get examples of writing test cases that work (or don't work). Plus, you'll learn how effective test case management makes a big difference.
Note: This post was originally published on October 30, 2006 and has been updated for accuracy and comprehensiveness.