Of all the phases in a technology project, user acceptance testing is the one most consistently sacrificed — and the one whose absence is most expensive. I have seen the same movie play out many times.
A team builds for months. The timeline slips, as timelines do. The slip gets absorbed by compressing the end of the plan, and the end of the plan is UAT. Business users are given two rushed weeks, vague instructions, and a system loaded with artificial data. They click around politely, sign the acceptance form, and the project celebrates. Then production go-live arrives, and the first month becomes an unofficial UAT conducted on live customers.
If you want to run UAT properly, the first thing to fix is not the test scripts. It is the mindset. UAT is not a quality assurance phase — QA should already have verified that the system works as specified. UAT answers a different question: does the system work for the business as it actually operates? Those are not the same question, because specifications are always an imperfect translation of reality. UAT is where the translation errors surface. Treating it as a formality means choosing to discover those errors in production instead.
From that mindset, the practical rules follow naturally.
First, test with the real users, not their representatives. The manager who attended the requirements workshops is the worst possible tester, because they will test the system they asked for. The clerk who processes two hundred cases a day will test the system as it will actually be used — including the weird cases, the shortcuts, and the workload pressure no requirements document captures. Getting these people released from daily duties for testing is a fight worth having with their managers, and it must be fought early.
Second, test real scenarios with realistic data. Happy-path scripts written by the build team prove nothing except that the demo works. Pull actual operational cases from recent history — the messy ones, the exceptions, the customer who has three accounts and a special pricing arrangement. If data privacy prevents using production records directly, invest in properly anonymised or synthetic data that preserves the mess. Clean test data is a lie you tell yourself.
Third, define what acceptance means before testing starts. Entry criteria: the system is stable, QA is complete, environments and data are ready. Exit criteria: which severity of defects blocks go-live, which can be accepted with workarounds, and who has the authority to decide. Without this agreed upfront, the final week becomes a negotiation where schedule pressure wins every argument.
Fourth, treat every defect found as a victory. This sounds obvious and is culturally very hard. Project teams under deadline pressure experience UAT defects as attacks. Leadership sets the tone here: a defect found in UAT costs a fraction of the same defect found in production, in money and in reputation. Celebrate the testers who find problems. They are saving the project from itself.
Fifth, manage UAT as actively as the build. Daily defect triage, visible progress tracking, fast turnaround on fixes, retesting discipline. UAT left to run itself produces a pile of vague feedback nobody can act on.
What changes with AI is worth a closing note, because it is changing fast. AI can now generate test scenarios from requirements documents, propose edge cases humans find tedious to enumerate, create synthetic test data at scale, and even simulate user journeys before a human ever touches the system. None of this replaces the core of UAT — real users confronting the system with real working knowledge — but it removes the excuse that thorough preparation takes too long.
The forward-looking thought I will leave is this: as AI accelerates how fast we can build systems, the constraint shifts to how fast we can trust them. UAT is the trust factory. The organisations that industrialise it will ship faster than the ones that skip it — which is exactly the opposite of what the skippers believe.
The above reflects my personal views only and is intended for informational and discussion purposes. It does not represent the position of any employer or organisation.