The master test plan covers all of the testing work to be done on a particular project, including the particular levels to be carried out and the relationships among those levels, and between test levels and corresponding development activities. The master test plan will discuss how our testers will implement the test strategy for this project (i.e., the test approach). The master test plan will be consistent with the test policy and strategy, and, in specific areas where it is not, it will explain those deviations and exceptions, including any potential impact resulting from the deviations. For example, if it is our testing strategy to conduct one complete pass of regression testing on an unchanging system immediately prior to release, but the current project will have no regression testing, the test plan will explain why this is planned and what will be done to mitigate any risk due to this variance from the usual strategy. The test plan will also include an explanation of any other effects that are expected from this variance. For example, skipping regression testing might require scheduling a maintenance release one month after the initial project release. The master test plan will complement the project plan or operations guide in that it should describe the testing effort that is part of the larger project or operation.
While the specific content and structure of the master test plan varies depending on the organization, its documentation standards, and the formality of the project, typical topics for a master test plan include:
- Items to be tested and not to be tested
- Quality characteristics to be tested and not to be tested
- Testing schedule and budget (which should be aligned with the project or operational budget)
- Test execution cycles and their relationship to the software release plan
- Relationships and deliverables among testing and other people or departments
- Definition of what test items are in scope and out of scope for each level described
- Specific entry criteria, continuation (suspension/resumption) criteria, and exit criteria for each level and the relationships among the levels
- Test project risks
- Overall governance of the testing effort
- Responsibilities for executing each of the test levels
- Inputs to and outputs from each of the test levels
On smaller projects or operations, where only one level of testing is formalized, the master test plan and the test plan for that formalized level will often be combined into one document. For example, if system test is the only formalized level, with informal component and integration testing performed by developers and informal acceptance testing performed by customers as part of a beta test process, then the system test plan may include the elements mentioned in this section.
In addition, testing typically depends on other activities in the project. Should these activities not be sufficiently documented, particularly in terms of their influence and relationship with testing, topics related to those activities may be covered in the master test plan (or in the appropriate level test plan). For example, if the configuration management process is not documented, the test plan should specify how test objects are to be delivered to the test team.