This user acceptance testing template connects a representative user's task with the downstream result the business needs. Put the agreed outcome, actual observation, and acceptance gap in the same record. The worked example is an original fictional test packet for a room-booking change.
Write the outcome before the steps
The fictional change is build RB-2, tested in an isolated environment with fixture meeting M17. The representative tester's role is office coordinator.
The agreed outcome, A1, is:
The coordinator can change an existing booking, the reception roster shows the new room and time, and the old slot is released.
This outcome crosses the editing form and the reception workflow. “Save button works” would leave the roster and old-slot consequence out of the acceptance record.
The Victorian Government's product-testing guidance connects user acceptance criteria with repeatable scenarios, representative users, evidence, and a summary recommendation. The room-booking packet here applies those general principles through an original example.
Prepare the scenario so someone can repeat it
| Field | Worked U1 preparation |
|---|---|
| User role | Office coordinator. |
| Build and environment | RB-2 in isolated test. |
| Starting fixture | M17 at Room Pine, 09:00. |
| User task | Change M17 to Room Cedar, 10:00. |
| Expected outcome | Form and reception roster show the new room/time; the old slot is released. |
| Evidence to retain | Actual form result, roster result, old-slot check, build, fixture, and test reference. |
Check that the fixture and expected result match the agreed requirement before the session. A representative user should be able to understand the work they are attempting, while the record makes the consequences clear to the reviewer.
Record the mismatch without collapsing the outcome
Choose U1: change booking in the example. Its hypothetical result is:
| Check | Supplied U1 observation |
|---|---|
| Form confirmation | Room Cedar, 10:00. |
| Reception roster | Still Room Pine, 09:00. |
| Old-slot release | No observation supplied. |
The roster mismatch leaves A1 unmet. The absent old-slot observation is another gap to check; it should not inherit a pass from the form confirmation.
Write the impact in the language of the work: reception would still consult the earlier room and time in this supplied test result. Keep that impact beside the mismatch so the decision owner can judge its significance.
The browser page presents the hypothetical evidence. It does not connect to a booking system or run an acceptance test.
Keep an unattempted scenario separate from a failure
Select U2: cancellation. This scenario has not been attempted, so its observed fields remain blank and its state is Not run.
U1 has evidence of an unmet outcome. U2 has no execution evidence. Combining both as “failed” would lose the difference between a defect to investigate and work still to perform.
For a later retest, add the build, fixture, observed results, and retest reference separately. Retain the original U1 mismatch so someone reviewing the packet can follow what changed.
Give the decision owner a useful summary
A review summary should identify which outcomes were examined, who represented the user role, the build/environment, the observed gaps, their business impact, and work still outstanding.
For this packet, the next recommendation is to investigate the roster mismatch, complete the old-slot check, and attempt cancellation before making a complete acceptance recommendation. The actual decision-owner disposition remains a separate field.
The blank UAT record includes outcome, prerequisites, journey, expected downstream result, observation, evidence, gap, impact, retest, and decision-owner response. Build review copy assembles those supplied fields; it does not sign off the change.
Make a packet for your own user workflow
Create one complete, self-contained HTML user acceptance testing packet.
Agreed business/user outcome and reference: [PASTE]
Representative user role: [FILL IN]
Build, environment, fixture, and prerequisites: [PASTE]
Repeatable user scenarios and expected downstream consequences: [PASTE]
Actual observations and evidence references: [PASTE OR LEAVE BLANK]
Acceptance gaps, business impact, and retest references: [PASTE]
Recommendation and actual decision-owner disposition: [PASTE OR LEAVE BLANK]
Keep the agreed outcome, scenario, expected results, observed results,
and gaps together. Include every supplied downstream consequence.
Do not treat one feature confirmation as a complete business outcome.
Keep Not run distinct from a tested failure or an inconclusive result.
Label hypothetical evidence fictional. Show original and retest records
separately. Do not invent execution, a passed check, or acceptance signoff.
Keep the team's recommendation separate from the decision owner's action.
Provide scenario selection, evidence comparison, and a blank UAT record.
Identify missing outcome, build, or evidence information before assembling
the review. Preserve temporary notes across scenarios, mark old output
stale after edits, and ask before resetting. No real booking connection,
test execution, release controls, or claimed saved acceptance records.
Use text of at least 16px, labeled keyboard-accessible controls, and
a layout readable at 360px without horizontal scrolling. Put CSS and
JavaScript inline with no external dependencies. Return complete HTML.
Make the retest expectation precise
Before the next attempt, ask the coordinator and reception representative to read A1 together. They should agree on what must appear in the roster and how the old-slot release will be checked.
In an HTML packet in NOS, you can revise the expected-outcome wording directly while reviewing the mismatch. Replace “booking updated” with the form, roster, and slot-release consequences. The next tester then has a concrete outcome to examine, and the decision owner can see which evidence is still missing.