QA: Templates
Four working templates: the requirement testability review, the release confidence report, the escaped-defect postmortem and the flake record.
Markdown. No sign-up, no email.
1. Requirement testability review#
One per requirement, before estimation.
| Field | Entry |
|---|---|
| Requirement | |
| Testable as written? | [Yes / No. If no, this is the whole finding] |
| How it would be tested | [If this cannot be written in a sentence, it is not testable] |
| Missing conditions | [What happens on empty, at maximum, on the second attempt, when it fails] |
| Contradictions found | [Reference the other requirement by number] |
| Acceptance criteria | [Specific enough that two people would agree whether it passed] |
| Verdict | [Accept / Send back / Accept with recorded gap] |
| Reviewed by |
"The system should be fast" is not a requirement. "95th percentile response under 400ms at 200 concurrent users" is. The difference is whether anyone can ever say it was met.
2. Release confidence report#
Generated per release. Shown here so the shape is fixed and the untested section can never be quietly omitted.
| Release | |
| Confidence | __% |
| Requirements covered | [n of n, with at least one test each] |
| Regression suite | [Pass or fail, count, and any newly failing] |
| Edge coverage on changed modules | [%] |
| Security cases | [Pass or fail. A failure stops the release] |
| Highest-risk module touched | [With its recent defect count] |
| 🔴 Not covered | [The section that matters. Name each gap and why it exists] |
| Accepted by | [A person. The score never accepts anything] |
| Untested risk accepted by | [A name per item, or the release does not go] |
3. Escaped-defect postmortem#
One per production defect. Thirty minutes, not a project.
| Field | Entry |
|---|---|
| Defect | |
| Found by | [Customer / monitoring / internal. "Customer" is its own finding] |
| Impact | [Who was affected, for how long] |
| Was there a test? | [If no: the coverage gap. If yes: continue] |
| Why did it pass? | [A wrong assertion is worse than a missing test and needs a different fix] |
| Which stage should have caught it? | [Requirement / unit / integration / security / manual] |
| Root cause | [The cause, not the symptom] |
| Test that would have caught it | [Write it. Reference it here. Do not close without this] |
| Pattern? | [Has this cause appeared before? If so, the fix is the cause, not this instance] |
4. Flake record#
| Field | Entry |
|---|---|
| Test | |
| First seen flaking | |
| Failure rate | [Runs failed out of runs attempted] |
| Quarantined on | [Out of the gating suite the same day] |
| Suspected cause | [Timing, shared state, external dependency, real race condition] |
| Fix or delete by | [Two weeks. Quarantine is not a destination] |
| Resolved how | [Fixed / deleted. A retry is not a resolution and hides the race condition underneath] |
Using these together#
The charter sets out what QA owns, the SOPs say when each is produced, the KPIs define what the postmortem feeds, and the workflows name who receives each output. A confidence report without the "not covered" section filled in is the one document here that actively misleads.