Test plan is the project plan for the testing work to be done. It is not a test design specification, a collection of test cases or a set of test procedures; in fact, most of our test plans do not address that level of detail. Many people have different definitions for test plans.
Why it is required to write test plans? We have three main reasons to write the test plans:
First, by writing a test plan it guides our thinking. Writing a test plan forces us to confront the challenges that await us and focus our thinking on important topics.
Fred Brooks explains the importance of careful estimation and planning for testing in one of his book as follows:
Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date [and] delay at this point has unusually severe … financial repercussions. The project is fully staffed, and cost-per day is maximum [as are the associated opportunity costs]. It is therefore very important to allow enough system test time in the original schedule.
By using a template for writing test plans helps us remember the important challenges. You can use the IEEE 829 test plan template shown in this chapter, use someone else’s template, or create your own template over time.
Second, the test planning process and the plan itself serve as the means of communication 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, objectives and critical areas to test; project and product risks, resource considerations and constraints; and the testability of the item under test. We can complete this communication by circulating one or two test plan drafts and through review meetings. Such a draft will include many notes such as the following:
[To Be Determined: Jennifer: Please tell me what the plan is for releasing the test items into the test lab for each cycle of system test execution?]
[Dave – please let me know which version of the test tool will be used for the regression tests of the previous increments.]
As we keep note or document the answers to these kinds of questions, the test plan becomes a record of previous discussions and agreements between the testers and the rest of the project team.
Third, the test plan helps us to 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. By updating the plan at major milestone helps us to 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 change is made in the project, as some projects can be quite dynamic.
At times it is 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, there are chances that these test plans can get overlapped, hence, a master test plan should be made that addresses the common elements of both the test plans can reduce the amount of redundant documentation.
IEEE 829 STANDARD TEST PLAN TEMPLATE
Test plan identifier
Features to be tested
Features not to be tested
Staffing and training needs
Item pass/fail criteria
Risks and contingencies
Suspension and resumption criteria Approvals