Plan user acceptance testing and write UAT scripts that business users can run.
Why it matters
A system can pass every technical test and still fail on its first morning, because it does not fit how people actually work. User acceptance testing (UAT) is where the business confirms that the system meets its needs, using realistic scenarios, before it goes live. The analyst usually plans UAT, writes or reviews the scripts and runs the triage meetings, because the analyst knows the requirements best.
Where UAT sits
Unit tests developers test small pieces of code
Integration tests interfaces between systems work (APIs, files)
System tests the whole system against the specification (QA team)
UAT business users confirm it supports their work
UAT is not a hunt for every bug; earlier test levels do that. It answers one question: can we run the business on this? It needs a stable test environment, realistic (but anonymised) data, and real users from each affected group.
The UAT plan
A short plan covers:
- Scope: which processes and requirements are tested, and which are out of scope.
- Entry criteria: what must be true before UAT starts (for example: system test passed, no open critical defects, test data loaded, users trained).
- Testers and schedule: named people from each group (store staff, customer service, marketing, finance) with time released from their normal work.
- Defect process: how to log a defect, severity levels, and who decides what is fixed before go-live.
- Exit criteria: what "accepted" means (for example: all critical scenarios passed, no open severity 1 or 2 defects, workarounds agreed for the rest) and who signs.
Writing UAT scripts
Each script tests one business scenario, traced back to a requirement or user story, in steps a non-technical user can follow:
ID: UAT-LOY-03
Requirement: US-12 "As a store associate I can look up a customer's points at checkout"
Preconditions: Test customer Ana Rivera (HO-1001) exists with 1,250 points.
Tester is logged into the POS test till as a store associate.
Step Action Expected result
1 Scan a test item and choose Find customer Search box appears
2 Search by phone number 555-0101 Ana Rivera is shown as the only match
3 Select Ana Rivera Points balance shows 1,250
4 Complete the sale of 49.99 with card Receipt shows points earned: 49
5 Look up Ana Rivera again Balance shows 1,299
Actual result / Pass or Fail / Defect ID / Tester / Date
Good scripts have specific data ("1,250 points", not "some points"), one clear expected result per step, and cover more than the happy path. For each important requirement add negative and edge cases: a customer with no loyalty account, a refund that must remove points, the API being unavailable (the sale must still complete), a name with an apostrophe or accent.
Acceptance criteria written as Given/When/Then in the Business & Systems Analysis course convert almost directly into UAT scripts; that is one reason to write them well.
Running UAT
- Start with a short kick-off: how to use the scripts, how to log defects.
- Hold a daily triage meeting to review new defects, agree severity and assign them.
- Track progress visibly: scripts passed, failed, blocked; defects open by severity.
- Re-test fixes with the original script, and run a small regression set to check nothing else broke.
- End with formal sign-off by the business owner against the exit criteria.
Common mistakes
- Using IT staff as UAT testers; they test what was built, not how the work is done.
- Vague expected results ("works correctly").
- Production customer data in a test environment without anonymisation.
- Starting UAT on an unstable build, so testers lose confidence.
- No exit criteria, so UAT ends when the calendar says so.
Quick recap
- UAT confirms the business can operate on the system; it comes after system testing.
- Plan scope, entry and exit criteria, testers, schedule and the defect process.
- Scripts trace to requirements, use specific data and expected results, and include negative cases.
Try it
In the Do tab you write a UAT plan outline and three scripts.