User acceptance testing is the point where people who will actually use the software decide whether it does their job. Not whether it works - that has been tested already - but whether it does the thing they asked for, in a way they can live with.

It is the only testing phase whose purpose is a decision rather than a list of defects. UAT ends with somebody saying yes or no to a release.

What makes it different from every other test

Every earlier phase asks whether the software matches its specification. UAT asks whether the specification was right.

That distinction sounds academic until you watch it happen. A feature can pass every functional test, meet every acceptance criterion as written, and still be rejected in UAT because the person who does the work three hundred times a week can see it will take four clicks where the old way took one. Nothing is broken. The requirement was wrong, and this is the last cheap moment to find that out.

QA testing
Does the software do what we said it would? Run by testers, against the specification
User acceptance testing
Does it do what the business needs? Run by the people whose work it is, against reality

Who runs it, and who should not

The people who will use it. Not the development team, not QA, and not a manager standing in for them.

That is harder than it reads. The people you want are busy doing the job the software is for, and their time is the most expensive part of the whole exercise. Which is why UAT that is scheduled as an afterthought gets delegated to whoever is free, and a release then gets signed off by somebody who has never done the work it supports.

Two roles worth naming: somebody who owns the decision and can say no, and somebody who collects what testers find and turns it into something a developer can act on. Without the first, UAT produces opinions and no outcome. Without the second, it produces a spreadsheet nobody can work from.

What testers should be given

Not a list of features. A list of the things they normally do.

1. Take a new customer from enquiry to first invoice
2. Process a refund for an order paid by card
3. Close the month with two branches reporting separately
4. Correct an address on an order that has already shipped

Those are business processes, and each one crosses several features. A tester handed “check the invoice screen” will check the invoice screen; a tester handed “get a new customer to their first invoice” will find the two places where the process breaks between screens, which is where real problems live.

Give them real data, or the closest safe copy of it. UAT on a database of Test Customer 1 through 20 finds none of the problems that a customer named “O’Brien & Sons (formerly Smith)” finds immediately.

When it is finished

Before it starts, agree what “yes” means. In writing, and in terms somebody can check.

  • Which processes must work, and which are allowed to be awkward
  • What counts as a blocker versus something to fix in the next release
  • Who signs, and what they are signing for
  • How long it runs. UAT with no end date does not end; it fades

The most common failure is not a bad test, it is an unclear finish. A phase that runs until people stop reporting things ends when they get bored, and a release that ships on boredom is a release nobody agreed to.

The reports UAT produces

This is the part development teams brace for, and the reason is structural rather than anybody’s fault.

Your testers are not testers. They are accountants, dispatchers, nurses, salespeople - and they describe what happened in the language of their job rather than the language of the software. “The invoice went to the wrong branch” is a perfectly clear sentence and it is not reproducible. It is missing which invoice, which branch, what was on screen, and what they expected instead.

Two things help more than anything else:

Ask for the process, not the diagnosis. “What were you doing, and what did you expect to happen?” gets you further than any form, because a business user’s guess at the cause is usually wrong and usually replaces the facts.

Take the technical part out of their hands. Nobody in UAT should be asked for a browser version, a console log, or steps written for a developer. Getting that right is what tooling is for, and the less you ask of a tester the more they will report.

Session Replay

Free Chrome extension. One click on the page that is misbehaving captures the screenshot, the console and the network log, and hands you a link to paste into the ticket.

Get the extension

Whoever collects the reports still has to turn each one into something a developer can act on, and the bug report guide is the shape that takes. If a UAT finding cannot be reproduced, it will be closed unresolved no matter how real it was.

The short version

UAT asks whether software does the job, decided by the people whose job it is. Give them processes rather than screens, real data rather than test rows, an agreed definition of yes, and as little technical homework as you can manage. What comes back will be phrased in their language, and turning that into something reproducible is the work - not a sign that they tested it wrong.