The new application looks finished. The demonstration went well, and the developer says the main tests pass. Your staff still need to establish whether it handles the work your business will depend on after launch.
User acceptance testing, or UAT, is the business's opportunity to verify that software meets agreed requirements through realistic tasks. The people who use and own those tasks check the results, record problems, and decide whether the release is acceptable for its intended use.
This user acceptance testing checklist covers the workflows, data, permissions, integrations, and operating arrangements to verify before launch. It applies to new business applications, major upgrades, replacement systems, and changes to established software.
What should user acceptance testing verify?
UAT should establish that representative users can complete the agreed business work and get the correct outcome. That includes exceptions, handoffs, restrictions, and recovery when something goes wrong.
A useful UAT record answers four questions: what did the user attempt, what should have happened, what actually happened, and who accepted the result? A screen opening successfully is only one small part of that evidence.
Technical QA covers matters such as individual functions, software defects, security checks, and repeatable regression tests. UAT adds business judgment about whether the delivered behavior fits the agreed workflow. Both contribute to launch readiness. Business acceptance does not replace specialist security, accessibility, performance, or recovery testing where the project requires it.
Before UAT: agree on scope, people, and entry criteria
Start planning acceptance while requirements are being defined. Identify the workflows that must work at launch, the people who can confirm their rules, and the results that count as acceptable. Our software discovery deliverables checklist explains how to establish that shared scope early.
Ask actual users to participate, including people who enter records, review work, correct mistakes, and manage the outcome. A project sponsor may authorize launch while a finance owner confirms financial results and an operations owner confirms daily work.
Before the testing window begins, verify that:
Use synthetic or appropriately masked data that preserves important relationships and edge cases. If an integration uses a simulator or sandbox, record what that setup cannot establish about production behavior. The release plan should address those remaining checks explicitly.
User acceptance testing checklist for business applications
1. Complete the critical workflow from beginning to end
Follow a piece of work through every person and system involved. For example, create a request, review it, return it for correction, approve the corrected version, and verify the result in the downstream system.
Check the outcome outside the originating screen. A success message does not prove that an invoice exists in accounting or that a notification reached the intended recipient.
2. Verify permissions using representative accounts
Test with the roles people will actually receive. Administrator accounts can conceal problems because they bypass restrictions that ordinary users experience.
Business testers should confirm whether the access rules match their responsibilities. The technical team should verify that those rules are enforced across the application, including APIs and downloads.
3. Check approvals, limits, and conflicting actions
Approval testing needs values below, at, and above each relevant boundary. Include the people who submit requests as well as those who authorize them.
Agree on the expected result before running the scenario. An undocumented business rule discovered during UAT may require a scope decision as well as a software change.
4. Reconcile migrated data, calculations, and reports
Choose examples whose correct values are known. Include old records, unusual statuses, rounding boundaries, and records with several related items.
Our guide to business data migration costs and testing explains why reconciliation, correction, and cutover need their own scope. A sample of plausible-looking records cannot establish that a full migration is complete.
5. Confirm integrations and notifications
Follow the business event across the connection. Check what the destination received, how the source represents completion, and what staff see while the transfer is still pending.
Distinguish a successful test against a sandbox from production configuration readiness. Credentials, endpoint addresses, scheduled jobs, and recipient lists belong in the launch checks too.
6. Test mistakes, interruptions, and exceptions
Use the system the way a busy person might. Submit incomplete information, double-click an action, reopen an old link, and interrupt a connection in a controlled test.
For mobile or field use, add the agreed offline and synchronization scenarios. Record whether information is saved on the device, waiting to upload, or confirmed in the main system.
7. Check usability, accessibility, and supported devices
Watch representative users perform tasks with the equipment they normally use. Let them attempt the work without continuous coaching from the person who built it.
Include specialist accessibility testing where required. Our website accessibility testing guide covers checks that automated scans alone can miss.
8. Assess response times and expected workload
Ask users whether normal work is practical with representative data volumes. Set measurable expectations for operations where delay affects the business, such as loading a job list or producing a month-end report.
A few business testers using the application at once cannot establish capacity for a much larger production workload. Record what was measured and the conditions under which it was measured.
9. Verify support, recovery, and launch responsibilities
Users need a way to get help on the first working day. The operating team needs to know how failures are detected, investigated, and resolved.
Rollback can be complicated once people have created live records or sent transactions to another system. Establish what recovery would mean for those records before approving the launch. Honor Tech's go-live support service can help coordinate readiness and the transition under an agreed scope.
UAT test case template: record expected and actual results
Give each scenario an ID, a business requirement, a tester, a role, test data, steps, and an expected result. After execution, add the actual result, pass or fail status, supporting evidence, and any linked defect. Use Blocked or Not Run when the scenario has not been demonstrated.
These examples show how a hypothetical purchasing application could turn broad requirements into testable business outcomes:
| Scenario | Test setup | Expected business result | Evidence to capture |
|---|---|---|---|
| Submit a valid request | Requester account, permitted department, known supplier and amount. | One request is saved with the correct values and assigned to the right reviewer. | Request ID, saved values, reviewer assignment, and notification. |
| Attempt self-approval | Approver account submitting its own request. | Approval is blocked and the request remains available to an eligible reviewer. | Blocked action, unchanged status, and relevant history. |
| Change an approved amount | Approved request and a user allowed to request a correction. | The agreed correction process preserves the previous decision and requires any necessary new approval. | Original approved values, revised values, and new approval status. |
| Retry a delayed transfer | Approved request and a controlled integration delay in the test environment. | Staff can distinguish pending from completed work. Retry follows the agreed recovery process without creating duplicate financial records. | Source ID, destination ID, status history, and final record count. |
Keep the scenario small enough to investigate, while retaining the complete business outcome it verifies. Evidence might include a record ID, a screenshot, a reconciliation result, or confirmation from the destination system. Handle that evidence according to the sensitivity of the information it contains.
Report defects, retest fixes, and control changes
A useful defect report states the release version, tester's role, starting data, steps, expected result, actual result, and business impact. Include enough evidence for someone else to reproduce the problem.
Agree how the team will distinguish launch blockers, defects that can be accepted temporarily, and requests for new scope. A minor-looking issue can be serious if it exposes confidential records or produces the wrong financial result. Rank the effect on the business, not just its appearance on the screen.
After a fix, repeat the failed scenario and relevant neighboring workflows against the updated release candidate. Record the new version and outcome. A developer marking a defect fixed does not establish that the business has verified the result.
If requirements change during UAT, update the acceptance criteria and assess the effect on cost, timing, and earlier results. Our guide to automated regression testing for existing business applications explains how repeatable checks can support this work and protect important behavior after launch.
UAT sign-off checklist: decide whether the release is ready
A high pass percentage can conceal one failed workflow that prevents the business from operating. Review coverage and unresolved consequences before making the launch decision.
A concise sign-off record can state the system and version, scope tested, test dates, participating owners, evidence location, open issues, accepted conditions, and decision. The decision may be approval, conditional approval within explicitly agreed limits, or a delay pending correction.
Approval should identify exactly what the business is accepting. It does not prove that untested functions or future changes will behave correctly.
Common questions about user acceptance testing
Who should perform UAT?
Representative users and business process owners should verify the workflows they understand. Developers and QA staff support setup, investigation, and retesting. A named business authority makes the acceptance decision for the agreed release scope.
How long should user acceptance testing take?
Duration depends on the workflows, roles, data preparation, integrations, tester availability, and time required for fixes and retesting. Plan enough time to execute the agreed scenarios and resolve their results. A fixed number of days does not establish adequate coverage.
Can UAT be automated?
Some acceptance scenarios can be expressed as automated checks with agreed expected results. Business users still need to judge workflow fit, clarity, unusual situations, and whether the delivered behavior meets the business need.
Should UAT happen in production?
Run planned UAT in a controlled environment with representative configuration and data. Use separately planned production checks after deployment to verify the live setup. Those checks need safeguards for real messages, payments, records, and other consequences.
Build a launch decision your business can support
Honor Tech can help define acceptance scenarios, prepare test data, coordinate defect review, and verify the business workflows that matter before launch. Our QA and test automation service can support the technical checks and repeatable evidence needed alongside business acceptance.
Tell us what your team is preparing to launch. Share the application, the critical workflows, the people involved, and any known deadline so we can help scope the testing and readiness work.