A user acceptance test case checks a defined user or business outcome against an agreed expectation. Prepare the case in an authorised test environment, using appropriate fictional or otherwise approved data and a clear route for reporting differences.
Passing one case does not approve a release or prove the whole service meets every requirement. The case contributes evidence to the actual review and decision process.
Connect the case to a requirement
Identify the user task and approved acceptance criterion. State what the test is intended to demonstrate, keeping unrelated checks in their appropriate cases or specialist processes.
The GOV.UK Service Manual’s user-story guidance connects outcomes to acceptance criteria. Its pre-production guidance provides context for testing before live use. Follow the actual project’s authorised environment and methods.
Do not test a production system or use real personal information simply because it makes the example easier to arrange.
Use a test-case structure
Record:
- Reference: case identifier and requirement or criterion.
- Preconditions: approved environment, role and starting state.
- Inputs: fictional or permitted data required.
- Actions: clear steps the tester performs.
- Expected result: defined observable outcome.
- Actual result: what occurred, with proportionate evidence.
- Outcome: pass, fail, blocked or another approved status.
- Follow-up: defect reference, owner and retest arrangement.
Keep credentials and sensitive system information out of broadly shared test records. Use the project’s approved restricted locations where needed.
A fictional missing-date case
In this invented room-request prototype, the criterion says a required date must be supplied before submission. The test begins with an authorised test user and an empty practice request.
The tester enters the other permitted fictional details, leaves the required date blank and attempts to submit. The expected result is the defined clear date message, with no request treated as successfully received under that criterion.
The tester records the actual message and resulting state. If a received record is created despite the missing date, they report the difference against the criterion rather than marking a pass because a message also appeared.
No actual service functionality or live test result is claimed by this exercise.
Distinguish a defect from a blocked test
If the environment is unavailable or necessary approved access is missing, record why the case could not run. Do not treat that as evidence that the feature passed or failed its business outcome.
For an observed difference, provide reproducible steps and relevant evidence through the approved defect process. Avoid guessing the technical cause or changing the expected result after seeing the output without a proper requirements decision.
Retest and preserve the result
When an authorised change is ready, repeat the relevant case under the approved plan and check any related cases identified by the responsible team. Record the version and conditions so the evidence remains interpretable.
Submit results to the actual acceptance process, with unresolved cases visible. A useful UAT case makes the need, expectation and observed result traceable, giving decision-makers reliable evidence rather than a general statement that someone tried the system and it looked fine.
For career context, compare the IT roles guide with the actual vacancy to distinguish business acceptance responsibilities from wider technical testing duties.
