The Goal of Test Planning

The testing process can't operate in a vacuum. Performing your testing tasks would be very difficult if the programmers wrote their code without telling you what it does, how it works, or when it will be complete. Likewise, if you and the other software testers don't communicate what you plan to test, what resources you need, and what your schedule is, your project will have little chance of succeeding. The software test plan is the primary means by which software testers communicate to the product development team what they intend to do.

The IEEE Standard 8291998 for Software Test Documentation^[1] states that the purpose of a software test plan is as follows:

^[1] The IEEE Std 829-1998 is available for purchase in printed and electronic form from standards.ieee.org.

To prescribe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan.

Given that definition and the rest of the IEEE standard, you will notice that the form the test plan takes is a written document. That shouldn't be too surprising, but it's an important point because although the end result is a piece of paper (or online document or web page), that paper isn't what the test plan is all about.

The test plan is a by-product of the detailed planning process that's undertaken to create it. It's the planning process that matters, not the resulting document.

The title of this chapter is "Planning Your Test Effort," not "Writing Your Test Plan." The distinction is intentional. Too often a written test plan ends up as shelfwarea document that sits on a shelf, never to be read. If the purpose of the planning effort is flipped from the creation of a document to the process of creating it, from writing a test plan to planning the testing tasks, the shelfware problem disappears.

This isn't to say that a final test plan document that describes and summarizes the results of the planning process is unnecessary. To the contrary, there still needs to be a test plan for reference and archivingand in some industries it's required by law. What's important is that the plan is the by-product of, not the fundamental reason for, the planning process.

The ultimate goal of the test planning process is communicating (not recording) the software test team's intent, its expectations, and its understanding of the testing that's to be performed.

If you spend time with your project team working through the topics presented in the remainder of this chapter, making sure that everyone has been informed and understands what the test team is planning to do, you'll go a long way in meeting this goal.