Checklist
Website launch checklist
A website launch checklist covering the checks that actually block a go-live: functionality, cross-browser, forms, analytics, redirects, and rollback.
A QA checklist that ends in a release decision
A release QA checklist covers seven groups: the entry conditions before testing starts, functional checks against the acceptance criteria, regression, compatibility, non-functional checks such as performance and accessibility, data and integrations, and release readiness. Its purpose is to end in a decision, so the readiness group has to name which severities block rather than asking for zero defects.
- Checklist
- 8 groups
- 28 checks
- Updated
A QA checklist is not a test plan. A plan describes how a release will be tested and is written once per release; a checklist is what somebody works through to decide whether this build can go, and it is the same list every time. Keeping them separate is what stops the checklist growing into a document nobody completes.
In the checklist
- Before testing starts 4
- Functional 4
- Regression 3
- Compatibility 3
- Non-functional 4
- Data and integrations 3
- Release readiness 4
- The release decision 3
QA checklist, ready to copy
Copy it as it is. There is no email step, and nothing on this page is behind one.
Before testing starts
Functional
Regression
Compatibility
Non-functional
Data and integrations
Release readiness
The release decision
that ships, by the person named, before release. Nothing else reopens.
Items, owner, and who re-checks:
checked again:
Decided by:
Name:
Role:
Build:
Date:
The list below is organised so that each group can fail independently and say something specific about the build. The last group is the one that turns the exercise into a decision rather than a report.
What each group is for
Scroll the table sideways for the examples.
| Group | Why it earns its place | Example |
|---|---|---|
| Before testing starts | The build is deployed, its version is recorded, a smoke test has passed and the environment is in a known state. Testing a build that cannot load its main paths spends a day producing findings about the deployment. | Build 2.14.0 on staging, smoke suite green, database reset to the August seed. |
| Functional | Every acceptance criterion in the release checked against this build rather than against a description of it, and every defect marked fixed confirmed on the same build with a regression test behind it. Checking features instead of criteria is how a release passes QA and then fails acceptance; confirming a fix without pinning it is how the same defect returns three releases later and is found by a customer. | All nine criteria for the invoicing story verified, two behaving differently from the wording. Six fixes confirmed, six regression cases added. |
| Regression | The suite ran against this build rather than a previous one, and its failures were triaged as real defects or as test defects. A suite whose failures are habitually ignored is providing reassurance instead of information. | Suite ran on 2.14.0. Four failures: three test defects from a changed selector, one real. |
| Compatibility | Supported browsers at the current version and one behind, mobile web on both platforms, and the extremes of your viewport range. One version behind matters because a meaningful share of users have not updated. | Chrome 141 and 140, Safari 18 and 17, Firefox 143, plus iOS Safari and Android Chrome. |
| Non-functional | Load measured on the slowest device you support, keyboard navigation and focus order on new screens, contrast on new components, and the error, empty and loading states actually reached. Those three states are the ones no one demos. | New invoice screen checked with the network throttled and with the list empty. |
| Data and integrations | Migrations rehearsed against production-shaped data, every outbound integration exercised including its failure path, and scheduled jobs run on the new build. An integration that only ever succeeds in testing has an untested half. | Migration rehearsed on an anonymised copy. Payment webhook tested with a rejected charge, not only an accepted one. |
| Release readiness | No open defect above the agreed blocking severity, known issues written down with an owner, rollback rehearsed with a named decision-maker, and monitoring covering the new surface. This is the group that produces the go or no-go. | No blockers, two majors accepted and recorded with owners, rollback rehearsed on Tuesday. |
| The release decision | Ship, ship with conditions, or do not ship, written down against a build and a name. A checklist that ends in a column of ticks ends in a report, and a report is not what the release is waiting for. The conditional outcome is the one most releases actually reach, so it is a real answer here rather than an informal agreement nobody can produce later. | Ship with conditions: two majors fixed and re-checked by the QA lead on the build that ships. |
A QA exit criterion nobody can meet, and one a release can be held to
Not this
[ ] No known bugs
This instead
[ ] No open defect above major [ ] The three open minors listed with an owner and a target, and accepted by the product owner, by name
Zero defects is not an exit criterion, because no release of any size has met it, so the check is either dispensed with or quietly reinterpreted on the day. A check that gets dispensed with has stopped being a check, and the habit spreads to the ones beside it. Naming the blocking severity gives the release a line it can actually be held to, and naming who accepted the rest is what makes that acceptance mean something a month later.
Check the criteria, not the feature
The difference is not pedantic. Working through a feature means exercising what was built, and what was built is exactly the thing that might not match what was asked for. Working through the acceptance criteria means comparing the build against the agreement, which is the only comparison that can find a gap between them. This is also why the criteria have to be available before testing starts: reconstructing them from the implementation produces a list the implementation passes by definition.
Zero defects is not an exit criterion
Every release ships with known problems, so a checklist that requires none is a checklist that gets waived, and an item that is routinely waived has stopped functioning as a check. Naming the blocking severity instead converts the last conversation from a negotiation into a determination anybody can make. It also moves the pressure of a date away from the people who found the problems and onto the decision to accept them, which is where it belongs.
A fixed defect needs a test, not only a verification
Confirming that a defect is gone proves something about this build and nothing about the next one. The discipline that makes the difference is that every fixed defect gains a test reproducing it, so the regression suite becomes the record of every mistake the team has already made once. Without it the same defect returns two releases later, is reported by a customer, and is triaged by somebody who has no idea it has been fixed before.
Common questions
What goes on a QA checklist before a release?
Entry conditions including a passing smoke test on a recorded build version, functional checks against the acceptance criteria, verification that fixed defects are fixed and pinned by tests, a regression run on this build, compatibility across supported browsers and devices, non-functional checks, data and integration checks, and a release readiness group that names which severities block.
What is the difference between a QA checklist and a test plan?
A test plan is written per release and describes how that release will be tested: scope, approach, environments, risks. A QA checklist is the same list every time and is worked through to decide whether a specific build can ship. One is the plan for a release, the other is a gate.
Who signs off a QA checklist?
Whoever owns the release decision, on evidence from whoever ran the checks. Splitting those two roles matters: the person who tested has the findings, and the person who ships has the view of what else is in flight and what a delay costs. Combining them puts the pressure of the date on the person collecting the evidence.
Can a QA checklist be automated?
Parts of it. The regression run, the compatibility matrix and many functional checks belong in the pipeline, and anything that runs every release and must never be skipped is a candidate. What resists automation is the judgement in the readiness group: whether a known issue is acceptable is a decision, and no suite makes it.
Terms used on this page
More templates
-
Checklist
UAT checklist and sign-off
A copyable UAT checklist and sign-off template: what to confirm before the window opens, how to record each scenario and finding, and what sign-off states.
Checklist
Website redesign checklist
A website redesign checklist for the QA half: the baseline to capture before the old site goes, url and content parity, regression, cutover and rollback.
Or skip the template and capture the fields automatically.
Environment, console and network attach themselves, on the free plan.