On specific projects where formal testing processes are required, building and maintaining a Master Test Plan (MTP) is a sound approach to managing your test efforts. The MTP serves as a high level document describing not only the various test plans that will be conducted (each plan is captured in a separate document), but additional critical information covering the entire testing process through release.
In a highly structured QA environment, the Master Test Plan serves as a "control document" that, to be changed, needs approval. Note that this approval can be efficiently accomplished through good communication - we are not fans of holding up the dev cycle for the sake of unnecessary bureaucracy! The MTP is essentially the roadmap and a comprehensive task list for the QA efforts to come, and ensures everyone knows what is expected for a high quality production release.
Every good Master Test Plan includes the following components:
Basics of the Master Test Plan
The Master Test Plan should detail the name of the project, the name of the creator, date of creation and versioning. These are important since the MTP will be stored at least for the duration of the project and maybe longer depending on audit requirements of the company. The Table of Contents and Index allows the user to easily navigate to specific sections.
Stakeholders or Approvals
List the managers or other stakeholders who need to approve the Master Test Plan before the next phase of testing can begin. This generally includes the Project Manager, Business Sponsor, Business Analyst, QA Manager, Development Manager and other team members as deemed fit.
Project Summary and Scope
Your summary should include an introduction and overview of the project - a short summary to give the reader a high level idea of the functionality the test plan refers.
The description of scope is essentially a list of features or functionality that will be tested and what won't be tested. This is Quality Assurance, after all, and it's best to leave nothing ambiguous. The scope section may also include the types of testing that will be done, for example, a project might decide to do system testing and integration testing but opt out of performance testing.
Test Entry and Exit Criteria
Certain conditions need to be met before actual software testing and QA can begin, which are referred to as the testing entry conditions or preconditions. These conditions could include information about the previous step in quality, for example a description of unit testing expected and the types of defects allowed/ not allowed to pass through. Additional entry conditions would include a description of the test environment, specific setup of required test data, review and approval of test cases, and more. For a rigorously controlled QA process, entry criteria can be a checkpoint before a project can enter the system testing phase.
Test Exit Criteria specifies the quality gates that need to be met before a project can be rolled into production, which are often created in conjunction between QA personnel and stakeholders. Minimum quality gates that most projects have are 100% execution of all test cases, no outstanding high severity defects, no showstoppers etc.
Test Data Requirements
Some organizations or projects such as those in healthcare and finance have specialized needs for complex test data, or data that mimics real-life information. Personal information of sample data needs to be masked for privacy protection before it can be used in testing. Other testing may require the generation of vast amounts of random data. These needs require special effort and time and must be noted down in the Master Test Plan.
Testing Tools
If the QA team plans to use any special tools, they need to be mentioned in the Master Test Plan. Most projects use at the very least a bug tracking tool like Jira or TestRail and perhaps an automation tool like Selenium. Comprehensive tool suites like HP Quality Center or SilkTest might be in place for teams with a good budget, and on the other end of the spectrum are the open source/ freeware like BugZilla and TestLink.
Risks
The Master Test Plan should mention and detail the known or anticipated risks of the particular project pertaining to QA and detail the mitigation strategy for these risks. Additional input from business analysts may be needed here.
Test Strategy
The test strategy section lists different types of testing to be performed, and a skilled QA professional draws from several sources to create a sound strategy. Apart from testing the functional requirements for the immediate release, a strategy should address business concerns and also focus on vulnerable areas of the project or system. For example, a project that adds new functionality to a particular feature area might require the re-testing of all previously logged Severity 1 and Severity 2 defects within that specific area.
Regression testing of existing functionality can be a major effort in the test cycle, so the testing strategy discussion will include the plan for functional execution of these less-tested features of the application. There are many ways to approach regression, whether by manual or automated efforts, but at the very least the critical business features should be covered.
A test strategy may also list the names and contact info of the resources involved in the testing process along with their specific role.
Testing Schedule
The Master Test Plan includes planned dates for various stages of testing such as system testing, integration testing and acceptance testing, or may simply refer to the project schedule maintained by the Project/Product Manager. Of course, in the typical rapid iteration of current software development, flexibility must be built into the plan in order to accommodate change.
Handoffs and Approvals
In a closely monitored project and QA process, the test plan might list the handoff conditions to be met to enter successive phases of testing, along with a list of people who need to provide approvals.
Defect Management Process
A Master Test Plan should detail the defect management process the project will follow and the different stages a defect will go through before it is closed. This may include a sample bug report as a template for what to expect.
Sample Test Cases
Include sample test cases to test essential business requirements. These are just examples because the Master Test Plan is created long before formal test design begins.
Test Metrics
Status reporting is an essential part of any controlled process such as development, test execution, and rollout. The Master Test Plan details the different test metrics that will be provided to the stakeholders in a status report on a daily or weekly basis after test execution begins and defects are being logged. This could be number of test cases executed, defects logged, features with the most bugs, coverage reports, etc.
Every organization has their own template for a Master Test Plan based on the software methodology they follow and other organizational guidelines. They may choose to omit some of these sections or add others that are applicable to their project or company. With these essential components of a Master Test Plan you can be certain your QA process is standardized and repeatable, and with regular updates this document becomes a living part of your QA process and QA team.