Test Plan & Test Strategy
So far in this track you've learned how to design test cases, execute them, and report the bugs you find. But before any of that happens on a real project, someone has to decide what gets tested, how, by whom, and on what schedule. That's the job of two related but distinct documents: the Test Strategy and the Test Plan. People often use the words interchangeably in casual conversation, but on a real team they answer different questions and usually live at different levels of the organization.
Test Strategy vs Test Plan
| Aspect | Test Strategy | Test Plan |
|---|---|---|
| Scope | Whole organization or whole product line | One release, feature, or sprint |
| Lifespan | Written once, revisited rarely (e.g. yearly) | Written fresh for each release |
| Owner | QA lead / test manager / architect | Test lead assigned to that release |
| Content | Testing types used company-wide, tools standard, general risk approach, automation policy | Specific scope, schedule, named resources, entry/exit criteria, environment for this release |
| Example question it answers | "Do we do performance testing at all, and with what tool?" | "Will performance testing be part of the RecipeBox v2.0 release, who runs it, and by what date?" |
In practice: RecipeBox's engineering org might have one Test Strategy document that says "we do functional, regression, and UAT testing manually; we use exploratory testing for new UI; we don't currently do automated performance testing." Every individual release — v1.5, v2.0, v2.1 — then gets its own Test Plan that applies that strategy to specific, dated, scoped work.
The Standard Test Plan Sections
Test plan templates vary between companies, but almost all of them include some version of these sections. Below is each section explained, then applied to a worked example: a hypothetical Test Plan for the "RecipeBox v2.0" release.
1. Objective
What this round of testing is trying to accomplish, in a sentence or two.
2. Scope (In-Scope / Out-of-Scope)
Exactly what will and will not be tested. This is one of the most valuable sections precisely because it prevents arguments later about what "should have" been caught.
| In scope | Out of scope |
|---|---|
| New Search Recipes screen (search by title) | Search by ingredient (planned for v2.1, not built yet) |
| Redesigned Add/Edit Recipe form and all its fields | Backend admin dashboard (internal tool, tested separately) |
| Regression pass on Login and Recipe List screens | Load/performance testing at scale (no strategy for it yet — see Test Strategy) |
| Functional testing on Android only (current supported platform) | iOS (not yet built) |
3. Test Approach
Which testing types and techniques will actually be used, and why.
4. Entry Criteria & Exit Criteria
Entry criteria are the conditions that must be true before testing can start. Exit criteria are the conditions that must be true before testing is considered done and the release can ship. Both exist so nobody has to argue in the moment about whether testing is "ready to begin" or "good enough to stop" — the answer was already agreed in advance.
| Entry Criteria | Exit Criteria |
|---|---|
| Build v2.0-rc1 deployed to the test environment | 100% of planned test cases executed |
| Requirements for Search and Add/Edit Recipe signed off | No open Critical or High severity bugs |
| Test cases for Search and Add/Edit written and reviewed | All Medium/Low bugs triaged and either fixed or explicitly deferred with sign-off |
| Test environment and test data (sample recipes, test accounts) ready | Regression suite passed on Login and Recipe List |
5. Resources
Who is doing the testing, and what they need.
6. Schedule
Dates. Even a rough schedule keeps testing from being an afterthought squeezed into the last two days before release.
| Activity | Dates |
|---|---|
| Test case writing & review | Days 1–2 |
| Functional testing (Search, Add/Edit Recipe) | Days 3–5 |
| Bug fixing & re-test cycle | Days 6–7 |
| Regression pass | Day 8 |
| UAT with beta users | Days 9–13 |
| Sign-off & release | Day 14 |
7. Risks
What could threaten the testing effort or the release itself, and what will be done about it.
| Risk | Mitigation |
|---|---|
| Search feature depends on a new backend endpoint that's still being finalized | Start functional testing with mocked responses; re-test against the real endpoint as soon as it's ready |
| Only 2 testers available for a feature-heavy release | Prioritize Search and Add/Edit Recipe first; regression on Login/Recipe List can run with a smaller, risk-based subset if time runs short |
| Beta users may not respond within the UAT window | Recruit 5 users instead of the minimum needed (3), and start recruiting a week early |