Master Test Plan
Master Test Plan
Master Test Plan
<Project Name>
Master Test Plan
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process (RUP), and is designed
for use in conjunction with the detailed guidance provided within RUP. As with most of the templates
provided with RUP, this template should be customized to suit the context of the specific project it will be
used on.]
[Note: text such as this you are currently reading–enclosed in square brackets and displayed in blue italics
(style=InfoBlue)–is included to provide guidance to the author and should be deleted before publishing the
document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select
FileProperties and replace the Title, Subject and Company fields with the appropriate information for this
document. After closing the dialog, automatic fields may be updated throughout the document by selecting
EditSelect All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done
separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field
contents. See Word help for more information on working with fields.]
<Project Name> Version: <1.0>
Master Test Plan Date: <dd/mmm/yy>
<document identifier>
Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>
Table of Contents
1. Introduction 5
1.1 Purpose 5
1.2 Scope 5
1.3 Intended Audience 5
1.4 Document Terminology and Acronyms 5
1.5 References 5
1.6 Document Structure 6
5. Test Approach 7
5.1 Measuring the Extent of Testing 7
5.2 Identifying and Justifying Tests 7
5.3 Conducting Tests 7
7. Deliverables 8
7.1 Test Evaluation Summaries 8
7.2 Reporting on Test Coverage 8
7.3 Perceived Quality Reports 8
7.4 Incident Logs and Change Requests 8
7.5 Smoke Test Suite and Supporting Test Scripts 8
7.6 Additional Work Products 8
7.6.1 Detailed Test Results 9
7.6.2 Additional Automated Functional Test Scripts 9
7.6.3 Test Guidelines 9
7.6.4 Traceability Matrices 9
8. Testing Workflow 9
9. Environmental Needs 10
9.1 Base System Hardware 10
9.2 Base Software Elements in the Test Environment 10
represents a high level overview of both the tests that will be performed and those that will not.]
4.1 Overview of Test Inclusions
[Provide a high-level overview of the major testing planned for project/ phase. Note what will be included in
the plan and record what will explicitly not be included in the following section titled Overview of Test
Exclusions.]
4.2 Overview of Other Candidates for Potential Inclusion
[Give a separate overview of areas you suspect might be useful to investigate and evaluate, but that have not
been sufficiently researched to know if they are important to pursue.]
4.3 Overview of Test Exclusions
[Provide a high-level overview of the potential tests that might have been conducted but that have been
explicitly excluded from this plan. If a type of test will not be implemented and executed, indicate this in a
sentence stating the test will not be implemented or executed and stating the justification, such as:
“These tests do not help achieve the evaluation mission.”
“There are insufficient resources to conduct these tests.”
“These tests are unnecessary due to the testing conducted by xxxx.”
As a heuristic, if you think it would be reasonable for one of your audience members to expect a certain aspect
of testing to be included that you will not or cannot address, you should note it’s exclusion: If the team agrees
the exclusion is obvious, you probably don’t need to list it.]
5. Test Approach
[The Test Approach presents an overview of the recommended strategy for analyzing, designing, implementing
and executing the required tests. Sections 3, Target Test Items, and 4, Overview of Planned Tests, identified
what items will be tested and what types of tests would be performed. This section describes how the tests will
be realized.
As you identify each aspect of the approach, you should update Section 10, Responsibilities, Staffing, and
Training Needs, to document the test environment configuration and other resources that will be needed to
implement each aspect.]
5.1 Measuring the Extent of Testing
[Describe what strategy you will use for measuring the progress of the testing effort. When deciding on a
measurement strategy, it is important to consider the following advice from Cem Kaner, 2000 “Bug count
metrics reflect only a small part of the work and progress of the testing group. Many alternatives look more
closely at what has to be done and what has been done. These will often be more useful and less prone to side
effects than bug count metrics.”
A good measurement strategy will report on multiple dimensions. Consider the following dimensions, and select
a subset that are appropriate for your project context: coverage (against the product and/ or against the plan),
effort, results, obstacles, risks (in product quality and/ or testing quality), historical trend (across iterations
and/ or across projects).]
5.2 Identifying and Justifying Tests
[Describe how tests will be identified and considered for inclusion in the scope of the test effort covered by this
strategy. Provide a listing of resources that will be used to stimulate/ drive the identification and selection of
specific tests to be conducted, such as Initial Test-Idea Catalogs, Requirements documents, User documentation
and/ or Other Reference Sources. Examples of Test-Ideas Catalogs can be found in the process components
shipped with RUP.]
5.3 Conducting Tests
One of the main aspects of the test approach is an explanation of how the testing will be conducted, covering
the selection of quality-risk areas or test types that will be addressed and the associated techniques that will be
used. If you are maintaining a separate test strategy artifact that covers this, simply list the test types or
quality-risks areas that will be addressed by the plan, and refer to the test strategy artifact for the details. If
there is no separate test strategy artifact, you should provide an outline here of how testing will be conducted
for each technique: how design, implementation and execution of the tests will be done, and the criterion for
knowing that the technique is both useful and successful. For each technique, provide a description of the
technique and define why it is an important part of the test approach by briefly outlining how it helps achieve
the Evaluation Mission(s).
7. Deliverables
[In this section, list the various artifacts that will be created by the test effort that are useful deliverables to the
various stakeholders of the test effort. Don’t list all work products; only list those that give direct, tangible
benefit to a stakeholder and those by which you want the success of the test effort to be measured.]
7.1 Test Evaluation Summaries
[Provide a brief outline of both the form and content of the test evaluation summaries, and indicate how
frequently they will be produced.]
7.2 Reporting on Test Coverage
[Provide a brief outline of both the form and content of the reports used to measure the extent of testing, and
indicate how frequently they will be produced. Give an indication as to the method and tools used to record,
measure, and report on the extent of testing.]
7.3 Perceived Quality Reports
[Provide a brief outline of both the form and content of the reports used to measure the perceived quality of the
product, and indicate how frequently they will be produced. Give an indication about to the method and tools
used to record, measure, and report on the perceived product quality. You might include some analysis of
Incidents and Change Request over Test Coverage.]
7.4 Incident Logs and Change Requests
[Provide a brief outline of both the method and tools used to record, track, and manage test incidents,
associated change requests, and their status.]
7.5 Smoke Test Suite and Supporting Test Scripts
[Provide a brief outline of the test assets that will be delivered to allow ongoing regression testing of
subsequent product builds to help detect regressions in the product quality.]
7.6 Additional Work Products
[In this section, identify the work products that are optional deliverables or those that should not be used to
measure or assess the successful execution of the Master Test Plan.]
7.6.1 Detailed Test Results
[This denotes either a collection of Microsoft Excel spreadsheets listing the results determined for each test
case, or the repository of both test logs and determined results maintained by a specialized test product.]
7.6.2 Additional Automated Functional Test Scripts
[These will be either a collection of the source code files for automated test scripts, or the repository of both
source code and compiled executables for test scripts maintained by the test automation product.]
7.6.3 Test Guidelines
[Test Guidelines cover a broad set of categories, including Test-Idea catalogs, Good Practice Guidance, Test
patterns, Fault and Failure Models, Automation Design Standards, and so forth.]
7.6.4 Traceability Matrices
[Using a tool such as Rational RequisistePro or MS Excel, provide one or more matrices of traceability
relationships between traced items.]
8. Testing Workflow
[Provide an outline of the workflow to be followed by the Test team in the development and execution of this
Master Test Plan.]
The specific testing workflow that you will use should be documented separately in the project's Development
Case. It should explain how the project has customized the base RUP test workflow (typically on a phase-by-
phase basis). In most cases, we recommend you place a reference in this section of the Master Test Plan to the
relevant section of the Development Case. It might be both useful and sufficient to simply include a diagram or
image depicting your test workflow.
More specific details of the individual testing tasks are defined in a number of different ways, depending on
project culture; for example:
defined as a list of tasks in this section of the Master Test Plan, or in an accompanying appendix
defined in a central project schedule (often in a scheduling tool such as Microsoft Project)
documented in individual, "dynamic" to-do lists for each team member, which are usually too detailed to be
placed in the Master Test Plan
documented on a centrally located whiteboard and updated dynamically
not formally documented at all
Based on your project culture, you should either list your specific testing tasks here or provide some descriptive
text explaining the process your team uses to handle detailed task planning and provide a reference to where
the details are stored, if appropriate.
For Master Test Plans, we recommend avoiding detailed task planning, which is often an unproductive effort if
done as a front-loaded activity at the beginning of the project. A Master Test Plan might usefully describe the
phases and the number of iterations, and give an indication of what types of testing are generally planned for
each Phase or Iteration.
Note: Where process and detailed planning information is recorded centrally and separately from this Master
Test Plan, you will have to manage the issues that will arise from having duplicate copies of the same
information. To avoid team members referencing out-of-date information, we suggest that in this situation you
place the minimum amount of process and planning information within the Master Test Plan to make ongoing
maintenance easier and simply reference the "Master" source material.]
9. Environmental Needs
[This section presents the non-human resources required for the Master Test Plan.
Note: This section may be delegated in whole or part to the Test Strategy artifact.]
9.1 Base System Hardware
The following table sets forth the system resources for the test effort presented in this Master Test Plan.
[The specific elements of the test system may not be fully understood in early iterations, so expect this section to
be completed over time. We recommend that the system simulates the production environment, scaling down the
concurrent access and database size, and so forth, if and where appropriate.]
[Note: Add or delete items as appropriate.]
System Resources
Resource Quantity Name and Type
Human Resources
Role Minimum Resources Specific Responsibilities or Comments
Recommended
(Number of full-time roles
allocated)
Look for opportunities to combine the purchase of productivity tools with training on those tools, and arrange
with the vendor to delay delivery of the training until just before you need it. If you have enough headcount,
consider having training delivered in a customized manner for you, possibly at your own site.
The test team often requires the support and skills of other team members not directly part of the test team.
Make sure you arrange in your plan for appropriate availability of System Administrators, Database
Administrators, and Developers who are required to enable the test effort.]
11. Key Project/ Phase Milestones
[Identify the key schedule milestones that set the context for the Testing effort. Avoid repeating too much detail
that is documented elsewhere in plans that address the entire project.]
[List any dependencies identified during the development of this Master Test Plan that may affect its successful
execution if those dependencies are not honored. Typically these dependencies relate to activities on the critical
path that are prerequisites or post-requisites to one or more preceding (or subsequent) activities You should
consider responsibilities you are relying on other teams or staff members external to the test effort completing,
timing and dependencies of other planned tasks, the reliance on certain work products being produced.]
Dependency between Potential Impact of Dependency Owners
[List any assumptions made during the development of this Master Test Plan that may affect its successful
execution if those assumptions are proven incorrect. Assumptions might relate to work you assume other teams
are doing, expectations that certain aspects of the product or environment are stable, and so forth].
Impact of Assumption being
Assumption to be proven incorrect Owners
[List any constraints placed on the test effort that have had a negative effect on the way in which this Master
Test Plan has been approached.]
Constraint on Impact Constraint has on test effort Owners