Skip to content

Quality Checklist

At a glance

  • Purpose: Turn the quality plan's commitments into a short, checkable list used at a specific moment — review, release, or handover — so nothing depends on memory.
  • Use it when: Attached to a gate: pre-review, pre-release, or handover. A checklist with no moment attached is not used.
  • Owner: Whoever runs the gate; the evidence column is filled by the person who did the checking.
  • Related: Module 09 · Lab 20

How to use this template

  1. Name the moment at the top. One checklist per gate; combining gates produces a list nobody completes honestly.
  2. Write each item so it can be answered Yes, No, or Not applicable — and require evidence for Yes. A tick with no evidence is a hope.
  3. Keep it short enough to finish. Beyond roughly fifteen items, people start ticking without checking, which is worse than no checklist because it creates false assurance.
  4. Treat any No as a decision, not a delay: who accepts it, and what the consequence is.
  5. Review the checklist after each use. Items that never catch anything should be removed, and items that would have caught a real defect should be added.

Field descriptions

Field What goes in it Watch out for
Gate The moment this checklist applies to A general-purpose list
Item One verifiable condition Compound items with "and"
Evidence Where the proof is "Discussed"
Result Yes / No / N/A Blank rows, which hide skipped checks
Checked by A person "The team"
Accepted gap Who accepts a No, and with what consequence Unrecorded gaps

Blank template

# Quality Checklist — [Gate name]

| | |
| --- | --- |
| **Gate** | [e.g. Pre-release to production] |
| **Version of the deliverable** | [Build or release identifier] |
| **Date and checker** | [YYYY-MM-DD, name] |

## Checklist

| # | Item | Evidence required | Result | Checked by |
| --- | --- | --- | --- | --- |
| 1 | Every planned change for this release is present in the build | Release manifest | | |
| 2 | No P1 or P2 defect is open against this release | Defect log extract | | |
| 3 | The definition of done is met for every item in the release | Review records | | |
| 4 | Acceptance scenarios have been run on realistic data | Test record with data volume | | |
| 5 | The performance target has been measured under agreed conditions | Test result | | |
| 6 | Backup, restore, and rollback have been tested | Test record | | |
| 7 | Access control and data-protection requirements are verified | Review or test evidence | | |
| 8 | Operator and user documentation matches the build | Documentation link | | |
| 9 | Known limitations are documented and accepted | Accepted gaps table below | | |
| 10 | The people who support the release have been briefed | Briefing record | | |

## Accepted gaps

| Item # | Why it is not met | Consequence | Accepted by | Date |
| --- | --- | --- | --- | --- |

Worked example

From Lab 20, the pre-release checklist for an internal release, invented for teaching:

# Item Result Note
1 Every planned change present in the build Yes
2 No P1 or P2 defect open No D-014 (list screen timeout) is open at P2
3 Definition of done met for every item No Two items failed criterion 3 or 7
4 Acceptance scenarios run on realistic data Yes 1,200 records — the run that found D-014
5 Performance target measured No Scheduled for after the fix
6 Backup, restore, and rollback tested Yes
7 Access control verified Yes
8 Operator documentation matches the build Yes
9 Known limitations documented Yes
Item # Why it is not met Consequence Accepted by Date
2 D-014 fix is in test, not yet verified Staff would experience a timeout during the admission window Sponsoring department 2026-04-14
5 Cannot be measured on the current build No performance evidence at release Sponsoring department 2026-04-14

The honest outcome here is not a clean sheet — it is a recorded decision to release with two known gaps, taken by the person who owns the consequence. That is what a checklist is for: it converts silent omissions into visible, owned decisions, and if the answer had instead been "defer the release", the same table would have justified that too.

Common mistakes

  • A general checklist used at every gate. The items that matter at review and at release are different, and a merged list is answered from memory.
  • Ticks without evidence. This is the failure mode that makes checklists actively harmful.
  • Compound items. "Tests pass and documentation is updated" gets ticked when only one is true.
  • Too long. Beyond fifteen items, honest completion stops.
  • No route for a No. If the only options are tick or block, people tick.
  • Never revised. A checklist that has never been updated either is perfect or is not being read.
  • Treating it as the quality plan. The plan sets the strategy; the checklist verifies one moment of it.