User Acceptance Testing (UAT): Template, Checklist & Examples

User acceptance testing (UAT) is the final round of testing in which the client or real users check that a website or web app does what they need before it goes live. On agency projects it's also the moment the client formally says "yes, this is what we ordered". When the client tests from written scenarios and the sign-off criteria are agreed before anyone starts, it ends with a clear yes instead of a trickle of new requests. The free test plan and sign-off form below are built for that.

What is user acceptance testing (UAT)?

User acceptance testing is testing done by the people who will own or use a product, against their real tasks, to decide whether they accept it. The developer asks "does it work?"; UAT asks "does it work for us?". The ISTQB glossary, the reference vocabulary for software testing, defines acceptance testing the same way: deciding whether a system satisfies the needs of its users.

For a website, that means the client's marketing manager publishing a blog post in the CMS, the sales team receiving the contact form leads, or a customer buying a product with a discount code. For a web app, it's the users doing their daily job in the new system.

UAT normally ends with a sign-off: a written approval that the site can go live and the project phase is complete. That sign-off matters for the agency too, because it marks where the agreed scope ends and new requests begin.

Who performs UAT on a website project?

The client, their staff or a small group of real end users perform UAT; the agency prepares it and fixes what it finds. The client or product owner runs the scenarios, decides what blocks the launch and signs off; the project manager writes the scenarios with the client and triages issues; developers and designers fix them but don't test their own work here.

The key rule: the people who built the site don't do the acceptance testing. They already know how it's supposed to work, so they don't see the problems a first-time user hits.

What is the difference between UAT and QA?

QA asks whether the site is built correctly, and the team that builds it runs it against the specification during and after development. UAT asks whether it's the right thing for the client, and the client or real users run it against business tasks just before launch. QA ends with issues fixed; UAT ends with a formal sign-off.

Do QA first. If the client starts UAT on a site full of broken forms and layout bugs, they'll spend their time reporting things you should have caught, and lose trust in the process. Our website QA checklist covers that step.

How do you plan user acceptance testing?

Plan UAT in six steps: agree what is in scope, write ten to twenty test scenarios with the client, prepare a staging site with final content and real email delivery, name who tests what and by when, explain how to report issues, and agree the sign-off criteria before anyone starts testing. Skipping the last step is what turns UAT into an endless list of extras.

1. Agree the scope: list what will be tested, such as page templates, forms, checkout, CMS tasks and integrations. Anything outside that list is not part of acceptance.
2. Write test scenarios with the client: each scenario is a real task, written as steps with an expected result (see the examples below). Ten to twenty cover most brochure sites and small shops.
3. Prepare the environment: a staging site with final content, real email delivery and test-mode payments, plus logins for the testers who need them.
4. Set dates and testers: name who tests what and the deadline. "Whenever you have time" means UAT never ends.
5. Explain how to report issues: one issue per report, with a screenshot and what they expected.
6. Agree sign-off criteria first: before testing starts, not after.

What does a UAT test scenario look like?

It's a real task written as a short sequence of steps with an expected result, so the tester can mark it as passed or failed. It's phrased in the client's words around a business goal, such as "a customer buys with a discount code", rather than around a technical component. The tester fills in the result and any notes.

If the client can't describe the expected result of a scenario, that's a requirement that was never agreed, and it's better to find it now than after launch.

User acceptance testing checklist for websites

Before the client starts, run through this list so the round tests the site, not the setup. It complements the scenarios: the scenarios check tasks, the checklist checks that everything needed to test those tasks is in place.

• QA finished and its issues fixed or listed
• Staging site has final content, not placeholders
• Emails from forms and orders arrive at the client's real addresses
• Payments run in test mode, with test card details shared with testers
• Every tester has a login with the right role, if the site has accounts
• Scenarios, deadline and sign-off criteria sent in one message
• One reporting channel agreed (no email, WhatsApp and calls in parallel)
• A way to tell bugs from change requests (a label or a separate list)
• The person who triages issues named, with a time to do it each day
• Re-test date booked for after the fixes

How should clients report UAT issues?

Each issue should be one report with the scenario ID, what happened and what the tester expected, the page URL, the device, system and browser, a screenshot with the problem marked, and a severity: blocker (can't launch), major (must fix before launch) or minor (can wait). Clients forget half of these by email, so the format has to be easy or automatic.

This is where most UAT rounds slow down. Clients are not testers: they send emails like "the form doesn't work on my phone" with no page, no phone model and no screenshot, and each vague report costs a round of questions. A complete one looks like this:

UAT-02: Discount code not applied on mobile

On iPhone (Safari), after entering SPRING10 in the cart, the message
"Code applied" appears but the total doesn't change.
Expected: 10% off.
URL: staging.example.com/cart/
Severity: blocker

Our bug report template has the full set of fields if you want to share a written format. A visual feedback tool fills most of them in for you. With GiveFeedback.io you add a script to the staging site and a feedback button appears. The client clicks it, marks the problem on a screenshot of the page, writes a title and description, and the report arrives with the URL, screen resolution, operating system, browser and version already attached. Testers don't need an account.

You can invite the client to the project so they see a read-only list of everything reported and its status (open, resolved, archived), and send each report to the team's tracker: an issue in Jira, a task in Asana, ClickUp or Wrike, a card in Trello, or a message in Slack or Discord. For most website UAT, a marked-up screenshot with the browser data is all the developer needs to fix the issue.

When is UAT done?

When the criteria agreed before testing are met: every scenario has been run at least once, no blocker or major issue is open, minor issues are listed with a fix date, change requests are logged and estimated separately, and the client confirms in writing. Without written criteria, UAT turns into an open-ended list of "one more thing".

Typical sign-off criteria for a website:

• Coverage: all test scenarios have been run at least once.
• Severity: no open blocker or major issues.
• Minor issues: listed with an agreed fix date; they don't block the launch.
• Change requests: logged separately and estimated.
• Confirmation: the client approves in writing, by email or with the sign-off form above.

A simple sign-off email from the client is enough on most projects:

We've completed acceptance testing of the new website on staging.
All scenarios UAT-01 to UAT-15 pass. The three minor issues in the
list will be fixed in the first week after launch. We approve the
site for go-live on 14 November.

With criteria like these you have a clear line: the site does what was agreed, it launches, and anything new is the next phase. For the approval step itself, see our guide to client website approval.

What are the most common UAT mistakes?

Five come up on most projects: starting before QA is finished, asking the client to "have a look" instead of giving scenarios, collecting feedback through five channels, mixing bugs with new requests, and leaving the round without a deadline. Each one makes UAT longer and turns a check on agreed tasks into a debate about taste.

• Starting before QA is finished: the client spends their time on bugs you should have caught.
• No scenarios, just "have a look": you get opinions on colors instead of checks on tasks.
• Feedback in five channels: email, WhatsApp, calls and comments on a PDF. Pick one channel and say so.
• Mixing bugs and new requests: label them separately from day one.
• No deadline: put UAT dates in the plan and in the contract.

Write ten to twenty scenarios with the client this week, agree what "done" means and choose one place for issues. That alone turns UAT from the most stressful part of a project into a short, predictable checklist.