• Test Designer

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.

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.

• Exploratory Testing
• Structure Testing
• Usability Testing
• Test Strategy

• Testing Embedded Systems