UAT without theatre

UAT theatre looks like this: a late invite, a long checklist nobody owns, and a pass or fail that is really a political mood. Everyone attends, a few people click through the happy path, and the release goes ahead because the date was never in question.

I have facilitated user acceptance testing on digital-experience programmes for banking and industrial brands and on global facilities platforms, usually with business owners who had an hour to spare and a release that could not slip. The sessions that worked were set up to produce a decision. The ones that failed were set up to produce attendance.

What user acceptance testing is for

UAT answers one question: will the people who asked for this accept it as built, knowing what we know about it? It is not a second round of system testing and it is not a demo. Functional testing asks whether the product behaves as specified. UAT asks whether that behaviour is acceptable to the business that has to live with it.

The distinction matters because it changes who decides. In functional testing the tester holds the oracle. In UAT the business owner does. My job is to put the right evidence in front of them and keep the session honest.

Signs your UAT is a ceremony

• The invite goes out in release week, after the date is already public.
• The checklist was written by QA and has never been read by the people signing it.
• Nobody can state what result would stop the release.
• Defects found in the session are argued down on the spot because there is no time left to fix them.
• Sign-off is an email that says “looks good”, with no reference to what was exercised.

If two or more of those are true, the session will confirm whatever the room already believed.

Before the session: agree what acceptable means

Real UAT starts while acceptance criteria are still negotiable. Before I schedule anyone, three things are written down and agreed with Product.

1. Acceptance in user language. Each criterion describes an outcome a business owner can observe: a booking confirmed, an invoice that matches the order, a report that reconciles. If it reads like a developer note it is not ready. I go into this in Acceptance criteria Product can actually sign.
2. Journeys in scope. A short list of end-to-end journeys, named the way the business names them, with the data each one needs. Everything else is explicitly out of scope for this session.
3. The evidence that will be shown. Which build, which environment, what functional testing has already verified, and which risks are known going in.

Then I ask one question: would you accept the release if only these pass? Hesitation at this point is cheap. Hesitation in the session is expensive.

During the session: keep a tight loop

I facilitate and the business owners drive. For every observation I capture the same four things.

Screenshots and two-line notes beat long write-ups. When something is unclear it is raised as a question for Product in the room, not left as a QA assumption to resolve afterwards. And when a stakeholder says “that is fine, really”, I write down who accepted what. Verbal acceptance evaporates by the next release.

After the session: a pack that fits on one page

The output is a short pack that Product and Engineering can read without a translator. It has three sections and a recommendation, in the same spirit as a release readiness note people can actually read.

The deferred section is where most packs go soft. A deferral without a named risk, an owner and a review date is just a defect nobody wants to look at.

When stakeholders cannot give you the time

The usual objection is capacity: the business has an hour, not a day. That is workable. Shrink the scope to the journeys that carry revenue, compliance or trust, send the evidence for everything else in advance, and use the hour for the decisions only they can make.

What does not work is replacing them with a proxy who cannot accept risk on their behalf. A proxy can click through a journey. They cannot tell you whether a slow export is tolerable for the finance team in month-end week.

When UAT is a ceremony, quality becomes blame: the release goes wrong and everyone remembers that QA signed it off. When UAT is evidence, the release call is shared, and so is what happens next.