Artifact:  Test Plan

Test Plan	The definition of the goals and objectives of testing within the scope of the iteration (or project), the items being targeted, the approach to be taken, the resources required and the deliverables to be produced.
UML Representation:	There is no UML representation for this artifact.
Role:	Test Manager
Optionality/ Occurrence:	One or more artifacts. Considered informal in some domains and test cultures, and formal in others. Typically a "Master" Test Plan may be created and maintained per project, with one more specific Test Plan created for each iteration.
Enclosed in:	Optionally, some aspects of the Test Plan can be presented appropriately within the Software Development Plan and the Iteration Plan.
Templates:	HTML   Others
Examples:	Test Plan, from the Course Registration System Elaboration Construction Test Plan, from the Collegiate Sports Paging System (e-business)
Reports:
More Information:	Guidelines:Test Plan Checkpoints:Test Plan
Purpose Properties Timing Responsibility Tailoring

Input to Activities:  Execute Test Suite Implement Test Suite Determine Test Results Identify Test Ideas Define Test Details Assess Iteration Develop Quality Assurance Plan Iteration Evaluation Criteria Review Develop Test Guidelines Identify Testability Mechanisms Define Testability Elements Structure the Test Implementation Identify Targets of Test Define Assessment and Traceability Needs Agree Mission Assess and Advocate Quality Identify Test Motivators Assess and Improve Test Effort Obtain Testability Commitment Define Test Approach Define Test Environment Configurations

Output from Activities:  Identify Targets of Test Define Assessment and Traceability Needs Agree Mission Assess and Advocate Quality Identify Test Motivators Assess and Improve Test Effort Obtain Testability Commitment Define Test Approach Define Test Environment Configurations

Purpose

The purpose of the Test Plan is to outline and communicate the intent of the testing effort for a given schedule. Primarily, as with other planning documents, the main objective is to gain the acceptance and approval of the stakeholders in the test effort. As such, the document should avoid detail that would not be understood, or would be considered irrelevant by the stakeholders in the test effort.

Secondly, the test plan forms the framework within which the test roles work for the given schedule. It directs, guides and constrains the test effort, focusing the work on the useful and necessary deliverables.

In cultures or domains in which test plans are not recognized as formal artifacts, it is still important to consider the different aspects represented by the test plan, and make appropriate decisions about what testing will be undertaken and how the test effort will be approached.

Properties

There are no UML representations for these properties.

Timing

An initial Test Plan, typically referred to as the "Master" Test Plan, may be created during the Inception phase. This instance of the Test Plan provides an overview of the test effort over the life of the project, providing foresight into when resources will be required and when important quality dimensions and risks will be addressed.

As each iteration is planned, one or more specific "Iteration" Test Plans are created providing specific information focused on the iteration.

Responsibility

The Test Manager role is primarily responsible for this artifact. The responsibilities are split into two main areas of concern:

The primary set of responsibilities covers the following management issues, ensuring the Test Plan:

• reflects the appropriate Evaluation Mission for the test effort for the given schedule
• is motivated by aspects considered useful and fruitful to evaluate for the given schedule
• represents an achievable approach to evaluation
• is accepted by the stakeholders
• changes are controlled and communicated to affected roles
• is followed by the test team members

The secondary set of responsibilities covers the following definition issues, ensuring the Test Plan:

• identifies the appropriate Target Test Items for the given schedule
• reflects an appropriate and achievable approach to be taken to conduct the evaluation
• considers both a breadth and depth of quality risks
• accurately identifies the necessary resources, human, hardware, and software

Tailoring

In certain testing cultures, Test Plans are considered informal, casual artifacts, whereas in others they are highly formalized and often require external signoff. As such, the format and content of Test Plans should be varied to meet the specific needs of an organization or project. Start by considering the Test Plan template included with the RUP and add, modify, or remove elements of the format as needed.

As an alternative to formal documentation, you might choose to only record the elements of the iteration 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.

We recommend that you create smaller Test Plans focused on the scope of a single iteration. These Test Plans should contain the information related to the specific Test Motivators (for example, a subset of requirements, risks), ideas, strategies, resources, 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 foresight into resource requirements and other logistics concerns. This master Test Plan 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 you avoid documenting specific detailed test information in the Test Plan.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process