October 30, 2006

Test Case Best Practices

Helix ALM
Community
The following guidelines are provided to help you write test cases.

Write a test plan and test cases

It 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).

Use templates with caution

Search for test case templates on the Web 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.

Assume that you will not be performing the test

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

Write the 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. Based on the example, it is clear to see that "Delete messages from the inbox" is not a valid test objective. The following is better: Verify 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).

Use a mix of valid and invalid tests

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.