Acceptance testing (UAT): when the decider is not the tester

A team ships a billing module. The unit tests pass, integration passes, end-to-end passes. Green everywhere. They deploy it on a Friday. On Monday the accountant opens it, makes three clicks and says: "this does not work for me, this is not how we bill". Nobody wrote a single line of bad code. And still the software failed.

That gap has a name. It is called acceptance. And the test that covers it, UAT (User Acceptance Testing), is the one most often skipped, most improvised and worst understood in the entire quality chain. The short answer: UAT does not verify that the software is well built, it verifies that it is the right software for whoever is going to use it. Those are two different questions and almost nobody separates them.

01 · what it isAcceptance answers a different question

There is an old phrase in software quality that captures it: verification asks "are we building the product right?" and validation asks "are we building the right product?". UAT lives on the validation side. It does not care whether the algorithm is elegant or whether coverage reaches ninety percent. It cares about one thing only: whether the person who asked for this can do their job with what you handed them.

The ISTQB testing standard places acceptance as the last of the four test levels, after component, integration and system. And it marks a difference that in practice gets ignored: the earlier levels are run by the technical team against technical specifications. Acceptance is run, or approved, by whoever is going to live with the product. The tester prepares the ground. The decider is not the tester.

Green across the whole suite means the code does what we said. It does not mean we said the right thing.

This is not a technicality. It is the reason a flawless piece of software can be a failure. The accountant in the example did not find a bug. She found a feature that solves a problem she does not have, and that does not solve the one she does have. No technical test level would have caught that, because all of them start from the same wrong specification.

02 · the mistake"I like it" is not a criterion

Here is the original sin of almost every UAT. A user is summoned, sat down in front of the system and asked to "check whether it is fine". The user browses for a while, does whatever comes to mind, and in the end delivers a verdict: "I like it" or "I am not convinced". That is not an acceptance test. It is an opinion poll in disguise.

The problem with "I like it" is that it is not repeatable, not debatable and nobody's responsibility. If the user is having a good day, they approve. If they are having a bad day, they reject. And when a problem shows up in production, nobody can point to what exactly was accepted, because it was never written down. Acceptance turned into a mood.

The alternative has a name that sounds bureaucratic but saves projects: acceptance criteria. They are concrete, verifiable conditions agreed before building, that define what it means for something to be done and acceptable. Not "the invoice looks fine", but "an invoice with three items, two with VAT and one exempt, computes the correct total and shows it in pesos with two decimals". That can be tested. That passes or fails. That does not depend on anyone's mood.

There is a format that helps you avoid rambling, popularized by behavior driven development: given a context, when an action happens, then a result is expected. "Given a customer with no credit limit, when they try to bill on credit, then the system blocks them and shows message X." You do not need the full ceremony. You need the discipline of writing the expected result beforehand, not improvising it while staring at the screen.

A measurable criterion: pass or fail. Personal taste: depends on who and on when. Only one of the two can be signed off.

03 · how it is doneAcceptance that can be signed off

A healthy UAT has three moments, and none of them is "the user plays around for a bit". The first happens before writing code: the acceptance criteria are agreed with whoever is going to decide. If the business cannot say in advance what would make them accept, the team is building blind and UAT will only discover the disagreement late and expensive.

The second moment is execution. The user, or QA alongside the user, walks through real business cases against those already written criteria. Not technical edge cases: cases the person actually lives. The accountant bills the type of invoice she bills every day, with the odd data she knows and the team does not. That domain knowledge is exactly what UAT contributes and no other test level has.

The third moment is the verdict, and this is the one almost nobody formalizes. Acceptance ends with a traceable decision: it is accepted, accepted with listed caveats, or rejected with concrete reasons tied to criteria. That decision has an owner with a name. In many contractual frameworks this is literally a contract acceptance test: what gets signed defines whether the supplier delivered. It is not a process detail. It is where the risk changes hands.

04 · where it fitsUAT does not replace QA, it closes it

A frequent misunderstanding: believing that if there is UAT, technical testing is redundant, or the other way around. The two test different things. Unit, integration and system tests make sure the product is well built. Acceptance makes sure it is the right product. Skipping the first ones leads you to a right product full of defects. Skipping the second, to a flawless product nobody wanted.

That is why UAT is the last gate, not the only one. It arrives when the technical side is already green, and even so it can say no. That "no" at the end is uncomfortable, but it is cheaper than the customer's "no" in production.

One single idea to take away: acceptance is not measured in coverage, it is measured in decisions someone can sign off. The day your UAT produces a document where someone responsible says "I accept these criteria and reject these others, for these reasons", you stopped doing theater and started doing acceptance. And on Monday morning, when the accountant opens the module, you will already know the answer before she speaks.