Test Plans: Don’t Overdo It

  In the beginning of the project, once the specifications become clear and the project planning is defined by the project manager, the test manager creates a Master Test Plan, If a test manager is lucky the project manager consults him/her for the project planning. Since the project's life cycle is not exactly known, the project manager relies on gut feelings, experience, function points, metrics, and anything else he or she can lay his or her hands on. To help guide them test managers also rely on the same resources in addition to "rules of thumb" such as, "one third of the project time is testing time."

1. Introduction: approval, goal, references, history, and recipients.
2. Project description: background, commission, planning test period, acceptance criteria, scope, starting points and conditions, and risk evaluation.
3. Test strategy: introduction, test units, quality attributes, quality requirements, quality requirements per test unit, and test types.
4. Test organization: test team, planning, tasks, test effort, and communication.
5. Test environment: general, hardware, software, test tools.
6. Procedures: test files, test ware, deliverables, project closure.
7. Appendices: supplemental data, materials, etc.

Responsibilities, lines of communication and project scope should be in the Project Plan and not the Master Test Plan. Testing is part of the whole development project. The project manager is responsible for the project plan. The quality requirements of the product (parts) as well as the description of the product itself should be in the product specifications. At the beginning of the project there is a desire to know how the tests will be done (in general). Indentifying the men, means, methods, and the required time it will take are normally defined in the early stages of project planning. The test strategy on a high abstraction level is required. Test scripts are not part of the test plan, however, in the test plan it is indicated how the scripts are to be crested and which techniques will be used.

 Somewhere in history some testing guru (in the land of the blind the one-eyed man is king...a Dutch expression) decided that it is important that for every test type, e.g. Functional Acceptance Test or User Acceptance Test, a separate test plan should be created. As you can see software testing was never a real science. Now it looks like the whole testing world is convinced that it is important to make DTP’s. I’m working in Quality & Testing all of my working days and never got a satisfactory answer to that one big question: “WHY?” The test types and planning are already described in the MTP, aren't they?

Only a few people read the MTP, so you can be pretty sure nobody will read a DTP. The project manager reads the planning part of the MTP. The test analysts and testers read the rest. Other than these select few - nobody reads it. Not a lot of people are interested in testing anyway. Half of the DTP is a copy of the MTP. It would be strange if the introduction, scope and planning (including resources) would be another story from the MTP all of a sudden.

So there is not much left to talk about, bits of testing-specific information that could, or more so should be placed in the MTP. Basically its just meant there to make testing look more important. Project Managers put them on their list of deliverables that have to be managed without having a clue about what they are managing, because they heard that these DTP’s seem important.

Testing is important enough though. Better focus on proper knowledge of the processes (the foundation for proper testing), on the scripts, on the test execution itself, and on findings management.

The project is never large enough to justify DTP’s. Because if it is too large, the project is chopped up in pieces or phases for which separate MTP’s are created. Waste you time on paperwork that matters, and on risk management - which works.

This article is based on the book “Q-Course Quality & Organization”, see www.q-course.com.