User Acceptance Testing (UAT): Checklist and Test Script

User acceptance testing (UAT) is the final check before a release goes live, and it is done by the business: the people who will use the software to do their jobs, working through their real tasks with realistic data. A UAT checklist covers five things. Entry criteria say when UAT can start. A one-page plan names the testers, the scenarios and the dates. Test scripts walk each tester through a real job, step by step. A triage rule sorts what fails into bugs and gaps. Sign-off is a named person from the business saying, in writing, that the software is accepted. The checklist, a plan, a script template with a filled example, and a sign-off record are below.

This page is about the business accepting the software. Writing individual test cases is covered in the test case template, the checks QA runs across a release are in the QA checklist, and the conditions each feature must meet are its acceptance criteria.

What UAT is, and who does it

Microsoft’s implementation guidance describes the types of testing↗ (opens in a new tab) plainly: UAT is the last test before production, it is always manual, it is done by business users in a dedicated test environment, and its purpose is to get sign-off from the business stakeholders that the solution meets their needs. The testers are trained on the new process first, so that confusion about the software is not recorded as a defect.

That is why UAT is not a second round of QA. QA asks whether the software does what the specification says. UAT asks whether the people who have to live with it can run their work on it: the billing clerk closing a month, the dispatcher rebooking a job, the manager approving a refund. A feature can pass every QA check and still fail UAT, because the specification missed how the work is really done.

UAT vs QA vs acceptance criteria

• Acceptance criteria: conditions written for one feature before it is built, such as “a refund above the approval limit needs a manager’s sign-off”. They are what QA and UAT both test against.
• QA: testers check the release against the specification and the criteria, including edge cases, browsers and regressions. The question is “is it built right?”
• UAT: business users run their real work end to end. The question is “is it the right thing, and can we go live on it?” The answer is a sign-off, not a pass rate.

Entry criteria: when UAT can start

• QA is finished and no open bug is marked critical. Business users should not be the first to find that the login page is broken.
• The UAT environment is separate from production, runs the release candidate, and has realistic data. Mask or replace personal data before copying anything from production.
• Test accounts exist for every role in scope, with the same permissions the real users will have.
• The scripts are written and reviewed by someone from the business, and every in-scope requirement is covered by at least one scenario.
• Testers are named, trained on the new process, and have time blocked in their calendars. UAT squeezed around a full workload is UAT that does not happen.
• Everyone knows how to report a failure and who triages it.

Exit criteria: when UAT is done

• Every script has been run and has a result: Pass, Fail or Blocked.
• No open bug is critical or high. Anything lower is either fixed and retested, or listed as a known issue the business accepts.
• Every gap, meaning a need the software was never built to meet, has a decision: fix before launch, schedule for later, or drop.
• The named business owner has signed off, in writing, with the date and the version tested.

The UAT checklist

BEFORE
[ ] QA complete; no open critical bugs
[ ] UAT environment on the release candidate, separate from production
[ ] Realistic data loaded; personal data masked
[ ] Test accounts for every role in scope
[ ] Scripts written, reviewed by the business, mapped to requirements
[ ] Testers named, trained, time blocked
[ ] Reporting route and triage owner agreed

DURING
[ ] Kickoff: scope, dates, how to report, who to ask
[ ] Daily check: scripts run, failures filed, blockers cleared
[ ] Every failure filed the same day, with steps and a screenshot
[ ] Each failure triaged: bug or gap, and its severity
[ ] Fixes redeployed to UAT and the failed scripts rerun

AFTER
[ ] All scripts run; results recorded
[ ] No open critical or high bugs
[ ] Known issues listed and accepted by the business owner
[ ] Gaps decided: now, later or never
[ ] Sign-off recorded: who, date, version tested

A one-page UAT plan

Release:          [name and version]
Business owner:   [the one person who signs off]
UAT lead:         [who runs the schedule and triage]
Dates:            [start] to [end]; sign-off by [date]
Environment:      [URL]; data as of [date]; personal data masked
In scope:         [processes, e.g. "month-end invoicing"]
Out of scope:     [what is not being accepted this round]
Testers:          [name, role, scenarios assigned]
Entry criteria:   [list, or "as the UAT checklist"]
Exit criteria:    [list, or "as the UAT checklist"]
Severity scale:   Critical = cannot go live; High = serious, workaround
                  is painful; Medium = workaround exists; Low = cosmetic
Reporting:        [where failures go, and who triages them daily]

Pick testers who match the people who will use the software, including people who use assistive technology. Section508.gov’s guidance on usability testing with people with disabilities↗ (opens in a new tab) recommends a representative sample of users with a range of disabilities, such as vision, hearing, dexterity or cognitive disabilities, because many rely on screen readers, magnifiers or other assistive technology that a script run with a mouse will never exercise.

A UAT test script template

A UAT script follows a business task from start to finish, in the business’s words. It is looser than a QA test case: it names the goal and the steps a user would take, and it asks the tester whether the result would work for them, not just whether it matches a spec.

Script ID:      UAT-<AREA>-<NN>
Scenario:       <the business task, as the user would describe it>
Requirement:    <requirement or task ref this covers>
Tester / role:  <name>, <role in the business>
Preconditions:  <account and role> · <data that must exist>

Steps:
  1. <what the user does>
  2. <what the user does, with the exact data>
  3. ...

Expected:       <what the user should see and be able to do next>
Actual:         <what happened>
Result:         Pass / Fail / Blocked
Works for my job?  Yes / No: <why not, in the tester's words>
Evidence:       <screenshot or file name>
Failure ref:    <bug or enhancement ref, if filed>
Run on:         <date>, version <build>

Script ID:      UAT-BILL-04
Scenario:       Issue a partial refund to a customer who was
                overcharged, and see it on the month-end report
Requirement:    FET-212 Partial refunds
Tester / role:  Dana Price, billing clerk
Preconditions:  Signed in as a billing clerk. Invoice INV-10432
                exists, paid, $1,240.00

Steps:
  1. Open INV-10432 and choose Refund
  2. Enter $140.00, reason "Overcharged: duplicate line"
  3. Submit, then open Reports > Month-end > Refunds

Expected:       Refund saved as Pending approval (over $100 needs
                a manager). After approval, the report shows
                INV-10432, $140.00, the reason and the approver.
Actual:         Refund saved and approved. The report shows the
                amount but not the reason.
Result:         Fail
Works for my job?  No: auditors ask for the reason on every refund
Failure ref:    BUG-231
Run on:         September 24, 2026, version 3.8.0-rc2

Turning failures into bugs, and gaps into decisions

Not every failure is a bug. Microsoft’s guidance on running tests↗ (opens in a new tab) draws the line: bugs are defects that need to be fixed, while gaps, caused by a missing feature, a changed requirement or a new idea, are enhancements to be discussed and prioritized. Sort every failure into one or the other on the day it is found.

• Bug: the software does not do what was agreed. File it with the script ID, the steps, expected and actual, the evidence and a severity. Fix, redeploy to UAT, rerun the script.
• Gap: the software does what was agreed, but what was agreed does not fit the work. File it as an enhancement and let the business owner decide whether it blocks launch.
• Question: the tester is unsure what should happen. That is a missing requirement; get the answer from the business owner and write it down before anyone codes a fix.

UAT sign-off

Sign-off is a formal acceptance, and it should read like one. In federal contracting, FAR 46.501↗ (opens in a new tab) defines acceptance as acknowledgment that the supplies or services conform with the contract’s quality and quantity requirements, and says it is ordinarily evidenced by executing an acceptance certificate. Your UAT sign-off does not need the legal weight, but it needs the same parts: who accepts, what exactly, and on what terms.

Release accepted:  Billing 3.8.0 (build 3.8.0-rc3)
Accepted by:       Maria Lopez, Finance Operations Manager
Date:              September 29, 2026
Scope tested:      Invoicing, partial refunds, month-end reports
Results:           38 scripts: 36 pass, 2 pass on retest
Known issues accepted for launch:
  - BUG-240 Refund report column widths wrap on small screens (Low)
Gaps deferred:
  - ENH-238 Bulk refunds from a CSV file (after launch)
Conditions:        none

A sign-off with conditions, such as “accepted if BUG-240 is fixed within two weeks of launch”, is fine as long as the condition is written down and tracked. A sign-off given verbally in a hallway is not a sign-off.

Running UAT from a fenbs board

fenbs does not store or run test scripts; keep those in a spreadsheet or your test tool. It holds the work UAT creates. Business testers join the board with a role; Reporter, one of the suggested roles, lets them add tasks and comment while editing only their own. Each failure becomes a task: a bug such as BUG-231 for a defect, an enhancement such as ENH-238 for a gap, with the script ID, steps and evidence in the note and a priority from 1 to 10, 1 the most urgent. After a day of testing, Add many takes a pasted list and files one task per line, with bug: or enhancement: at the start of a line setting its kind. fenbs has no assignee field and no due dates, so put the tester and any fix-by date on the first line of the note.

The feature under test records the result in its Testing section: Tested, Partly tested, Failed, or Needs owner check for what only a person can confirm, with notes saying which scripts were run and what was not. The sign-off itself belongs on the Decisions and rules page as a decision, “Accept Billing 3.8.0 for launch”, with the known issues linked. Request sign-off from the business owner there: each named board member gets an email and answers Approve or Reject, and the decision stays awaiting sign-off until all of them approve. An AI assistant can draft the record and ask for sign-off, but it can never sign.