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
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
  • The resources and schedule required
  • The deliverables to be produced
Properties
Activity Exit StateApproved for Iteration
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 the Software Development Plan or the 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