UAT stands for user acceptance testing: a check that software supports agreed business needs, carried out by intended users or their representatives. They perform realistic tasks and record what happens.
A booking screen might save an appointment correctly yet leave staff struggling to reschedule it. UAT brings those practical requirements into the acceptance decision, moving beyond a demonstration of individual features.
What UAT adds to technical testing
Functional testing checks specified behaviour; UAT examines whether that behaviour supports the work people need to do. The two overlap, and users can uncover technical defects during acceptance testing.
UAT belongs within the broader quality assurance effort. It complements specialist security, performance and integration testing rather than replacing them. Its particular contribution is operational judgement: can staff complete agreed tasks using the software as delivered?
Acceptance criteria turn that question into observable outcomes. “When staff reschedule an appointment, the customer receives an updated confirmation” gives testers something concrete to assess. “Rescheduling should work well” leaves the outcome open to interpretation.
Who takes part, and when?
Plan UAT as part of IT project management, reserving business users’ time, assigning responsibility for investigating findings and scheduling an acceptance decision before launch.
Choose people who know the relevant work, including different roles where permissions or responsibilities affect the outcome. Technical staff can prepare tests and investigate problems. Name a business owner authorised to accept the result, and distinguish that responsibility from recording test results or approving deployment.
Agree requirements and acceptance criteria early. Testing can run across successive releases, with each round building on earlier findings. Before execution, the relevant functions should be stable enough to test meaningfully, with suitable accounts, sample data and supporting guidance available.
A worked example: rescheduling an appointment
Imagine a new appointment-booking application. The business has agreed that authorised staff must be able to move an appointment to an available slot, release the previous slot and send the customer an updated confirmation.
Use a test account with the appropriate staff permissions and fictional booking details in a suitable test environment. Route messages to a controlled test inbox. The tester opens an existing appointment, selects another available slot and confirms the change.
An illustrative completed test record could read:
Expected outcome: The replacement slot is reserved, the previous slot becomes available and the confirmation shows the revised appointment.
Observed outcome: The replacement slot is reserved and the confirmation is correct, but the previous slot remains unavailable.
Result: Fail against the slot-release criterion.
Link the failed result to a defect record for investigation.
Include an exception test too: attempt to select an unavailable replacement slot. Under this example’s agreed requirements, the application should explain why the change cannot proceed and preserve the original appointment.
What evidence should testers record?
Tie each record to a requirement. Include the tester’s role, execution date, application version, starting conditions, steps, expected outcome, actual outcome and any issue reference.
Screenshots need context: describe the action taken and the criterion being checked. A calendar image becomes useful evidence when another person can tell which appointment changed and what went wrong.
Keep blocked and unexecuted tests separate from passes and failures. If an incorrectly configured test account prevents execution, record the test as blocked and correct the setup before trying again.
After a fix, repeat the failed test and relevant related checks. Retain the original finding alongside the retest result to show whether the issue was resolved.
Turning findings into an acceptance decision
Classify findings before judging their effect on acceptance. A software failure against an agreed criterion is a defect. An additional feature request may be a change request. Difficulty completing a task could reveal a training need, confusing design or a defect; investigate before assigning a category.
An essential business need discovered during testing still deserves assessment, even if the original requirements missed it.
Business impact should drive the decision. Losing appointments carries different consequences from a spelling mistake. The authorised business owner should decide whether to accept, require correction or accept with documented conditions.
For an accepted limitation, record its impact, a viable workaround where appropriate, a responsible owner and a review date. If staff must temporarily release old slots manually, establish who will do it and whether the workload is manageable.
Sign-off should identify the software version, tested scope and outstanding conditions. It records business acceptance within those boundaries; the wider release decision also needs evidence from the other quality and operational checks.