UAT Working Sheet
UAT Working Sheet
The purchasing tool was signed off in a single meeting. Nobody in that meeting had ever raised a purchase order.
Four department heads who approve spending watched a demo, agreed it looked clean, and signed. Within a month the buyers who raise orders all day found they could not copy a previous order, so a routine restock meant retyping forty lines. Nobody who did the work had been asked, so it was never specified.
(Composite example, assembled from patterns common in organisations where UAT is run as a demo for approvers. The figures are illustrative.)
Too much UAT is theatre: a demo, nods and a signature, then the real issues after launch. UAT's job is not to re-find defects internal testing missed; it is to catch a system that faithfully implements the wrong specification. Boehm (1984) framed the difference as two questions: verification asks "Are we building the product right?", and validation asks "Are we building the right product?". This sheet keeps UAT on the second question, starting from the calendar.
Step 1: map the working process
Budget time after testing for fixes. T = the UAT execution day. Offsets are in working days for a small feature; scale them to weeks for a large release.
Phase | When | What has to be true before you leave this phase | Date |
☐ Plan | T-2 | Scenarios, success criteria, participants and schedule defined | ______ |
☐ Prepare | T-1 | Environment stable, scripts checked, participants briefed | ______ |
☐ Execute | T | Participants test, the team observes, issues are captured | ______ |
☐ Triage | T | Every issue sorted (bug or design issue) and prioritised | ______ |
☐ Fix | T+1 | Critical issues addressed | ______ |
☐ Verify | T+1 | Participants re-test the fixes | ______ |
☐ Sign-off | T+2 | Acceptance recorded with the list of accepted known issues | ______ |
Launch | T+2 or T+3 | No exit condition: this is the release | ______ |
If nothing is scheduled between Execute and Launch for Fix and Verify, pressure to sign will turn the session into a ceremony.
Step 2: choose the participants
Pick a small group (our rule of thumb is 5–10 participants). Much more than that and feedback becomes hard to integrate.
Choose people who:
☐ Will use this feature regularly.
☐ Are affected if it is wrong.
☐ Bring different roles or use cases.
☐ Are comfortable giving honest feedback.
Screen out people who:
☐ Sit far from the actual use.
☐ Feel obliged to approve.
☐ Lack the context to judge it.
The wrong participants say "it's fine", and the real users find the problems after launch.
# | Name and role | Regular user? | Honest feedback? | Confirmed |
1 | ______ | ☐ | ☐ | ☐ |
2 | ______ | ☐ | ☐ | ☐ |
3 | ______ | ☐ | ☐ | ☐ |
4 | ______ | ☐ | ☐ | ☐ |
5 | ______ | ☐ | ☐ | ☐ |
Step 3: prepare before anyone touches the system
☐ Environment ready: stable, realistic data, accessible.
☐ Scenarios documented: clear scripts for the scripted part.
☐ Success criteria defined: what "passes UAT" means, specifically.
☐ Issue reporting clear: participants know where to record what they find.
☐ Time committed: blocked in calendars, not "fit it in when you can".
Build both approaches into the session:
☐ Scripted: specific scenarios on the critical paths, easier to interpret.
☐ Exploratory: users work as they would on a normal day, which surfaces real-world problems.
Step 4: observe during the session
What participants do matters as much as what they say. Someone may call a screen fine while struggling with it; the struggle is the finding. Note where each participant:
☐ Hesitate.
☐ Leave the expected path.
☐ Rename something, calling it by a different word from yours.
☐ Look confused.
☐ Look frustrated.
Remote sessions: share screens, and record with permission.
Step 5: capture every finding
"It's confusing" is not actionable. Record all five fields, then tag it. A bug: the system isn't doing what was specified, so fix it before launch. A design issue: the system does what was specified but the specification was wrong, so triage it (fix, defer or accept).
Scenario | Expected | Actual | Severity (blocking, annoying or cosmetic) | Workaround? | Bug or design? |
______ | ______ | ______ | ______ | ______ | ☐ Bug ☐ Design |
______ | ______ | ______ | ______ | ______ | ☐ Bug ☐ Design |
______ | ______ | ______ | ______ | ______ | ☐ Bug ☐ Design |
______ | ______ | ______ | ______ | ______ | ☐ Bug ☐ Design |
UAT-discovered design issues are often the most valuable findings you'll get, because they are caught before customers meet them. Don't dismiss one because "the spec said so".
Step 6: hold the sign-off gate
Don't sign until every box below is true. A meaningful sign-off records acceptance with the known issues being accepted; without that list it is only a signature.
A sign-off should mean:
☐ Participants actually used the system, rather than watching a demo.
☐ Every issue found has been addressed or explicitly accepted as out of scope.
☐ Participants believe the system serves the use case.
☐ The list of accepted known issues is attached.
☐ A named business owner signs, not just the participants.
It should not mean:
☐ Participants signed without really using the system.
☐ Every issue was dismissed.
☐ The team is locked into a final version with no room to fix anything.
Accepted known issues (attach to sign-off): ______
Step 7: check the five ways UAT goes wrong
☐ Disengaged participants: they click a few things and approve. Give them scenarios and watch.
☐ Sign-off pressure: the project is too far along to change anything. Schedule fix time after UAT.
☐ Wrong participants: people far from the work say it's fine. Choose people closer to the actual use.
☐ Skipped internal testing: UAT burns its time re-finding basic defects. Finish internal testing first.
☐ No follow-up: findings are logged and forgotten. Assign each one and track it to closure.
UAT is not beta: UAT is specific users, scenarios and a formal sign-off before launch; beta is wider, ongoing feedback. Sequence: internal testing → UAT → beta → controlled rollout → general availability.
How to use it
Who: the release-readiness owner (a QA lead, product owner or engineering manager) with the business owner who will sign. Fill in Steps 1 and 2 when the date is set, the rest during and after the session.
Output: a dated phase plan, a screened participant list, a tagged findings sheet and a sign-off with known issues attached.
Done when: each finding is fixed, deferred or accepted by a named person, participants have re-tested the fixes, and the sign-off names who accepts the known issues.
Where this changes
A small internal tool can fold Steps 1 to 3 into one planning conversation, provided the testers are the people who will use it. Regulated, contractual or large releases need more: acceptance criteria agreed in advance, traceable evidence per scenario, and sign-off by an accountable owner named in the contract or governance process.
The reasoning is in User Acceptance Testing (UAT): How to Run It Well. For which contract UAT checks, read Definition of Done vs Acceptance Criteria, and to write criteria that can be tested at all, Acceptance Criteria: Given/When/Then Done Right.
Final takeaway
A UAT signature is only worth what the session behind it tested. Put real users in the room, watch what they do as well as what they say, and sign only when each finding carries a decision and a name.
Sources
Barry W. Boehm, "Verifying and Validating Software Requirements and Design Specifications", IEEE Software 1(1):75–88, 1984 (the verification and validation questions).
Jakob Nielsen, "Why You Only Need to Test with 5 Users", Nielsen Norman Group, 18 March 2000. Context for small, iterative test groups; it concerns usability testing, not a UAT standard. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
