Flawsnap
Free trial

User acceptance testing (UAT) checklist

A checklist for each stage of UAT, from preparing the environment to getting a clear sign-off.

A UAT checklist covers four stages. Before testing, agree scope, testers, test scenarios, a stable environment and exit criteria. During testing, run scenarios as real users would and log every issue with steps and evidence. Then triage issues by severity, retest fixes, and get written sign-off once the agreed exit criteria are met.

What UAT is, and what it is not

User acceptance testing is the last check before release, done by the people the software is for: the client, the business owner or a group of real users. They are not hunting for every edge case. They are confirming that the software does the job it was built to do, in the way they actually work.

UAT assumes the build has already passed functional QA. If testers keep finding crashes and broken pages, the build was not ready, and UAT turns into unpaid QA.

Stage 1: before testing starts

  • [ ] Scope written down: which features and journeys are in this round, and which are not.
  • [ ] Testers named, with a lead who can make decisions and sign off.
  • [ ] Test scenarios written as real tasks ("Book a table for four next Friday"), not as UI instructions.
  • [ ] Test environment stable, on a fixed build, with realistic data. No deploys during sessions without warning.
  • [ ] Test accounts created for each role, with credentials shared privately.
  • [ ] Devices and browsers to cover agreed, based on what real users use.
  • [ ] One place to report issues, and every tester knows how to use it.
  • [ ] Severity levels defined so everyone means the same thing by "critical".
  • [ ] Exit criteria agreed in advance (see stage 4).
  • [ ] Dates for the test window, the fix window and the retest window.

Stage 2: during each test session

  • [ ] Start from the scenario, not from the menu. Work as you would on a normal day.
  • [ ] Mark each scenario pass, fail or blocked, with the date and the tester's name.
  • [ ] Report every issue the moment you find it, while the screen still shows it.
  • [ ] One issue per report, with steps, expected and actual results, and a screenshot.
  • [ ] Note the device, browser and account you used.
  • [ ] Flag anything that works but feels wrong: confusing labels, extra steps, missing information.
  • [ ] Do not fix data or settings by hand to get past a problem; report it instead.

Reporting from inside the page saves the most time here. With a feedback widget on the staging site, testers circle the problem and the page, browser and console come with it. See UAT with Flawsnap.

A test scenario format that works

UAT scenario record
Scenario ID:   UAT-07
Scenario:      A returning customer reorders a previous purchase
Role/account:  customer-returning@test
Starting point: Signed in, on the account page
Steps:         Open Orders, choose the last order, click "Reorder", pay
Acceptance:    Same items in the basket, saved address prefilled,
               confirmation email received
Result:        Pass / Fail / Blocked
Issues raised: (report links)
Tester, date:

Stage 3: triage and retest

  • [ ] Review new issues daily with the product owner and a developer.
  • [ ] Classify each one: defect, change request, or not a bug (explained to the tester).
  • [ ] Assign a severity and an owner. Change requests go to a separate list, not this release.
  • [ ] Merge duplicates and tell the reporters which issue survived.
  • [ ] Fix, deploy to the UAT environment, and tell testers what changed.
  • [ ] The original reporter retests and closes the issue, or reopens it with a note.
  • [ ] Rerun any scenario that touched the fixed area, not just the single step.

Stage 4: exit criteria and sign-off

Agree these before testing begins, so sign-off is a check rather than a negotiation:

  • [ ] Every in-scope scenario has been run at least once.
  • [ ] No open critical or high-severity defects.
  • [ ] Remaining medium and low issues are listed, accepted and scheduled.
  • [ ] Change requests are recorded for a later release.
  • [ ] The sign-off lead confirms in writing, naming the build that was accepted.

Pitfalls that derail UAT

  • Feedback in five channels. Email, chat, calls and spreadsheets mean issues get lost. Pick one place.
  • Testing a moving target. Unannounced deploys make results meaningless.
  • Vague issues. "The form is weird" cannot be fixed. Ask for steps and a screenshot every time.
  • Scope creep. New ideas are welcome, but logged as change requests, not blockers.
  • No retest. A fix nobody verified is not a fix.

Questions

Who should do user acceptance testing?
The people who will use or own the software: the client, business stakeholders, or a small group of real users. Developers and QA should support them, but should not be the ones accepting the work.
How long should UAT take?
It depends on scope. Plan a test window, a fix window and a retest window rather than one block, and agree the dates before starting. Short rounds focused on a few journeys are easier to finish than one long round covering everything.
What is the difference between QA and UAT?
QA checks that the software works as specified and finds defects. UAT checks that it meets the users' real needs and is acceptable for release. QA usually happens first and is done by testers; UAT is done by users or the client.
Can UAT be done on the live site?
It is safer on a staging copy with test accounts and realistic data, so testers can place orders or change settings without affecting real customers. Some teams do a short final check on production after release.

Try it on your own site

7-day free trial, then $9 a month for Starter or $19 for Pro, per organization, with unlimited team members.

Start free trial Try the live demo

Related

Updated