5–15 scenarios
Real user paths derived from the brief — that’s a website UAT.
2 buckets
Every finding is a blocker or a wish. This line is the acceptance.
1 acceptance
Formal, documented, by the client — then launch and invoice.
The team proves it works. The client proves it’s right.
Both are testing, but they answer different questions — and mixing them up produces projects that are bug-free and still rejected.
QA testing checks the site against technical criteria — browsers, devices, forms, speed. It’s the team’s job, and it should be finished before the client ever starts testing. UAT checks the site against the agreement: the goals from the proposal, the requirements from the brief, the scenarios real visitors will walk. It’s the client’s job — because only the client can declare “this is what we ordered”.
UAT without structure
“Take a look and tell us what you think”
- The client tests taste instead of requirements
- Findings arrive as opinions, scattered over weeks
- Wishes and defects blur into one endless list
- Acceptance never formally happens — the invoice waits
UAT with structure
Scenarios, classification, acceptance
- Test cases derived from the agreed requirements
- Findings pinned to the page, with context
- Every finding classified: blocker or wish
- A documented acceptance ends the project
Website UAT in 5 steps
Lightweight enough for a 10-page website, rigorous enough to carry a final invoice.
- 1
Derive test cases from the promises
UAT tests what was sold, not what was built: every requirement from proposal and brief becomes a checkable statement. “Visitors can book an appointment in under a minute” — that’s a test case.
- 2
Prepare the client, not just the site
The client needs the test cases, a link to the real staging site, and a deadline. Without structure, UAT becomes “clicked around, felt fine” — which accepts nothing.
- 3
Run the pass on real scenarios
The client walks their own customers’ paths: find the service, submit the form, read the confirmation — on their own phone, not your demo setup.
- 4
Record findings where they happen
Every finding pinned to the page with its context, classified: acceptance blocker or wish for later. This classification IS the acceptance negotiation.
- 5
Fix blockers, verify, accept
Blockers get fixed and re-verified by the client. Then acceptance is declared — formally, with a record. Wishes move to the next budget, not into limbo.
The invoice connection
Run UAT where the site lives
Your client tests the real staging site through one link — desktop and mobile, no login. Findings land pinned with device and browser context, the Pilot sharpens vague ones, and the acceptance generates its own timestamped record.
Start bepeq for freeSign-off record generated automatically
Version: staging.clientsite.com
Jul 8, 2026 · 2:32 PM · IP recorded
2 open points (category B) with a deadline
Common questions about website UAT
What is user acceptance testing for a website?
UAT is the client’s own verification that the delivered website fulfills what was agreed: the client walks real user scenarios on the staging site, checks them against the requirements from proposal and brief, reports findings, and — once the blockers are fixed — formally accepts the project. It’s the last gate before launch and final invoice.
What’s the difference between UAT and QA testing?
QA is the team testing against technical criteria: browsers, devices, forms, performance. UAT is the client testing against the business promises: can my customers do what the site was built for? QA finds bugs; UAT finds gaps between expectation and delivery. A project needs both, in that order.
Who performs UAT in a website project?
The client — specifically people on the client side who represent real users: the person who answers customer calls, the office manager who’ll edit content, the decision-maker who signs. The agency prepares the test cases and the environment, but the acceptance judgment must come from the client, or it isn’t acceptance.
What does a UAT test case look like for a website?
A user scenario with an expected outcome: “As a new patient, I find the opening hours within 10 seconds from the homepage” or “I submit the contact form on my phone and receive a confirmation email.” Five to fifteen such scenarios cover a typical website — derived from the goals in the brief, not from the sitemap.
What happens when UAT findings and wishes get mixed up?
The project never ends. The critical discipline is classifying every finding: acceptance blocker (the site doesn’t fulfill an agreed requirement) or new wish (it fulfills the agreement, the client wants more). Blockers get fixed inside the project; wishes become change requests. A tool that forces this classification per finding keeps the acceptance honest.