A release checklist you can work top to bottom on release day

Six stages from entry criteria to post-release, with every item carrying the reason it earns its place and the genuinely blocking ones flagged. Tick items as you go, then download the checklist as CSV for your release runbook.

30checks/6stages/11blocking items/FreeCSV download

All 30 checks, grouped by when they apply

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated 20 August 2026

0 of 30 complete

Ticking is local to your browser and is not saved or sent anywhere.

Before testing starts

Entry criteria. Running a cycle against a build that fails these wastes the cycle.

Release scope is written down and agreed, including what is explicitly out of scopeThe out-of-scope list is what protects the team later when someone asks why an area was not covered.
Build is deployed to the test environment and the version is recordedBlockingEvery defect raised in this cycle needs to reference a build. Without it, triage starts with a question.
Smoke suite passes on the deployed buildBlockingIf core paths are broken there is nothing to gain from deeper testing until a new build lands.
Test data is seeded and any third-party sandbox is reachableData and sandbox problems discovered mid-cycle cost more than the ten minutes it takes to check first.
Exit criteria are agreed with the person who will approve the releaseCriteria agreed in advance are a standard. Agreed during crunch, they are whatever the deadline allows.

Functional coverage

All High priority test cases executed and passedBlockingThis is the coverage claim the release recommendation rests on.
New features verified against their acceptance criteria, not against the implementationTesting what was built rather than what was asked for is how a feature passes QA and fails UAT.
Every fixed defect in this release retested on the current buildBlockingRetest takes priority over regression. There is no value in regression on a build where the fix did not work.
Regression executed on modules affected by the change, scoped by impact analysisImpact analysis with a developer usually shrinks or redirects the suite more accurately than guessing.
Negative and boundary paths covered on new inputs, not just happy pathsBoundary conditions are where comparison logic lives, which is where off-by-one defects hide.
Exploratory session run against the highest-risk change, with notes recordedScripted tests confirm known behaviour. Exploratory work is what finds the defect nobody anticipated.

Data and integrations

Data migrations dry-run against a production-like datasetBlockingMigrations that pass against a small seed routinely fail on production volume, encoding or legacy edge records.
Backward compatibility verified for API consumers still on the previous versionA removed field or tightened validation breaks clients silently, and they usually find out before you do.
Third-party integrations verified, including their failure behaviourA timeout or 500 from a provider must degrade gracefully rather than take down the page.
Idempotency verified on any endpoint that creates or chargesBlockingNetworks retry. A non-idempotent payment or order endpoint eventually double-charges someone.

Non-functional

Performance measured against the agreed target at expected concurrencyA percentile target at a stated load, not an average, because the average hides the tail users actually feel.
Authentication and authorisation verified on every new or changed endpointBlockingObject level authorisation, where an ID can be changed to reach another user data, is the most common real API vulnerability.
No secrets, tokens, personal data or stack traces exposed in responses, logs or URLsBlockingVerbose logging added during development is the usual way tokens end up in a log everyone can read.
Accessibility checked on new or changed screens: keyboard, labels, focus order, contrastA screen that cannot be completed with a keyboard locks people out of the product entirely.
Verified across supported browsers and at mobile, tablet and desktop breakpointsResponsive breakage and browser-specific behaviour are cheap to catch here and expensive to catch in support.

Release readiness

No open Critical or High defects, or each has documented, accepted risk with an ownerBlockingShipping with known defects is a legitimate business decision. Shipping without anyone owning that decision is not.
Rollback plan exists and has been tested, not just writtenBlockingAn untested rollback is a hope. The moment you need it is the worst moment to discover it does not work.
Feature flags configured and their default state confirmed for productionA flag defaulting the wrong way ships a half-finished feature to everyone the moment the deploy lands.
Monitoring and alerting cover the new paths, with thresholds agreedAnything not fully verified pre-release needs to be observable post-release, or you learn about failures from customers.
Support and customer-facing teams briefed on what is changing and known issuesSupport hearing about a change from a customer is a preventable and entirely self-inflicted cost.
Test summary report issued with a clear release recommendation and residual riskThe decision maker needs a recommendation, not a table of pass counts they have to interpret.

After release

Smoke test executed against production immediately after deployBlockingConfiguration and environment differences mean a build that passed in staging can still fail on the first production request.
Monitoring watched through the first peak traffic periodLoad-dependent failures such as pool exhaustion appear at peak, not at deploy time.
Any escaped defect logged with a root cause on the process, not the personAn escape is feedback on where coverage was missing. An RCA that names an individual produces silence next time.
Regression suite updated with a case covering anything that escapedThe same class of defect should not be able to escape twice.

How To Use This

Treat blocking items differently from the rest

A checklist where every item is equally important gets skimmed. These four habits keep it useful past the second release.

Blocking means blocking

Eleven items here should stop a release. If your team routinely ships past them, either the item is wrong or the gate is decorative.

Cut what does not apply

No data migration this release means that item is not applicable, not unchecked. A permanently unticked box trains people to ignore the list.

Assign owners, not just ticks

Rollback plan and monitoring usually belong to engineering rather than QA. A checklist without owners quietly becomes the tester problem.

Add what escaped last time

Every escaped defect is evidence of a missing check. Adding one item per escape is how a checklist earns its authority.

Why This Order

Ordered by release day, not by discipline

Most published release checklists group items by discipline: all the functional checks, then all the security checks, then performance. That reads well and works badly, because on release day you are moving through time rather than through disciplines. This list is ordered by when each gate applies, so it can be worked top to bottom.

The reason attached to each item is deliberate. A checklist without reasons gets followed while the person who wrote it is still around and abandoned afterwards, because nobody can tell which items were considered and which were copied. Stating why an item exists also makes it possible to argue that it does not apply to you, which is a feature.

The two stages teams most often skip entirely are entry criteria and post-release. Skipping entry criteria means burning a cycle on a build that was never testable. Skipping post-release means the smoke test that would have caught a production configuration difference never runs, and you learn about it from a customer instead.

One deliberate omission: there is no sign-off box. QA advises on risk and the accountable owner decides, so what belongs at the end is a recommendation with residual risk documented, not a signature that quietly transfers the decision to the tester.

Suggest an improvement

Releases feeling risky?

QAble runs release cycles for client products end to end, from entry criteria through post-release verification and escaped-defect analysis.

Managed QA services

More templates and checklists

View all

Sources

ISTQB Glossary standard definitions for the testing terms used here.
WCAG 2.2 the success criteria behind the accessibility cases.
OWASP ASVS verification requirements for authentication, session and access control.