Detail Test Plans: Get Rid Of Them
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.