# Test Plan

> 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.