Use this user acceptance testing checklist to prepare, run and close a UAT round. It has 61 tickable items across three phases, and each one has an owner so nothing falls between the agency and the client.

Copy the tables into a spreadsheet or shared document, or print the page and tick as you go. If you are new to UAT, start with our guide to user acceptance testing, then come back here.

The owners used below are the UAT lead (who runs the round), the approver (who makes the final decision), the developer, QA and the testers.

Before UAT

Do not invite testers until this phase is complete. A gap here turns into wasted tester time later.

Scope and plan

Done	Check	Owner
☐	Acceptance criteria written as things a person can check	UAT lead
☐	Test plan approved, covering scope, roles and schedule	Approver
☐	Out-of-scope list written and shared with testers	UAT lead
☐	Every must-have requirement has at least one scenario	UAT lead
☐	Every scenario has an expected result and a named tester	UAT lead
☐	Awkward paths included: declined card, expired code, empty form, password reset	QA
☐	Severity definitions and fix targets agreed	UAT lead
☐	Entry and exit criteria written into the plan	UAT lead
☐	Schedule leaves time to fix and retest before go-live	UAT lead

A blank plan to start from is in our UAT test plan template.

Build and environment

Done	Check	Owner
☐	Internal QA finished with no open critical or high issues	QA
☐	Release deployed to UAT and version recorded	Developer
☐	Environment matches production: versions, caching, plugins	Developer
☐	Payments in test mode and test details ready to share	Developer
☐	Outgoing email diverted to a shared inbox	Developer
☐	Site behind a password and hidden from search engines	Developer
☐	Integrations pointing at sandboxes, not live systems	Developer
☐	Deployment window agreed, with no unscheduled deployments	Developer

Our article on what a UAT environment needs explains each of these in more detail.

Data and accounts

Done	Check	Owner
☐	A test account exists for every user role	Developer
☐	Realistic sample data loaded, with no real customer data	Developer
☐	Discount codes, stock levels and other test scenarios set up	Developer
☐	Method agreed for resetting data between rounds	Developer

People

Done	Check	Owner
☐	Approver named and available in the sign-off week	UAT lead
☐	Testers named, with time blocked in their calendars	UAT lead
☐	Backup named for every key tester	UAT lead
☐	Invitation sent at least a week ahead	UAT lead
☐	Reporting route set up and tried by one tester	UAT lead

During UAT

Keep the round moving and keep decisions visible.

Day one

Done	Check	Owner
☐	Smoke test run on the UAT site before testers arrive	Developer
☐	Kick-off held: scope, deadlines, how to report	UAT lead
☐	Every tester has logged in successfully	UAT lead
☐	One test issue logged to prove the reporting route works	Tester

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Testing

Done	Check	Owner
☐	Scenarios marked passed, failed or blocked as they are run	Tester
☐	Every failed scenario has a linked issue	Tester
☐	Issues give page, steps, expected result, actual result and device	Tester
☐	Tested on the agreed devices, not only the tester's laptop	Tester
☐	Forms submitted and the resulting emails read in full	Tester
☐	Payment taken through to confirmation page and email	Tester
☐	CMS tasks tried by the person who will do them after launch	Tester

If testers report through QualityHive, which is our product, send them the guest link with the kick-off and have one of them log a test issue on day one. Guest feedback needs the Lite plan or above. Our website UAT software page shows how it fits.

Triage

Done	Check	Owner
☐	Triage held at the agreed time every day	UAT lead
☐	Each issue classed as defect, change request or question	UAT lead
☐	Each defect has a severity, an owner and a target date	UAT lead
☐	Change requests moved to a separate log	UAT lead
☐	Fixes deployed only in the agreed window	Developer
☐	Smoke test repeated after every deployment	Developer
☐	Daily progress note sent: passed, failed and blocked counts	UAT lead
☐	Stop rule checked: pause if a core journey is unavailable	UAT lead

After UAT

Testing being over does not mean UAT is over. These items protect the launch.

Closing the round

Done	Check	Owner
☐	Every must-have scenario has been run	UAT lead
☐	Fixed issues retested by the person who raised them	Tester
☐	Regression check on areas touched by fixes	QA
☐	No critical or high issues open	UAT lead
☐	Outstanding issues listed with owner and date	UAT lead

Sign-off

Done	Check	Owner
☐	Results summary sent to the approver	UAT lead
☐	Decision recorded: accepted, conditional or not accepted	Approver
☐	Any conditions have a named owner, date and retest	UAT lead
☐	Signed copy filed with the project records	UAT lead

Use the UAT sign-off template to record the decision.

Go-live handover

Done	Check	Owner
☐	Go-live slot and rollback plan confirmed	Developer
☐	Live payment keys and real email sending switched on	Developer
☐	UAT data and test orders not carried into production	Developer
☐	Smoke test on production, including one real transaction	Developer
☐	Test accounts removed and UAT access closed	Developer
☐	Change requests moved into the next phase	UAT lead
☐	Lessons recorded for the next project	UAT lead

Treat each phase as a gate

The phases only protect you if you stop at the end of each one:

Gate	Decided by	If you cannot pass it
Start testing	UAT lead	Move the start date. Do not invite testers to a site that is not ready.
End testing	UAT lead	Extend the round, or agree in writing to reduce the scope.
Go live	Approver	Sign off with conditions, or move the launch.

An unticked box is fine if there is a written reason next to it. An unticked box nobody noticed is the one that causes the problem.

The ticks people get wrong

Some items get ticked from memory. For these, ask for evidence before you accept the tick:

Item	Evidence to ask for
Environment matches production	Side-by-side list of runtime, plugin and module versions
Email diverted	A test order, with the email landing in the shared inbox
Payments in test mode	A completed test payment showing in the gateway's test dashboard
Every tester has logged in	Their names against a successful login, not a yes in a meeting
Issue retested	The tester's own confirmation on the issue
Approver available	A calendar slot in the sign-off week

Short on time?

For a small site, do not skip these eight:

Internal QA finished before anyone else sees the site
Scenarios written with expected results
Email diverted and payments in test mode
Testers and approver named, with time booked
One route for reporting issues
Daily triage
Fixes retested by the person who raised them
A recorded decision from the approver

For the technical side of launch, run our website QA checklist separately. It covers what the build team checks before UAT begins.

Revolutionise your QA processes

Frequently asked questions

What should a UAT checklist include?

Preparation of scope, environment, data and people, then the day-to-day running of testing and triage, then retests, sign-off and go-live handover. Each item should be specific enough to tick and should have an owner.

Who should complete the UAT checklist?

The UAT lead keeps the master copy and chases each item. The named owner ticks it. The approver reviews the final section before making a decision.

Is a UAT checklist the same as a test plan?

No. The test plan describes how the round will run. The checklist makes sure the plan was followed and that no step was skipped.

When should the UAT checklist start?

As soon as the UAT date is set, ideally two weeks or more before testing opens. Booking testers and setting up the environment take longer than most teams expect.

User Acceptance Testing Checklist: Before, During and After