 |
This artifact defines the strategic plan for how the test effort will be conducted against one or more aspects of the target system. |
Domains: Test |
|
Purpose
-
To convey the strategy to external stakeholders to gain their agreement to the approach
-
To convey the strategy to the internal members of the test team to enable a coordinated team effort
-
To convince management and other stakeholders that the approach is sound and achievable
|
Relationships
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Process Usage |
|
Description
Main Description |
The Test Strategy is used to identify testing principles and practices that will be applied in order to mitigate the
project risks, manage the testing risks, and identify any exposures. This artifact provides a common approach and
terminology for the testing effort. It also gives a general direction of where the testing is headed. It emphasizes the
importance of a team approach to testing.
|
Brief Outline |
The Test Strategy captures the following informational elements:
-
An explanation of the general approach that will be used. For example, explain how the primary approach is 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, and 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
For a specific software system in a given context (technology, domain, and so forth), it is likely that the strategy
can be reused (in whole or in part) in subsequent development lifecycles.
|
Illustrations
Tailoring
Impact of not having |
At the beginning of a project, it may be very difficult to embark on any test planning effort until details of the
solution start to emerge. To overcome this difficulty, a high-level strategy is developed to understand the testing
implications and verify the feasibility of testing the solution. Without a clear understanding of the testing
requirements, the best solution alternative may not be selected, and without appropriate testing, even the best
solution cannot be implemented with a high degree of assurance that it will function as expected.
If the test strategy is not produced, these issues need to be addressed by using test plans.
|
Reasons for not needing |
Usually for small projects, this artifact may not always be created. A single test strategy per project or per phase
within a project is recommended in most cases. Optionally, you might reuse existing strategies where appropriate, or
you might further subdivide the test strategies based on the type of testing that you are conducting.
|
Representation Options |
In certain testing cultures, the Test Strategy is considered an informal, casual work product, 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.
|
More Information
Concepts |
|
Guidelines |
|
Whitepapers |
|
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.
|
|