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 UAT checklist, and the sign-off it produces
A UAT checklist covers the session rather than the plan. It confirms the build, environment, data and access before anybody starts, records a result against every scenario including the ones nobody ran, holds each finding to what somebody else can act on, and ends in a sign-off naming the build accepted, the known issues accepted with it, and the person accepting on behalf of the business.
- Checklist
- 5 groups
- 24 checks
- Updated
A UAT plan is agreed before the window opens and settles what will be accepted and by whom. This is the other half: the list somebody works through while the window is open, and the record it leaves behind at the end. Keeping the two apart is what stops the plan being reopened every morning, and it is what keeps the sign-off short enough that the person signing reads all of it.
In the checklist
- Before the window opens 8
- Scenarios run (the script)
- Every finding, before it leaves the session 7
- Before the window is closed 6
- Sign-off 3
UAT checklist and sign-off, ready to copy
Copy it as it is. There is no email step, and nothing on this page is behind one.
Before the window opens
Scenarios run (the script)
Each row is an outcome to reach, not a sequence of clicks.
| # | Business outcome to reach | Owner | Role | Build | Result | Findings |
|---|---|---|---|---|---|---|
| 1 | Pass / Fail / Blocked / Not run | |||||
| 2 |
Every finding, before it leaves the session
Before the window is closed
Sign-off
Release or feature:
Build or version accepted:
Environment:
UAT window, from and to:
Participants, by name and role:
Scenarios: [total] run, [n] passed, [n] failed, [n] blocked, [n] not run
Known issues accepted with this sign-off:
| Ref | Summary | Severity | Owner | Target release |
|---|---|---|---|---|
Decision, one of:
above, carrying the known issues listed.
that ships, by the person named, before release. Nothing else reopens.
Items, owner, and who re-checks:
Accepted on behalf of the business by:
Name:
Role:
Date:
Countersigned by the delivery lead:
Name:
Date:
The list below is written for a session run by people who do not test software for a living. Each group answers one question. Is this build worth their day. Did every scenario get a result. Does each finding carry enough for an engineer to act on it. And what exactly is being accepted, on which build, with which known issues attached.
What each group is for
Scroll the table sideways for the examples.
| Group | Why it earns its place | Example |
|---|---|---|
| Before the window opens | The build, the environment and the data set written down; every participant able to sign in as the role they will test as; the acceptance criteria to hand in the wording agreed before the work started; scenarios assigned with one owner each; and the reporting route tried once on a throwaway report. A sign-off naming a week rather than a build accepts whatever happened to be deployed during it, and a booked session spent on logins is a session lost. | Build 3.2.0 on the UAT environment, seeded with the anonymised July returns data. Three clerks and a supervisor signed in the afternoon before. |
| Scenarios run (the script) | One row per business outcome to reach, with an owner, the build it ran on, a result and any findings. The row is the script: an outcome rather than a click sequence, so participants take the route they would take at work and reveal the screen nobody designed for. Pass, Fail, Blocked and Not run are all real values, because without the last two a scenario nobody opened is indistinguishable from one that passed. | Refund a return that arrived damaged and was paid partly on a gift card. Owner: returns clerk. Result: Not run, the supplier sandbox was down on both days. |
| Every finding, before it leaves the session | The expected business outcome, what happened instead, the scenario and account it came from, the technical conditions around it, and any value that was typed, since a recording may mask it. The technical half is collected by the page rather than asked for, because a returns clerk has no reason to know that a request failed. | Expected the refund to include return postage; it excluded it. Scenario 4, clerk account, one failed request logged. |
| Before the window is closed | The reconciliation: every scenario carrying a result including Not run with its reason, every Fail linked to a finding and every finding back to a scenario, duplicates merged so the counts mean something, and anything demonstrated out loud written down by somebody. This is the group that decides whether the numbers in the sign-off describe the window or flatter it. | Two scenarios re-run after a mid-window redeploy, four findings merged into two, one verbal complaint written up as UAT-14. |
| Sign-off | The known issues the business is knowingly signing over, each with a severity, an owner and a target release, then one decision of three, then who accepted, in which role, on which date and against which build. The conditional outcome is the one most windows actually reach, so it is a real answer here with its items, its owner and whoever re-checks them. A year later this block is the only record of what was agreed. | Accepted on condition: UAT-11 and UAT-14 fixed and re-checked by the returns supervisor on the build that ships, countersigned by the delivery lead. |
A UAT finding that cannot be triaged, and the same one that can
Not this
The refund amount is wrong.
This instead
Expected the refund to include the return postage of 3.99. It excluded it, so the customer received 41.00 instead of 44.99. Scenario 4, run from the clerk account, on build 3.2.0. Evidence attached. One failed request logged at the moment of submission.
A business user reporting a business outcome is doing their job, and wrong is honestly what they saw. What is missing is anything anybody can act on: wrong by how much, on which order, in which direction. Half of the second version is the participant answering in business terms, and the other half, the build and the failed request, is collected by the page rather than asked for, because a returns clerk has no reason to know that a request failed.
Sign-off names a build, not a week
A signature against a date accepts whatever was deployed during it. Naming the build is what makes the record checkable later, when somebody asks whether the behaviour now in production is the behaviour that was accepted. It also forces a decision teams otherwise make silently. If a fix is deployed in the middle of the window, every scenario run before it was run against different software, and each of those rows either gets re-run or gets annotated with the build it ran on. Redeploying mid-window is normal. Leaving the record vague about it is what turns a sign-off into folklore.
A scenario with no result is not a pass
A scenario list carrying results only on the rows that failed reads as though everything else worked. Usually several of those rows were never opened, because a participant ran out of time or was blocked by an account that did not work. Blocked and Not run therefore have to be values a row can hold, and the reconciliation at the end of the window exists to force one value onto every row. The reason matters as much as the value: a scenario skipped because a supplier sandbox was down is a gap in coverage the acceptance decision has to weigh, not a detail that quietly disappears between two spreadsheets.
The technical half of a finding cannot come from the participant
Business participants describe the outcome they expected and the one they got, which is the half only they can supply. The rest, meaning the browser and version, the viewport, the account, the console errors and the failed requests, has to be collected by the page while they work. That makes capture a setup item rather than a session one, which is why the checklist asks for it to be proved on a throwaway report before the window opens rather than assumed. Two limits are worth planning around. A recording that masks typed characters cannot show which value broke a form, so that value gets written into the finding by hand. And captured evidence expires: log streams around a session are kept for 30 days and idle sessions for 90, so a finding parked until the next release is triaged with less than the session produced.
Accepted on condition needs a closing step
Most sign-off forms offer two outcomes, and most real windows end between them: the business will accept the release provided a short list is fixed first. Recorded as an acceptance, it ships with the list unaddressed. Recorded as a rejection, it stalls a release everybody agrees is close. The conditional outcome needs the same structure as the other two, meaning the exact items, an owner for each, and a named person who re-checks them on the build that ships rather than on the one that was tested. Without that last step the condition is a sentence in a document, and the release goes out having satisfied nobody's definition of accepted.
Common questions
What is a UAT checklist?
The list worked through while user acceptance testing is running, as opposed to the plan agreed before it. It covers the entry conditions, the scenarios and their results, what each finding has to carry, the reconciliation at the end of the window, and the sign-off record. The same list serves every release, which is what keeps it short enough to complete.
What is the difference between a UAT checklist and a UAT test plan?
The plan is written once per release and settles scope, participants, acceptance criteria and which severities block. The checklist is the same every time and is worked through during execution to produce a decision on a specific build. A plan argues what acceptance means; a checklist records whether it happened.
What should a UAT sign-off document include?
The release accepted, the build version and environment it was tested on, the window dates, the participants by name and role, the scenario counts including blocked and not run, the known issues accepted with their owners and target releases, the decision itself, and the signature of whoever accepts on behalf of the business.
What is a UAT script?
A row describing a business outcome to reach, with an owner and a result, rather than a sequence of clicks to perform. Scripting the clicks verifies the route the team already designed and tested. Handing a participant an outcome and letting them find their own way there is what surfaces the screen nobody can locate and the label that means something else in their department.
Can UAT be signed off with defects still open?
Yes, and almost every release is. What makes it defensible is that the open defects are listed on the sign-off with a severity, an owner and a target release, and that none of them sits above the blocking severity the plan named. A sign-off requiring zero open defects is one that gets waived, and a check that is routinely waived has stopped being a check.
Terms used on this page
Why the work behind it is hard
More templates
-
Checklist
QA checklist
A QA checklist for a release: what to verify before a build leaves the pipeline, who signs each item, and which failures block the release outright.
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.