User Acceptance Testing (UAT): A Working Checklist

A practical UAT checklist for business software: who should test, how to write scenarios, how to log defects and what sign-off should mean.

User acceptance testing is the stage where the people who will use the software confirm it does their job. It is often treated as a formality: a demo, a few clicks, a signature. Then the real problems appear in the first week of live use. This is the checklist I use to make UAT find those problems earlier.

What UAT is for

Developer and QA testing ask whether the software works as specified. UAT asks a different question: does it work for the business? A feature can match the specification exactly and still fail UAT because the specification missed how the work is really done.

Before UAT starts

• Pick testers who do the job every day, not only their managers.
• Prepare a separate UAT environment with realistic data: real product names, real price structures, real customer types.
• Agree the entry criteria: QA is complete and no known blocking defects remain.
• Agree in advance what counts as a blocker and what can wait for a later release.

Write scenarios, not test cases

Business users do not think in fields and buttons. They think in situations. Write each scenario as a small story from their day, including the awkward ones.

Scenario 14: Order with an expired offer
Given a distributor with an offer that ended yesterday
When the sales officer places an order using that offer
Then the order is saved without the discount
And the officer sees why

Cover the normal path, the month-end path, the mistake-and-correct path and the approval-rejected path. The exceptions are where systems fail, and users know them better than anyone.

During UAT

• Sit with the testers for the first session. Watch where they hesitate; hesitation is a finding.
• Log every issue in one place with the scenario number, steps, expected and actual result, and a screenshot.
• Classify each issue the same day: defect, change request, or training need.
• Fix and retest in short cycles so testers see progress and stay engaged.

Defect or change request?

This is where most UAT arguments happen. My rule: if the agreed requirement says one thing and the software does another, it is a defect. If the software matches the requirement but the user now wants something different, it is a change request with its own estimate. Good requirements gathering makes this conversation short.

What sign-off should mean

Sign-off is a statement that the agreed scenarios passed and the open issues are known and accepted. Attach the scenario list, the results and the open-issue list to the sign-off. That document protects both the business and the delivery team, and it is the starting point for rollout.