Test strategy: the one-page version that actually gets used

Headings

7

Length

1 page, 400 to 700 words

Revision cadence

yearly or on major change

Test levels named

4: unit, integration, system, acceptance

Typical automation stance

70 / 20 / 10 by level

Feeds

every test plan and sprint plan

What a strategy decides

A strategy answers the questions that stay the same from release to release. Which levels of testing exist and who owns each. Which types of testing run at which level. What has to be true before testing starts and before it stops. Where testing runs. How much is automated and at which level. Once those are written down, a test plan for a release only has to fill in the specifics: features, dates, people, and the criteria values for that release.

The strategy is also where the organization commits to a risk approach. If the strategy says depth of testing follows product risk score, then every plan inherits risk-based testing and nobody argues about whether the login page needs the same attention as the payment page.

The seven headings on one page

1. Scope. Which products, components and interfaces the strategy governs, and which are governed elsewhere (a vendor, a platform team, a regulator).
2. Product risk approach. The scoring scale (usually 5 by 5), the class thresholds, who scores, and the rule that links class to test depth.
3. Test levels. Unit, integration, system and acceptance, with the owner, the environment and the typical entry condition for each.
4. Test types. Functional, regression, performance, security, usability, compatibility, and the level at which each runs (the matrix above).
5. Entry and exit criteria. The measurable conditions for starting and stopping each level, stated as defaults that plans can tighten but not loosen.
6. Environments and data. The named environments, who provisions them, how test data is created and masked, and the refresh cadence.
7. Automation stance. The target share by level, the categories of tool (unit runner, API client, browser driver, CI server), and the rule for what gets automated first.

Strategy versus plan

Writing the entry and exit criteria

Criteria are where a strategy earns its keep. Write them as defaults with numbers. Entry to system test: the build passed its unit and integration suites, the smoke test passed in the system environment, and the release notes list the included changes. Exit from system test: 100 percent of high-risk and 95 percent of medium-risk requirements have at least one passed test, no open severity 1 defects, at most three open severity 2 defects with documented workarounds, and the regression suite passed at 98 percent or above with every failure triaged.

Plans may tighten these numbers for a risky release. They may not loosen them without a written exception approved by the person who owns the strategy. That single rule prevents the slow drift where each release ships with slightly lower criteria than the last.

The automation stance

State the target split by level and the reason. A common stance is 70 percent of automated checks at unit level, 20 percent at service or API level and 10 percent through the user interface, following the test automation pyramid. Then state the priority rule: automate regression checks for high-risk features first, then anything executed more than three times per release, then the rest only if the maintenance cost is justified. Name tool categories, not products, so the strategy survives a tool change.

Keeping the strategy alive

Review the strategy once a year and whenever a major change lands: a new platform, a regulatory requirement, a shift to continuous delivery. Each review compares the exit criteria with what releases actually achieved. If every release needed an exception on the same criterion, either the criterion is wrong or the process is, and the review decides which. Publish the strategy where plans are written, link every plan back to it, and record deviations in the plan rather than silently rewriting the strategy.

A strategy that is used shows up in the language of the team. When a developer asks which level should catch a particular defect and the tester can point to the matrix, the strategy is doing its job. When the answer is that it depends on who is free, the document is decorative.

This guide is part of the test management hub. It is best read alongside how to write a test plan and risk based testing, which cover the neighbouring questions.

Work it out