The Goals of Test Case Planning

The early chapters of this book discussed the different software development models and the various testing techniques that can be used, based on those models, to perform effective testing. In a big-bang or code-and-fix model, the testers are at the mercy of the project, often having to guess what testing to perform and whether what they find are indeed bugs. In the more disciplined development models, testing becomes a bit easier because there's formal documentation such as product specs and design specs. The software creationthe design, architecture, and programmingbecomes a true process, not just a chaotic race to get a product out the door. Testing in that environment is much more efficient and predictable.

There's the old saying, "What's good for the goose is good for the gander," meaning what's beneficial to one person or group is also beneficial to another. Hopefully, from what you've learned so far, you would think it's heresy for a programmer to take the product spec and immediately start coding without developing a more detailed plan and distributing it for review. A tester, then, taking the test plan and instantly sitting down to think up test cases and begin testing should seem just as wrong. If software testers expect the project managers and the programmers to be more disciplined, instill some methods, and follow some rules to make the development process run more smoothly, they should also expect to do the same.

Carefully and methodically planning test cases is a step in that direction. Doing so is very important for four reasons:

• Organization. Even on small software projects it's possible to have many thousands of test cases. The cases may have been created by several testers over the course of several months or even years. Proper planning will organize them so that all the testers and other project team members can review and use them effectively.

• Repeatability. As you've learned, it's necessary over the course of a project to run the same tests several times to look for new bugs and to make sure that old ones have been fixed. Without proper planning, it would be impossible to know what test cases were last run and exactly how they were run so that you could repeat the exact tests.

• Tracking. Similarly, you need to answer important questions over the course of a project. How many test cases did you plan to run? How many did you run on the last software release? How many passed and how many failed? Were any test cases skipped? And so on. If no planning went into the test cases, it would be impossible to answer these questions.

• Proof of testing (or not testing). In a few high-risk industries, the software test team must prove that it did indeed run the tests that it planned to run. It could actually be illegal, and dangerous, to release software in which a few test cases were skipped. Proper test case planning and tracking provides a means for proving what was tested.

NOTE

Don't confuse test case planning with the identification of test cases that you learned in Part II, "Testing Fundamentals." Those chapters taught you how to test and how to select test cases, similar to teaching a programmer how to program in a specific language. Test case planning is the next step up and is similar to a programmer learning how to perform high-level design and properly document his work.

AD HOC TESTING

One type of software testing, called ad hoc testing, describes performing tests without a real planno test case planning and sometimes not even a high-level test plan. With ad hoc testing, a tester sits down with the software and starts banging the keys. Some people are naturally good at this and can find bugs right away. It may look impressive and may have some value as a supplement to planned testsfor example, in a bug bashbut it's not organized, it's not repeatable, it can't be tracked, and when it's complete, there's no proof that it was ever done. As a tester you don't want code that was written in an ad hoc manner, nor do your customers want software that was tested exclusively in an ad hoc manner.