A QA strategy is the standing set of decisions about how a team protects quality. It names the risks that matter most, the levels and kinds of testing that answer each one, the owner of every check, the evidence a release needs, and what is deliberately left untested. Every test plan inherits it.
What does a QA strategy decide?
A strategy exists because testing everything is off the table, and that principle sits in the syllabus testers are certified against.
The ISTQB Foundation Level syllabus (v4.0.1, September 2024) describes seven testing principles. The second is “Exhaustive testing is impossible”, and the sixth, “Testing is context dependent”, adds that no single approach to testing applies everywhere. Source: ISTQB Foundation Level syllabus, section 1.3.
A QA strategy is therefore a record of five choices, each one a question somebody answers in writing.
| Decision | The question it answers | What the strategy records |
|---|---|---|
| Risks | Where would a defect cost the most? | The standing risks: the failures that would cost the most, ranked (risk-based testing) |
| Levels and kinds of testing | Which testing answers each risk? | The levels the team runs, and the split between scripted checks, automation and exploratory testing |
| Ownership | Who runs each check, and who may waive it? | A named role for every check and gate |
| Release evidence | What must a release show before it ships? | The conditions for release readiness and the proof behind each |
| Exclusions | What is deliberately not tested? | The areas, browsers and depths left out, each with a reason and the person who accepted it |
Risk comes first because the other four rows are answers to it. A team that has not ranked its risks cannot say why the checkout has a full suite and the settings page a single check.
The last row is the easiest to leave out. Exhaustive testing is out of reach, so every team skips something, and an exclusion written down with a reason is a risk somebody accepted. One that was never written looks like coverage until a customer finds the gap.
What goes in a QA strategy document?
The written strategy turns those five decisions into sections a new joiner can read in one sitting. Each holds a standing rule and a trigger that sends it back for review. The test strategy template is the copyable document for the testing sections, with a filled-in example.
| Section | What it records | Reviewed when |
|---|---|---|
| Scope and quality goals | The products covered, and what quality means as outcomes a user would notice | The product or its audience changes |
| Standing risks | The failures that would cost the most, ranked, with the date of the last review | A product change adds a risk, or an escaped defect shows the ranking was wrong |
| Test levels and kinds | The levels that run, the tools that run them, and where test automation stops and a person takes over (manual vs automated testing) | A level or tool is added or dropped |
| Roles and ownership | Who owns each check, who reads incoming reports, who signs a release | Somebody joins, leaves or changes role |
| Environments and data | Which environments exist, what each is for, and where test data comes from | An environment is added or retired |
| Gates and criteria | The definition of done, each quality gate, and the standing entry and exit criteria | A gate lets an escape through |
| Release evidence | The conditions a release must meet, the severity scale, and what a defect report must carry | A release ships with a condition unmet |
| Measures | The few numbers that judge the strategy, with test coverage stated per risk | A number stops changing any decision |
| Exclusions | What is not tested, why, and who accepted it | Usage or a contract shifts |
The same ISTQB syllabus describes five test levels (component, component integration, system, system integration and acceptance) and groups test levels and test types into four testing quadrants. Source: ISTQB syllabus, sections 2.2.1 and 5.1.7.
A strategy names the levels it runs and says why the others are absent. The agile testing quadrants are a quick check for a blind side, since a strategy made only of automated component tests holds nothing that critiques the product the way a user would.
How is a QA strategy different from a test plan and a QA process?
The three get merged because a small team keeps them in one file. They answer different questions and change at different speeds.
| QA strategy | Test plan | QA process | |
|---|---|---|---|
| Question | How does this team protect quality, release after release? | What is tested in this release, by whom and by when? | Which question is asked at each handover, and who answers it? |
| Covers | Every product and release the team ships | One release or project | Every piece of work, every day |
| Changes | Rarely, on a trigger | Whenever the release changes | When a gate lets something through |
| Owner | Whoever leads quality | The test lead for the release | The named owner of each gate |
The ISTQB syllabus fixes the order of the first two columns. Among the purposes of a test plan it lists that the plan “demonstrates that testing will adhere to the existing test policy and test strategy (or explains why the testing will deviate from them)”. The plan applies the strategy to one scope, and test plan vs test strategy keeps the full contrast. The test plan template is filled in once per release, at the planning step of the software testing life cycle.
The process is the strategy on an ordinary working day, the gates between steps and the person who answers each one, argued in a QA process is a set of gates. The strategy decides that a gate exists and what it protects.
“Test strategy” and “QA strategy” are often used for the same document. Where a team separates them, the test strategy is the testing half, and the QA strategy adds what sits outside a test run, such as code review, the definition of done and the measures that judge the result.
How does a software quality assurance plan relate to a QA strategy?
A software quality assurance plan, shortened to SQAP or QA plan, carries the same decisions in a formal wrapper. It is written for one project, in the cases where a client, a contract or a regulator asks for a recognised format, and it adds what an outside reviewer needs, such as the standards followed, the records kept and who approves them.
IEEE 730-2026, the IEEE Standard for Software Quality Assurance Processes, was published on 21 August 2026. It supersedes the 2014 edition, which the IEEE Standards Association lists as inactive since 27 March 2025. Source: IEEE SA, IEEE 730-2026.
The standard has moved from the document to the activity. The 2002 edition was titled the IEEE Standard for Software Quality Assurance Plans, and its abstract says it “specifies the format and content of software quality assurance plans”. From 2014 the title reads Software Quality Assurance Processes, and the current abstract establishes requirements for “initiating, planning, controlling, and executing” those processes on a software development or maintenance project. A page citing IEEE 730-2014 as current is out of date.
For the testing documents themselves, ISO/IEC/IEEE 29119-3:2021 supplies test documentation templates for any organisation, project or testing activity, according to its published abstract.
A team with no such obligation can treat the QA strategy as its working document. Where a formal plan is required, the strategy is written first and the plan cites it, adding the project’s scope, schedule and records.
What does a QA strategy look like for a small web team?
The example is an illustrative team of six that ships a web application every week with no dedicated tester. Its strategy is one table ranked by risk, and every row names an owner and the evidence a release has to show. A team this size can run on a definition of done until two people disagree about what it means, and this table is what it writes then.
| Risk, in rank order | Testing that answers it | Owner | Evidence the release needs |
|---|---|---|---|
| 1. Checkout takes the wrong payment | Unit and integration tests on totals and tax, and an end-to-end test of the paid path on every pull request | The developer who made the change | A passing pipeline on the release commit |
| 2. A change breaks a page nobody opened | The regression suite before each release, and an exploratory session on the changed area | The release owner for the week | Suite results and session notes on the release ticket |
| 3. Pages are slow on phones | Core Web Vitals measured on real page loads | The front-end lead | Largest Contentful Paint within 2.5 seconds and Interaction to Next Paint of 200 milliseconds or less at the 75th percentile of page loads, the “good” thresholds on web.dev |
| 4. A page cannot be used by keyboard or screen reader | Automated accessibility checks on every build, and a manual keyboard pass on new components | The component’s designer and developer | Changed pages conform to WCAG 2.2 at Level AA |
| 5. A customer’s report cannot be reproduced | Reports sent through the feedback widget and read within an agreed time | The triage owner for the week | Every open report shows the page, browser and viewport it came from |
| Not tested | Browsers outside the supported list, and legacy admin screens beyond a smoke test | Accepted by the product owner | The exclusion and its reason, written in the strategy |
Rows three and four borrow thresholds from outside the team, Google’s published guidance and a W3C Recommendation, and a team may set its own.
Row five is where release evidence includes what a reporter or tester actually saw, and its evidence column is the one part of the table Notarus supplies. Its widget captures the page the reporter is looking at, and console logs, network activity, page URL, viewport and browser travel with the report (evidence capture). Capture settings, browser support and performance budgets decide what is available, and a report can still be sent without evidence. How soon a report is read stays with the triage owner.
The table is judged after release. Escaped defects are counted by area and set against the ranking (testing metrics covers which numbers to trust), beside the share of deployments that needed immediate intervention, which DORA calls the change fail rate.
Related terms and guides
- Test plan vs test strategy: the standing document and the per-release one
- Risk-based testing: ranking by likelihood and impact
- Test automation: checks that run identically on every build
- Manual vs automated testing: splitting effort between person and script
- Entry and exit criteria: what opens and closes a test phase
- Quality gate: a pass or fail checkpoint for every change
- Definition of done: the checklist all work has to meet
- Release readiness: what a go or no-go decision inspects
- Exploratory testing: unscripted testing aimed by a charter
- Test coverage: how much behaviour the tests verify
- Escaped defect: a defect that reached production uncaught
- Exhaustive testing: why testing everything is out of reach
- Agile testing quadrants: four groups of tests by audience and purpose
- Test case design: deriving cases with a technique
- Software testing life cycle: the phases of testing in a release
- A QA process is a set of gates, not stages: the gates and who answers each
- Three QA best practices carry a small web team: where a team without a QA department starts
- Testing metrics that count activity prove nothing: the numbers that judge a strategy
- QA team structure is who reads the reports: the ownership column in full
- QA in agile happens at three sprint boundaries: where checks sit in a sprint
- Improve software quality by classifying escapes: reading escapes before spending on prevention
- Match a test environment where the bugs live: what the environments section settles
- How to write test cases worth a second run: the standard a strategy sets for a case
