User Acceptance Testing Checklist

What is user acceptance testing?

User acceptance testing (UAT) lets the people responsible for a business process check whether software supports their agreed needs. Its output is an acceptance decision supported by results, evidence and a record of remaining issues. It complements technical testing; teams should agree which checks belong in each stage before UAT starts.

Use this checklist as a starting point and adapt it to your project’s risks, users and approval process. A high pass rate helps the discussion, but it does not explain whether the failed scenarios block an important business activity.

1. Agree scope, owners and acceptance criteria

• Name the business owner, participating testers, defect reviewers and final approver.
• List the workflows included in this cycle and explicitly record exclusions.
• Write observable acceptance criteria for each important outcome. Include access restrictions and non-functional expectations that business users need to assess.
• Agree what blocks acceptance, how exceptions will be recorded and who can accept a remaining risk.

2. Prepare the environment and test data

• Record the software version, testing environment and planned testing period.
• Provide each tester with the correct role and confirm access before the session.
• Prepare representative test records, including boundary values, missing information and invalid inputs. Use synthetic or appropriately protected data.
• Check prerequisites, integrations needed for the agreed scenarios and a way to reset test data.
• Agree entry criteria: required technical testing is complete, known limitations are shared and the core business paths can be attempted.

3. Connect requirements to executable scenarios

For each requirement, identify the test cases that will verify it. A useful case includes a starting state, steps and expected results. Include alternative paths and permission checks, not just a successful submission.

A traceability matrix helps reviewers find requirements without test coverage. Rwanda’s RISA guidance on requirement traceability recommends mapping requirements and tests in both directions. This checklist does not claim certification or regulatory compliance.

Worked example: purchase approval

This is an illustrative scenario, not customer data. The requirement is that only an authorized manager may approve a submitted purchase request.

Before testing, the business owner should confirm that these outcomes match the intended process. If the requester can approve their own request, record a defect and assess the business impact before considering acceptance.

4. Execute, record and triage

• Record the actual result against each execution. Distinguish passed, failed and unexecuted work.
• Attach relevant screenshots or documents without exposing secrets or unnecessary personal data.
• Link a defect to a failed execution and include reproducible steps, expected behavior and actual behavior.
• Review impact with the business owner. Keep blockers visible and agree responsibility for the next action.
• Retest fixes and affected neighboring workflows. Keep the updated result and evidence with the testing cycle.

5. Review exit criteria and record sign-off

Review coverage and outcomes together. Confirm which required cases ran, which remain untested and whether unresolved issues breach the agreed acceptance criteria. If an exception is accepted, explain its impact, owner and follow-up date.

Include these fields in the decision record

• Project, release/version, environment and testing period.
• Scope, linked requirements, test run references and evidence location.
• Execution summary, unresolved defects and any untested scope.
• Decision: accepted, accepted with documented conditions, or not accepted.
• Conditions, accountable owners, approver’s full name and decision date.

In Verixa, use requirements traceability to connect the scope to cases, then bring results and defects into the review. Keep the decision understandable to business stakeholders who did not execute the tests themselves.