Test Plan Template
A fill-in test plan for a release — what is being verified and what is deliberately not, environments and data, entry and exit criteria, risk-based priorities, and who decides to ship.
Markdown. No sign-up, no email.
A test plan exists to make two things explicit before anyone is under pressure: what "tested" means for this release, and who decides to ship when the answer is imperfect. Everything else is supporting detail.
Release / feature: _______________ Owner: _______________ Date: _______ Target release date: _______
1. Scope#
What is being tested: _______________
What is explicitly NOT being tested, and why: _______________
The second line is the one that prevents an argument later. Untested areas are acceptable; untested areas that everyone assumed were covered are not.
Change summary — what is actually different in this release: _______________
2. Risk-based priorities#
Test where failure would be worst, not where testing is easiest.
| Area | Likelihood of defect | Impact if it fails | Priority | Depth of testing |
|---|---|---|---|---|
| high / med / low | high / med / low | 1-3 |
The three things that must not break: _______________
3. Environments#
| Environment used | |
| How it differs from production | |
| Integrations: real or stubbed | |
| Who else is using it during this window |
🔴 List the differences from production honestly. Most "it worked in test" incidents trace to a difference someone knew about and did not think mattered — a smaller dataset, a stubbed dependency, different configuration, a single instance instead of several.
4. Test data#
| Source of test data | |
| Contains personal data | yes / no |
| If yes: masked or synthetic? approved by? | |
| Covers realistic volume | yes / no |
| Covers awkward real cases (long names, unusual characters, edge dates) | yes / no |
Test data that is too clean is the most common reason a defect reaches production. Real data is messy in ways nobody invents.
5. What will be run#
| Type | Included | Automated | Who | Notes |
|---|---|---|---|---|
| Unit | ||||
| Integration | ||||
| End-to-end (key journeys) | ||||
| Regression | ||||
| Performance | ||||
| Security | ||||
| Accessibility | ||||
| Compatibility (browsers, devices) | ||||
| Exploratory |
Key user journeys that must pass: _______________
Leave room for exploratory testing. Scripted tests confirm what you thought of; exploratory testing finds what you did not, and it consistently finds the more interesting defects.
6. Entry criteria#
- [ ] Build deployed to the test environment
- [ ] Test data loaded
- [ ] Smoke test passes
- [ ] Known blocking defects from the previous cycle resolved
7. Exit criteria — agree these BEFORE testing starts#
| No open defects of severity | |
| Maximum open medium defects | |
| Key journeys passing | all / ___% |
| Automated suite | green |
| Performance within | |
| Who signs off |
Agreeing exit criteria under deadline pressure produces criteria shaped to whatever the current state happens to be. Agree them while the answer is still hypothetical.
8. Defect handling#
| Severity | Definition | Response |
|---|---|---|
| Critical | fix before release | |
| High | ||
| Medium | ||
| Low | log, schedule |
Who arbitrates severity disagreements: _______________
9. Regression risk#
What this change could break that is unrelated to it: _______________
Shared components touched: _______________
Areas with a history of breaking: _______________
10. Sign-off#
| Name | Date | Decision | |
|---|---|---|---|
| Testing complete | |||
| Known issues accepted by | |||
| Go / no-go |
Known issues shipped, with reasons: _______________
Shipping with known defects is normal and legitimate. Shipping with known defects that were never written down is how the same problem is rediscovered by a customer three weeks later.