A Test Plan is a Tool - a Dynamic Tool, That is

Why do we write test plans? Are we all just frustrated unpublished authors? (No, that's why we write blogs. ;-)

A test plan is a tool. The act of researching and writing a plan forces us to examine the software under test, to understand how it works, and the risks inherent it its function and its environment. By writing the plan as a document, we contribute to the institutional memory of the software project, as the document is persistent, and will be available as a resource to all the project team members and to other projects.

But - the fact that the plan may be stored as a static document file is purely incidental. Documents, files, database records are simply the mechanism by which we make collected information available to be read.

The most important thing about a test plan is that the information in the plan has to be dynamic, nit static. It has to adapt to changes in the project scope, direction, design, etc., and to changes in the potential risks that the project faces.

To be a successful test planning tool, the test plan has to reflect the "unfinished agenda" [1] of the testing effort.

But, what should that unfinished agenda be based on? The testing and quality risks that the product currently faces. The important thing to remember is that the risks the product faces during its testing will change. Perhaps the product design will change. If this happens, the plan has to adapt. Or, maybe new information will be received from a beta test sight about user requirements. Or, maybe tests that were originally planned become obsolete.

Remember how - in an earlier post to this blog - we talked about how it is impossible to find literally every bug in a product? The tests have to focus on what's most important, and that means focusing on what's most at risk. And - this will change constantly during the testing of a product.

So, the plan must be dynamic, not static, changing to meet the challenge of each new set of risks. The plan is part of a process - a way of finding the most serious bugs. [2]

Ref:

[1] From a 1960 speech by US President Kennedy
[2] Yes, from another JFK speech

What format should a test plan take? While the content is always more important than the format, it does help to have a well organized plan. I'm partial to the IEEE test plan format:

IEEE Test Plan
IEEE Test Plan in Wikipedia
Useful Wikipedia entry on test plans