A test plan documents the strategy that will be used to verify and ensure that a product or
system meets its design specifications and other requirements. A test plan is usually prepared by
or with significant input from test engineers.
Depending on the product and the responsibility of the organization to which the test plan
applies, a test plan may include a strategy for one or more of the following:
Design verification or compliance test – to be performed during the development or
approval stages of the product, typically on a small sample of units.
Manufacturing test or production test – to be performed during preparation or assembly
of the product in an ongoing manner for purposes of performance verification and quality
control.
Acceptance test or commissioning test – to be performed at the time of delivery or
installation of the product.
Service and repair test – to be performed as required over the service life of the product.
Regression test – to be performed on an existing operational product, to verify that
existing functionality was not negatively affected when other aspects of the environment
were changed (e.g., upgrading the platform on which an existing application runs).
A complex system may have a high level test plan to address the overall requirements and
supporting test plans to address the design details of subsystems and components.
Test plan document formats can be as varied as the products and organizations to which they
apply. There are three major elements that should be described in the test plan: Test Coverage,
Test Methods, and Test Responsibilities. These are also used in a formal test strategy.
Test coverage
Test coverage in the test plan states what requirements will be verified during what stages of the
product life. Test coverage is derived from design specifications and other requirements, such as
safety standards or regulatory codes, where each requirement or specification of the design
ideally will have one or more corresponding means of verification. Test coverage for different
product life stages may overlap, but will not necessarily be exactly the same for all stages. For
example, some requirements may be verified during Design Verification test, but not repeated
during Acceptance test. Test coverage also feeds back into the design process, since the product
may have to be designed to allow test access.
Test methods
Test methods in the test plan state how test coverage will be implemented. Test methods may be
determined by standards, regulatory agencies, or contractual agreement, or may have to be
created new. Test methods also specify test equipment to be used in the performance of the tests
and establish pass/fail criteria. Test methods used to verify hardware design requirements can
range from very simple steps, such as visual inspection, to elaborate test procedures that are
documented separately.
Test responsibilities
Test responsibilities include what organizations will perform the test methods and at each stage
of the product life. This allows test organizations to plan, acquire or develop test equipment and
other resources necessary to implement the test methods for which they are responsible. Test
responsibilities also include what data will be collected and how that data will be stored and
reported (often referred to as "deliverables"). One outcome of a successful test plan should be a
record or report of the verification of all design specifications and requirements as agreed upon
by all parties.
IEEE 829 test plan structure
IEEE 829-2008, also known as the 829 Standard for Software Test Documentation, is an IEEE
standard that specifies the form of a set of documents for use in defined stages of software
testing, each stage potentially producing its own separate type of document.[1] These stages are:
Test plan identifier
Introduction
Test items
Features to be tested
Features not to be tested
Approach
Item pass/fail criteria
Suspension criteria and resumption requirements
Test deliverables
Testing tasks
Environmental needs
Responsibilities
Staffing and training needs
Schedule
Risks and contingencies
Approvals