Topic: Test Case Descriptions

In step three, you may have generated between ten and fifty test case names on your first pass. That number will go up as you continue to make your testing more systematic. The advantage of having a large number of tests is that it usually increases the coverage.

The disadvantage to creating a big test suite is simply that it is too big. It could take a long time to fully specify every test case that you have mapped out. And, the resulting document could become too large, making it harder to maintain.

A good strategy is to be selective before drilling down to the next level of detail. For example, you might prioritize the test cases based on the priorities of the features or use cases that they test. Also, it's a good idea to first write descriptions rather than get into detailed steps for each test case. Going deep into the details of just a few test cases may be enough to shake out ambiguity or incompleteness in the requirements. The remaining cases should all be specified eventually, however you might choose to rely on ad-hoc testing for lower priority features in early releases.

For each test case, write one to three sentences describing its purpose. The description should provide enough information so that you could come back to it after several weeks and recall the same ad-hoc testing steps that you have in mind now. Later, when you actually write detailed steps in the test case, you will be able to expect any team member to carry out the test the same way that you intended.

The act of writing the descriptions forces you to think a bit more about each test case. When describing a test case, you may realize that it should actually be split into two test cases, or merged with another test case. And again, make sure to note any requirements problems or questions that you uncover.