User acceptance testing checks whether the intended users can complete their work against agreed criteria. It supports a release decision with observable evidence. A successful developer demonstration is useful, but business users also need to try the workflows themselves.
For a customer portal, operational tool or field application, prepare acceptance testing during scoping. Our custom software development guide explains how this validation fits into delivery.
What acceptance testing covers
The technical team tests code behaviour, interfaces and defined controls. User acceptance testing adds an operational question: can an authorised person complete their task with the information and exceptions their role encounters?
It does not replace security testing, load testing, backup recovery tests or an accessibility assessment. Those activities require their own methods and owners. The release decision should bring their findings together when they are part of the agreed scope.
A session may uncover a defect, an omitted business rule, a training need or a new feature request. Distinguishing them prevents every difficulty from being labelled a bug, while ensuring genuine failures are corrected.
Assign participants and decision authority
- Business owner: prioritises outcomes and accepts the workflows.
- Representative users: execute scenarios under relevant working conditions.
- Test coordinator: organises sessions, test data and issue tracking.
- Technical team: investigates defects, implements fixes and identifies the version under test.
- Specialist owners: review security, data, operations or accessibility where required.
Reserve participants’ time before development is almost complete. Include someone who can resolve conflicting operational rules. If two departments disagree about who may approve a request, a testing session cannot settle that ownership without an authorised decision-maker.
Prepare the environment and records
Use an identifiable application version in a validation environment. Confirm accounts, roles, supported devices, browsers and required connections. Test notifications and transactions should reach the intended test destinations. Identify simulated dependencies clearly: a simulated response does not prove the real system exchange works.
Build representative records without unnecessarily exposing personal information. Include a normal request, missing fields, duplicates and important exceptions. Keep a way to restore the starting state so the team can repeat the scenario after a fix.
Write a scenario someone else can repeat
Start with the requirements in your software project scope. Each scenario should state the role, starting conditions, test data, actions and expected result. “Test the form” does not tell a participant what success looks like.
Illustrative example: sign in as customer A, open a draft request, attach an allowed document, save and reopen the request on another supported device. The document should appear once and remain inaccessible to customer B. Evidence should cover both persistence and access control.
Copy-ready acceptance test grid
Copy this grid into your tracking tool. Add columns for version, tester, date, evidence and defect reference. These scenarios are illustrative and should be adapted to approved requirements.
| ID | Scenario and starting condition | Expected result | Status |
|---|---|---|---|
| UAT-01 | Authorised customer, valid request: save and reopen. | Confirmed fields and attachments remain present without duplicates. | Not run |
| UAT-02 | Required field missing: attempt submission. | Submission stops, a clear error appears and entered data remains available. | Not run |
| UAT-03 | User lacks permission: open a restricted record. | Access is denied without exposing the record’s contents. | Not run |
| UAT-04 | Destination unavailable: submit a transfer. | Pending or failed state is clear; recovery follows the agreed rule without duplication. | Not run |
| UAT-05 | Use the workflow by keyboard on a supported device. | Required actions are reachable and the focus location remains visible. | Not run |
Use distinct statuses: not run, passed, failed, blocked and not applicable with a reason. A test blocked by missing access has not passed. Screenshots can help, but useful evidence also records the data, application version and observed behaviour.
Include exceptions and working conditions
Test interrupted work, repeated saves, role changes, rejected files and expired sessions. Review the agreed languages, date formats and error messages. For mobile or field workflows, include the network conditions covered by the scope. An offline requirement needs its own explicit acceptance criteria.
The W3C’s preliminary accessibility checks help identify some straightforward barriers. W3C explains that these checks are not a complete evaluation. Plan assessment appropriate to the project’s agreed accessibility target instead of treating a few successful checks as certification.
Record defects so the team can act
For each failure, record repeatable steps, expected behaviour, observed behaviour and the impact on work. Agree on severity using that impact: an essential workflow is blocked, information is exposed, a result is wrong or a limited inconvenience remains. Correction priority is an explicit decision that should also consider dependencies and available workarounds.
After a fix, repeat the failed test and relevant neighbouring workflows. Keep the original issue history. If the expected behaviour changes because the business rule was incomplete, record that decision and update the requirement as well as the scenario.
Make an evidence-based acceptance decision
Review unexecuted scenarios, open defects, specialist findings and operational readiness. A high pass percentage can hide one unacceptable failure. The important question is which outcomes remain unsafe, incorrect or unavailable, and whether their impact is acceptable to the authorised owner.
The decision may be acceptance, acceptance with documented conditions or postponement. Each condition should identify its impact, acceptable workaround, owner and agreed resolution date. Do not let an unresolved issue disappear into an informal promise to address it later.
Acceptance and deployment authorisation may be separate decisions. Record both, identify the accepted version and prepare support instructions, monitoring and recovery. Plan a short, authorised validation after launch to confirm essential workflows in the live environment.
Prepare validation as part of delivery
Hamdi Services includes testing, documentation and knowledge transfer in launch preparation; support and future development are defined in the proposal. To discuss your custom application, bring the workflows your team needs to accept, the people who can test them and any constraints on the release decision.
Stock photograph: Jakub Zerdzicki / Pexels. This illustration does not depict a Hamdi Services team or client engagement.