Test Plans, Estimates and Strategies

The trio of test topics: plans, estimates and strategies depend on a number of factors, including the level, targets and objectives of the testing we're setting out to do. Writing a plan, preparing an estimate and selecting test strategies tend to happen concurrently and ideally during the planning period for the overall project, though we must ready to revise them as the project proceeds and we gain more information.

The purpose and substance of test plans

While people tend to have different definitions of what goes in a test plan, for us a test plan is the project
plan for the testing work to be done. It is not a test design specification, a collection of testcases or a set
of test procedures; in fact, most of our test plans do not address that level of detail.

Why do we write test plans? We have three main reasons. First, writing a test plan guides our thinking. We find that if we can explain something in words, we understand it. If not, there's a good chance we don't.
Writing a test plan forces us to confront the challenges that await us and focus our thinking on important topics.

The test planning process and the plan itself serve as vehicles for communicating with other members of the project team, testers, peers, managers and other stakeholders. This communication allows the test plan to influence the project team and the project team to influence the test plan, especially in the areas of organization-wide testing policies and motivations; test scope, objec-tives and critical areas to test; project and product risks, resource considera-tions and constraints; and the testability of the item under test.

The test plan also helps us manage change. During early phases of the project, as we gather more information, we revise our plans. As the project evolves and situations change, we adapt our plans.

Written test plans give us a baseline against which to measure such revisions and changes. Furthermore, updating the plan at major milestones helps keep testing aligned with project needs. As we run the tests, we make final adjustments to our plans based on the results. You might not have the time - or the energy - to update your test plans every time a variance occurs, as some projects can be quite dynamic.

In certain senarios  it's better to write multiple test plans in some situations. For example, when we manage
both integration and system test levels, those two test execution periods occur at different points in time and
have different objectives. For some systems projects, a hardware test plan and a software test plan will address different techniques and tools as well as different audiences. However, since there might be overlap between these test plans, a master ttest plan that addresses the common elements can reduce the amount of redundant documentation.