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
- Scope. Which products, components and interfaces the strategy governs, and which are governed elsewhere (a vendor, a platform team, a regulator).
- Product risk approach. The scoring scale (usually 5 by 5), the class thresholds, who scores, and the rule that links class to test depth.
- Test levels. Unit, integration, system and acceptance, with the owner, the environment and the typical entry condition for each.
- Test types. Functional, regression, performance, security, usability, compatibility, and the level at which each runs (the matrix above).
- Entry and exit criteria. The measurable conditions for starting and stopping each level, stated as defaults that plans can tighten but not loosen.
- Environments and data. The named environments, who provisions them, how test data is created and masked, and the refresh cadence.
- 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
| Aspect | Test strategy | Test plan |
|---|---|---|
| Scope | Organization or product line | One release, project or sprint |
| Lifetime | Years, revised on major change | Weeks to months, retired at release |
| Owner | Head of testing or QA lead | Test lead for the release |
| Level of detail | Rules and defaults | Features, dates, names, values |
| Risk content | Scoring method and thresholds | Actual scores per feature |
| Criteria | Default entry and exit conditions | Specific numbers for this release |
| Automation | Target share and tool categories | Which suites run, which are added |
| Length | 1 page | 1 to 10 pages |
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.
Print the strategy. If it does not fit on a single sheet at a readable size, it contains plan content or history. Move the plan content into plan templates and the history into a change log.
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.
Common questions
Is a test strategy the same as a test approach?
In ISO/IEC/IEEE 29119 the test strategy is organizational and the test approach is the implementation of that strategy in a specific project. In everyday use the terms overlap; what matters is having the standing rules written once and applied per release.
How long should a test strategy be?
One page, roughly 400 to 700 words, plus the level-by-type matrix. Longer strategies are almost always carrying plan content or process history that belongs elsewhere.
Who writes the test strategy?
The person accountable for testing across the product line: a QA lead, head of testing or principal tester. Development leads and product management review it, because the entry criteria bind them too.
Does an agile team need a test strategy?
Yes, and it is often easier for an agile team because the cadence is fixed. The strategy states the levels, the definition of done contribution, and the automation stance; each sprint applies it without a formal plan document.
What is a risk-based test strategy?
One in which the depth of testing per feature is decided by a product risk score rather than uniformly. The strategy fixes the scoring scale and thresholds; each release scores its own features.
How often should the strategy change?
Review yearly. Change when a major platform, regulatory or delivery-model shift happens, or when the annual review shows that a criterion needed exceptions on most releases.
Sources
- ISO/IEC/IEEE 29119-2:2021, Software testing, Part 2: Test processes
- ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation
- The TMMi model, TMMi Foundation
Further reading named in the text
- ISTQB, Certified Tester Advanced Level Test Management Syllabus (ISTQB, 2012)
- Rex Black, Managing the Testing Process, 3rd edition (Wiley, 2009)
- Lee Copeland, A Practitioner's Guide to Software Test Design (Artech House, 2004)
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.