Client user acceptance testing — what to check

Client user acceptance testing, usually shortened to UAT, is the stage where the client — not the supplier — tests the finished site against what was originally agreed to be built. It is the last real opportunity to catch a problem before the site is public, and it is also, in practice, the stage most often reduced to a quick glance rather than a genuine test, because by this point in a project the client is commonly tired of it and eager to launch.

What UAT is actually checking, and how it differs from internal QA

Internal review, covered on the internal review and QA page, checks whether the build works technically, performed by the people who built it. UAT checks something different: whether the finished site actually does what the client understood was being built, performed by the person who understands the business best. These catch different classes of problem. A technically flawless contact form that asks for the wrong information, because the supplier misunderstood what the client actually needed to collect from an enquiry, will pass every internal technical check and fail UAT — because it is not a technical fault, it is a misunderstanding about intent that only the client is positioned to notice.

What to actually test, not just look at

Area to test	What “just looking” misses
Every form, submitted for real	Whether the submission actually reaches the right inbox, and what the confirmation says
Navigation, clicked through as a real visitor would	A menu that looks right but leads somewhere unexpected
Content, read in full rather than skimmed	Wording that was correct in an earlier draft but is now out of date
A real transaction, if the site sells anything	Whether checkout, tax and confirmation emails actually behave correctly end to end
Every page on a phone, held in the hand	Layout problems a resized desktop browser window does not reveal

The distinction between reviewing and testing is the whole point of this stage. Looking at a page and judging whether it appears correct is review. Submitting the actual enquiry form and confirming the email arrives, correctly formatted, in the right inbox, is testing. Only the second one reliably catches the kind of fault that costs a real enquiry after launch.

Why user acceptance testing is treated as a formality more than any other stage

By the time a project reaches UAT, weeks or months have usually passed since the first conversation, several rounds of feedback have already happened, and the client is naturally keen to see the project finished rather than to keep finding things wrong with it. This fatigue is real and it is the reason UAT is, candidly, the stage with the least genuine scrutiny applied to it across the whole build — not because clients do not care about quality, but because motivation to keep testing thoroughly is at its lowest exactly when a fresh, careful look matters most.

Treating UAT as a formality — a quick scroll through the homepage and an email saying “looks good” — is the single easiest way for a defect to reach a live, public site. The fix is not more suspicion of the supplier; it is a deliberate, structured pass through the checklist above, ideally by more than one person inside the business, before approval is given.

Ecommerce and functional builds need this more, not less

On a site with real functionality — bookings, payments, product variants, account creation — UAT should include a genuine end-to-end test of that functionality, not a visual check of the pages around it. A completed test purchase through to a real (or clearly marked test-mode) payment and confirmation email is the single most useful thing a client can do at this stage on an ecommerce build. General information on what a platform such as Shopify handles for this kind of testing, and what still needs manual checking regardless of platform, is on Shopify explained.

What happens to defects found during UAT

Faults found here are normally fixed before launch at no additional cost, because they represent the site not yet matching what was agreed — this is different from a new feature request, which is treated as additional scope. A short list of test cases run against specific scenarios — “submit the contact form with a long message”, “add three items to the cart then remove one” — is a more useful record of a defect than a vague description, because it lets the supplier reproduce it directly rather than guessing at the steps. It is worth both sides being clear, before UAT starts, on that distinction: a genuine defect against the agreed scope is a pre-launch fix; a new idea that occurred during testing is a change request, and naming which is which as issues are raised avoids a dispute at the point everyone is trying to finish the project.

How many people inside the business should test

Involving more than one person is worth the modest extra time it takes to coordinate. A business owner reviewing the site alone tends to check it against their own mental model of the business; a staff member who deals with customer enquiries daily notices different things, such as whether the contact form actually asks for the information they need to respond properly, or whether the service descriptions match the language customers actually use when they call. Two people testing independently and comparing notes afterwards catches more than the same amount of time spent by one person alone, because they are not anchored to the same assumptions about what “obviously” works. Consolidate that feedback into one list before it goes back to the supplier, rather than sending two separate, possibly conflicting, sets of notes.

Recording what was tested, not just the outcome

A short written record of what was actually tested — which forms were submitted, which pages were reviewed on a phone, whether a real transaction was completed — is worth keeping alongside the final approval. If a problem is discovered after launch, this record answers a genuinely useful question: was this specific thing tested and missed, or was it never tested at all. That distinction matters for working out whether a fix belongs in warranty coverage or reflects a gap in the testing process itself, and it removes the need to reconstruct, from memory, what was actually checked weeks earlier.

Where UAT sits in the release sequence

Approval at UAT is what allows the project to move to a formal go/no-go review before the site’s release goes live. See the pre-launch checklist for what is verified immediately after UAT is signed off, and before the domain is actually switched over.