WorkProductDescriptor
Work Product (Artifact): Test Plan |
|
 |
This artifact defines the goals and objectives of testing within the scope of the test cycle, the items being targeted, the approach to be taken, the resources required, and the deliverables to be produced. |
|
Purpose
-
To outline and communicate the intent of the testing effort for a given schedule
-
To gain the acceptance and approval of the stakeholders in the test effort
|
Relationships
Roles | Responsible:
| Modified By:
|
Input To | Mandatory:
| Optional:
| External:
|
Output From |
|
Description
Main Description |
The Test Plan forms the framework within which the team performing the testing will work for the given schedule. It
directs, guides, and constrains the test effort, focusing the work on the useful and necessary deliverables. It also
communicates the intent of the effort to stakeholders. As such, the Test Plan should avoid detail that would not be
understood, or would be considered irrelevant by the stakeholders in the test effort.
In cultures or domains in which this work product is not recognized as a formal work product, it is still important to
address the different aspects represented by the Test Plan as part of the planning effort, and make appropriate
decisions about what testing will be undertaken, and how the test effort will be conducted.
|
Brief Outline |
The Test Plan captures the following informational elements:
-
The definition of the goals and objectives of the test effort within the scope of the iteration (or project)
-
The definition of the the targeted test items
-
An explanation of the approach or strategy that will be used
-
Entry and exit criteria that can be used to determine the starting and ending time for the execution
of the Test Plan
-
The required resources and schedule
-
The deliverables to be produced
|
Properties
Optional |  |
Planned |  |
Illustrations
Tailoring
Impact of not having |
Higher level plans for testing, such as a master test plan, are not executable, as they do not have detailed level
activities or tasks. Without task level details, resources and time schedules to carry out those tasks, it will be
difficult, if not impossible, to execute, track, manage and control them. Different levels of tests focus on different
areas of functionality and risk, and different organizational units may own responsibility. Thus without detailed test
plans organized around your main test cycles or iterations, it will be difficult for different organizational
units to plan, prepare, execute and report testing without actually increasing risk. Eliminating detailed test plans,
especially for large projects, will virtually guarantee project failure.
The creation of detailed test plans is also the activity that is most often underestimated in projects. It must start
as soon as pre-requisites are available to ensure that testing requirements and dependencies are identified early and
are addressed appropriately. Delaying the start of this activity often leads to project schedule overruns and increased
business or technical risks.
|
Reasons for not needing |
If the main factors driving the granularity of your test plans are test levels and test types, then not all
these factors are relevant during the duration of a project and therefore some specialized test plans will not be
developed or will be limited to just a few test cycles or iterations. In cases where projects are small, with
well-defined scope and structure, and all project members are co-located or work closely together, there may be one
joint test plan that covers the high level plan and all detail levels of testing.
|
Representation Options |
In certain testing cultures, Test Plans are considered informal, casual work products, whereas in others they are
highly formal and often require external signoff. As such, the format and content of the work product should be varied
to meet the specific needs of an organization or project. Start by considering the templates included with the IBM®
Rational Unified Process® (RUP®) approach, and remove, add, or modify elements from the template as needed.
As an alternative to formal documentation, you might choose to record the elements of the Test Plan as a set of
informal planning notes, possibly maintained on an intranet Web site or whiteboard readily visible to, and accessible
by, the test team.
Optionally, some aspects of this work product can be presented appropriately as enclosures within other plans (for
example a project plan, release plan, or iteration plan), rather than as a separate work products.
We recommend that you create smaller Test Plans focused on the scope of a single iteration. These work products should
contain the information related to the specific Test Motivators (for example, a subset of requirements and risks), the
specific test ideas you will investigate, strategies you will use, resources available, and so forth, relevant to the
specific Iteration.
Optionally, a Master Test Plan may be created at the outset of the project to provide an outline of the planned test
effort over the life of the project, and provide some forethought into resource requirements and other long-term
logistics concerns. This master work product also provides a way to limit the repetition of elements common to all Test
Plans, such as human, hardware, and software resources, management procedures, and so on. We recommend that you avoid
documenting specific detailed test information in the Test Plan, documenting that as necessary and appropriate in other
more appropriate test work products.
|
More Information
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|