User Acceptance Testing: Process, Checklist, and Criteria

User acceptance testing answers one question: does this do the job the business needs, using real scenarios and real data, judged by the people who will use it. It is not a second round of QA. QA asks whether the software works as specified; UAT asks whether the specification was right.

This guide covers who should test, how to write acceptance criteria that produce a clear verdict, how long to allow, and how to run the sign-off so a project does not stall at the last step.

Key takeaways

• UAT is a business activity: Run by the people who do the work, not by the development team.
• Write criteria before the build: Acceptance criteria agreed afterwards become a negotiation.
• Test the exceptions: The happy path passes; the awkward cases decide whether the system gets adopted.
• Allow 5–10% of the timeline: And book the testers' time in advance, because that is what usually slips.

Separate UAT from QA

Both are necessary. Sending software to UAT before QA has finished wastes business users' time on defects the team could have caught, and it is the fastest way to lose their willingness to participate next time.

Choose testers who do the work

The right testers are the people whose daily work the system changes, not their managers, and not a project team that has been close to the build for months.

Include someone who handles exceptions. They know the cases that break assumptions, and they are the reason UAT finds things QA cannot: the rule nobody wrote down, the customer type that behaves differently, the month-end process that works nothing like the rest of the month.

Book their time formally. UAT slipping because testers were pulled onto day-job work is the most common cause of a delayed go-live, and it is a scheduling failure rather than a software one.

Write acceptance criteria before the build

Criteria written after delivery become an argument. Written before, they are a contract both sides can check.

Good criteria are specific, observable and binary. "The system should be fast" is untestable. "A search returns results within two seconds with 50,000 records loaded" is testable, and a supplier can build to it.

Cover the non-functional requirements too: performance under realistic volume, behaviour on a poor connection, what happens when an integration is unavailable. These are the requirements most often left implicit and most often disputed at sign-off.

Test scenarios, not screens

A screen-by-screen walkthrough finds cosmetic issues. End-to-end scenarios find the ones that matter.

Write scenarios as complete journeys a real person completes: take an order from arrival through fulfilment, onboard a customer from enquiry to first use, process a month-end close. Each should have a starting state, the steps, and a clearly correct end state.

Then add the awkward ones deliberately: the cancelled order, the duplicate record, the customer who does not fit the standard type, the approver on leave, the integration that times out. Automating the routine 80% is straightforward; whether the remaining 20% is handled determines whether staff adopt the system or build a workaround around it.

Use realistic data

Testing with clean invented data proves the system works in conditions it will never meet. Use a representative copy of real data: including the messy records, the historical oddities, the entries with missing fields.

Where that data is personal, anonymise or pseudonymise it before it reaches a test environment. Under GDPR and Turkish data protection law, copying production personal data into an unsecured test system is a common and avoidable compliance failure.

Allow enough time, and expect a second pass

Budget 5–10% of project duration for UAT: roughly one to two weeks on a three-month project, longer where several departments are involved.

Plan for two rounds. The first surfaces findings; the second confirms the fixes. Projects scheduled with a single UAT window and go-live immediately after have no room for the second, which means either shipping known defects or slipping the date publicly.

Classify findings before you triage them

Not everything raised in UAT is a defect. Findings split three ways, and mixing them is why UAT triage meetings run long.

Defects, the system does not meet an agreed criterion. The supplier fixes these within scope.

Change requests, the system does what was agreed, but the business now wants something different. These are priced and scheduled, not fixed for free.

Misunderstandings, the system is correct but the tester expected something else. These are training or documentation issues, and they are useful signals about the interface.

Agree who classifies, and how disagreements are settled, before UAT starts.

Define what sign-off means

Sign-off should be a decision with three possible outcomes: accept, accept with conditions, or reject, with named conditions and dates where relevant.

Establish in advance who signs, what severity of open defect blocks a launch, and what happens to accepted-with-conditions items after go-live. A conditional acceptance with no owner and no date is how known defects become permanent.

Carry UAT findings into launch

The output of UAT is not only a decision. It is a list of what confused people, which becomes your training material; a list of accepted defects, which becomes the first post-launch backlog; and a set of scenarios worth keeping as regression tests for the next release.

Teams that treat UAT as a gate get a yes or a no. Teams that treat it as evidence get a launch plan.

Related guides

• For a wider view of the same problem, see How to Build a Business Case for Custom Software.
• The next practical step is described in How to Choose a Digital Transformation Partner.

When the build described in User Acceptance Testing: Process, Checklist, and Criteria needs a team behind it, Discuss Your Software Project.