Write Software Testing Plan

All software needs to be tested. In fact, software testing is a major part of the overall software development process that involves many people and countless hours of detailed work. Unfortunately, most testing efforts are under-planned: some software testing professionals work in the field for years without ever seeing a really comprehensive QA plan and test suite. Part of the problem is that QA efforts often begin too late in the release cycle when there is too much pressure to take shortcuts.

The figure below illustrates where your QA plan and test suite fit with other project documents.

Software development projects that don't have enough test planning tend to bog down with defects that can put the entire project's success at risk. Test planning helps in the following specific areas:

Requirements Validation

Designing a system test suite forces you to deeply understand the requirements. As you understand the requirements more, you will notice incompleteness, ambiguity, and inconsistency. Correcting these problems early can speed up development and reduce the number of late requirements changes.

Testing Coordination

Testing involves many people working together over time. For the team to be effective, their efforts must be coordinated with a written plan.

Test Coverage

Testing only half of a large system is sure to allow thousands of defects into the shipping product. A QA plan is needed to set coverage criteria and evaluate coverage. A test suite must be carefully designed with the coverage criteria in mind.

Test Automation

Too often, QA teams hope to use automated testing, but end up stuck with ad-hoc manual testing. This happens because they never really formalize the requirements, so they must always rely on human judgment to evaluate test outputs. Creating automated test scripts without outlining the test suite is like writing code without a design document. The following diagram illustrates the gap between ad-hoc testing and automated testing, and how systematic testing with a test suite bridges that gap.

The rest of this white paper works through the steps shown in the diagram below.

Note that in steps 4 and 5, we recommend that you only specify the most important test cases in detail. In any complex system, there will be a large number of potential test cases. We encourage you to take a breadth-first approach: map out your test case suite first, then fill in details incrementally as needed. This concept is key to getting the most value out of the limited time that you have for test planning.

Step One: Overall QA Planning