Test Plan vs Test Strategy: Key Differences With Examples
A test strategy says how your organisation tests. A test plan says what one project will test, when and who does it. See both side by side, with a template and a worked example.
- Test strategy: the high-level approach to testing, usually shared by many projects and rarely changed.
- Test plan: the project-level document with scope, schedule, people, environments and risks.
- The plan is built from the strategy, so write the strategy first.
- Small teams can combine them in one short document, as long as the two questions are answered: how and what.
People mix up the two documents because both live in the “planning” part of testing and both are written by senior QA people. They answer different questions, though, and confusing them is how teams end up with a 40-page plan that nobody reads.
This guide explains test plan vs test strategy in plain terms. Once you know them, write better cases with our guide on how to write test cases.
The short answer
A test strategy answers “how do we test here?” It sets principles: which test levels you use, how much you automate, which tools, how defects are handled. A test plan answers “what are we testing in this release, who does it and by when?“
Think of a strategy as the company’s cooking style and a plan as tonight’s menu, shopping list and timetable.
What a test strategy contains
- Test objectives and the quality attributes that matter (speed, security, accessibility).
- Test levels and types: unit, integration, system, acceptance, regression.
- The automation approach and the tools allowed. See our comparison of the best test automation tools.
- Defect handling: severity levels, triage rules, tooling.
- Test data and environment principles.
- Metrics you track, such as defect leakage or automation coverage.
- A risk-based approach for deciding where to test deeper.
What a test plan contains
- Scope: features in and out of testing, and the build or release under test.
- Test approach for this project, referring to the strategy instead of repeating it.
- Schedule and milestones.
- Roles, responsibilities and resources.
- Test environments and test data needs.
- Entry and exit criteria: when testing may start and when it is done.
- Risks, assumptions and how you will handle them.
- Deliverables: test cases, reports, sign-off.
Test plan vs test strategy side by side
| Aspect | Test strategy | Test plan |
|---|---|---|
| Question answered | How do we test? | What, when and by whom? |
| Level | Organisation or product line | One project or release |
| How often it changes | Rarely | Often, as scope and dates move |
| Typical owner | QA manager or test architect | Test lead or QA lead for the project |
| Detail | General principles and standards | Specific features, dates, people |
| Source | Company policy and past experience | Derived from the strategy and the requirements |
Tip: if a sentence would still be true on the next project, it belongs in the strategy. If it names a release, a date or a person, it belongs in the plan.
A worked example: online checkout
Imagine a shop that is adding a new checkout page.
From the strategy: “Every release gets automated regression on the three main browsers, API tests run on each commit, and critical defects block the release.”
In the plan for this release: “Test the new checkout page and the coupon feature. Out of scope: the admin dashboard. Two testers, test environment STG-2, start when the build passes smoke tests, finish when no open critical defects remain. Risk: the payment sandbox is down on Fridays.” For a good first check on any new build, see smoke testing vs sanity testing.
A short test plan template
You do not need a heavy document. This outline fits one page and covers what stakeholders need.
1. Release and scope (in / out)
2. Approach (link to the test strategy)
3. Schedule and milestones
4. Team and responsibilities
5. Environments and test data
6. Entry and exit criteria
7. Risks and mitigations
8. Deliverables and sign-offOnce the plan is set, protect each release with a regression testing checklist.
Common mistakes
- Copying the strategy into every plan. Link to it instead.
- A plan with no exit criteria. Nobody can say when testing is done.
- A strategy nobody has read. Keep it short and put it where the team works.
- Writing the plan once and never updating it. Scope changes, so the plan must too.
Final thoughts
Keep the strategy stable and the plan alive. Write the strategy once, review it twice a year and create a lean plan for every project that points back to it.
Frequently asked questions
What is the main difference between a test plan and a test strategy?
A test strategy is the high-level approach to testing, shared across projects. A test plan applies that approach to one project, with scope, schedule, roles and risks.
Which comes first, the test plan or the test strategy?
The strategy comes first. The test plan is derived from it and from the project requirements.
Who writes the test strategy and the test plan?
A QA manager or test architect usually writes the strategy. A test lead writes the plan for a specific project, often with input from developers and product owners.
Can a small team use one document for both?
Yes. A short combined document works if it clearly separates the general approach from the project-specific scope, dates and people.
Do agile teams still need a test plan?
Yes, but a lighter one. A one-page plan per release or sprint, with scope, risks and exit criteria, keeps everyone aligned without slowing the team.
Keep learning
Need help with testing, WordPress or SEO?
We help teams ship better software and grow their sites. Tell us what you are working on and we will suggest a clear next step.