Artifact: Test Strategy
|
Defines the strategic plan for how the test effort will be conducted against one or more aspects of the target system. |
|---|---|
| Other Relationships: | Extends: Test Plan |
| Role: | Test Designer |
| Optionality/Occurrence: | Not considered optional. Occurs as one or more artifacts, typically either as a single, evolving strategy or may be multiple artifacts partitioned on various dimensions including development phase, type or testing and target test item. |
| Templates and Reports: | |
| Examples: | |
| UML Representation: | Not applicable. |
| More Information: |
Purpose
The main purpose of the Test Strategy is to:
- convey the strategy to external stakeholders to gain their agreement to the approach.
- convey the strategy to the internal members of the test team to enable a coordinated team effort.
A test strategy needs to be able to convince management and other stakeholders that the approach is sound and achievable, and it also needs to be appropriate both in terms of the software product to be tested and the skills of the test team.
Brief Outline
The Test Strategy captures the following informational elements:
- A explanation of the general approach that will be used. For example, explain how the primary approach be based on verifying the software against requirements or design specifications, exercising the software against fault models, subjecting the software to known attacks, or some other general approach.
- The specific types, techniques,
styles of testing that will be employed as part of the strategy, and for
each:
- An indication of the scope and applicability of the technique
- An outline of how the technique will be employed.
- An outline of what tools will be required to support the technique.
- The criteria for measuring the success and ongoing value of employing the technique
- An indication of the weaknesses or limitations of the technique and where any other techniques will cover this.
Note that for a specific software system in a given context (technology, domain and so forth), it is likely that the strategy can be reused all or in part in subsequent development lifecycles.
Properties
There are no UML representations for these properties.
| Property Name | Brief Description |
|---|---|
| Name | An unique name used to identify this Test Strategy. |
| Description | A short description of the contents of the Test Strategy, typically giving some high-level indication of complexity and scope. |
| Purpose | An explanation of what this Test Strategy represents and why it is important, usually the specific test types or assessment purpose it achieves. |
| Dependent Test and Evaluation Items | Some form of traceability or dependency mapping to specific elements such as individual Requirements that need to be referenced. |
Timing
Starting as early as Inception and continuing in each subsequent phase, the test strategy is readdressed continually as the project lifecycle evolves. Typically the strategy differs from phase-to-phase and is typically defined early in each phase (or at the end of the preceding phase).
Responsibility
The Test Designer role is primarily responsible for this artifact. The most important skill required to fulfill this responsibility is knowledge and experience of a broad range of testing types, techniques and styles. Good communication skills are important for creating this artifact, typically a reasonable proficiency in writing is necessary.
Tailoring
In certain testing cultures, the Test Strategy is considered an informal, casual artifact, whereas in others it is highly formalized and often requires external signoff. As such, the format and content should be varied to meet the specific needs of the project or organization.
As an alternative to formal documentation, you might choose to only record the elements of the Test Strategy 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.
