The release readiness checklist

Most release problems trace back to a decision nobody quite made: a risky change that got the same testing as a typo fix, a rollback that was assumed rather than tried, a known bug that shipped because no one said no.

This checklist is the order I work through before a release goes out. It doesn't need a QA team. It needs someone to ask each question and write down the answer.

1. Know what's in the release

Surprises in scope become surprises in production.

• Every change in the release is listed and linked to its ticket or pull request.
• Nothing has slipped in that wasn't planned, reviewed and tested.
• Database migrations, configuration changes and new feature flags are listed alongside the code changes.

2. Understand the risk

Test in proportion to what could go wrong.

• The riskiest changes are named: money, data, security, the busiest user journeys.
• The riskiest changes got the deepest testing, not the same depth as everything else.
• Anything not tested, and the reason, is written down.

3. Testing you actually believe

A green build only counts if the team trusts it.

• Automated checks pass, and none covering the risky areas are muted, skipped or quarantined.
• Someone has explored the risky changes by hand, beyond the scripted cases.
• The critical user journeys have been checked end to end.

4. Defects reviewed

Open bugs are decisions, not background noise.

• Every open defect touching this release has been looked at by someone who can decide.
• No serious defect ships unless someone has accepted it by name, with a plan.
• Known issues that customers might notice are ready for support and release notes.

5. Environments and data

Test where it behaves like production.

• Testing happened in an environment close enough to production to trust the results.
• Migrations have been rehearsed on realistic data, including how long they take.
• Production configuration and feature flag settings have been checked for this release.

6. The things that aren't features

Easy to forget, expensive to miss.

• Performance has been checked for anything that changes load, queries or payload sizes.
• Security-relevant changes, such as authentication, permissions and new inputs, have had a second look.
• Interface changes have had a basic accessibility check: keyboard, contrast, screen-reader labels.

7. Release mechanics

Plan the way out before you go in.

• The deployment steps are written down and someone other than the author could follow them.
• Rollback or roll-forward has been tried, not just assumed.
• Risky changes sit behind a flag or switch that can turn them off without a redeploy.
• The timing avoids peak trading and the end of the working week.

8. Know what broken looks like

You can't watch for what you haven't defined.

• Dashboards and alerts cover the changed areas, not only the system as a whole.
• The team knows which signals would mean the release has gone wrong.
• Someone is named to watch those signals for the first hours after release.

9. People and communication

Releases fail socially as often as technically.

• Whoever is on call knows what is going out and what to look for.
• Support has the release notes and the known issues before customers do.
• Any customer-facing change has its message ready.

10. Make the decision, and write it down

A release decision that only exists in a meeting can't be reviewed.

• Three lines recorded: what was tested and found, what wasn't tested and why, and who accepted the remaining risk.
• The person accepting the risk has the authority to do so.
• The decision is go, no-go, or go with named conditions, never "probably fine".

Where to go from here

If you can't tick section 10, start there. Writing down what was tested, what wasn't and who accepted the risk takes five minutes, and after a quarter it tells you more about your quality than any dashboard.

If release decisions in your team rest on one tired developer, that's the gap a fractional Head of Testing fills. A free 30-minute call is the easiest place to start.