UAT checklist before every release

In short: user acceptance testing (UAT) is the check that a release does what the business asked, run by the business side against criteria written before the sprint. It fails when it is a demo the vendor chose. Use the checklist below as a gate: no release goes live until every line is answered, and a "no" is recorded, not negotiated away.

What UAT is, and what it is not

Developers test that the code works as they understood it. UAT tests that it does what you needed. Those can differ, and the difference is what surfaces at acceptance if nobody checks earlier. UAT is not a demonstration, not a developer clicking through screens they built, and not a formality after the invoice is agreed.

The release checklist

Before testing starts

• The acceptance criteria for this sprint exist in writing and were agreed before the sprint began.
• A test environment exists that mirrors production data structure, with realistic (not toy) data.
• The release notes list what changed, in plain language.
• A named person on the business side owns the sign-off and has set aside the time. Half a day per release is usually enough.

During testing

• Each acceptance criterion is run and marked pass or fail with evidence (screenshot or note).
• The unhappy paths are tested: wrong inputs, missing permissions, failed payment, lost connection.
• Each role is tested, including what it should not be able to do.
• Previously accepted features still work (a short regression pass on the critical flows).
• Data is checked: imports, exports, totals and records match expectations.
• Forms, emails and notifications are checked in the languages you operate in.
• The main flows work on the devices and browsers your users actually have.

Before go-live

• Every failed criterion is either fixed and retested, or consciously deferred in writing with an owner and a date.
• A rollback plan exists and someone has confirmed how long it takes.
• A backup was taken before the release.
• Production credentials, monitoring and an on-call contact for the first 24 hours are confirmed.
• The sign-off is recorded: who, when, which version.

The rules that make the gate real

1. Criteria come first. Written afterwards, they describe whatever was built.
2. The business side tests, not the vendor. When developers test their own work they test what they anticipated.
3. No partial credit. Delivered, partially delivered or not delivered. Partial counts as not done until the remaining part has a date.
4. Evidence beats opinion. A grade with no evidence is an opinion.

What it catches

On a $90,000 build, every status report was green for six sprints. Graded against written criteria, three of the six were partially delivered: the vendor had demoed the happy path and deferred error handling, permissions and data migration to a phase that did not exist in the contract. Caught at sprint six it was renegotiated at no cost; at final acceptance it would have been a change request in the high five figures. A UAT gate run every sprint would have shown it in the first.

If you cannot run it yourself

Two options: ask a colleague who knows the business to own the gate with this checklist, or have an independent reviewer run it. Build Oversight runs the UAT gate on the criteria written before each sprint and returns a go or no-go in writing. To write the criteria first, see acceptance criteria examples, and for spotting trouble early, the five warning signs a project is about to slip.