On this page
User acceptance testing (UAT) is the client’s own check that the site does what was agreed, carried out by the people who will use it, before they sign it off. This page explains how it differs from QA, who should be involved, and gives a template you can copy into a document or a spreadsheet.
What UAT is for on a website
QA asks “does it work?” and is done by the agency. UAT asks “is this what we agreed, and can our people do their jobs with it?” and is done by the client. A site can pass QA with every link working and still fail UAT, because the person who handles orders cannot find the one screen they use forty times a day.
- It tests tasks, not pages. A scenario is something a real customer or member of staff does from start to finish.
- It is measured against what was agreed. The brief or the statement of work is the reference, not what anyone would now prefer.
- It is not a round of new ideas. Something that works as agreed but is no longer wanted is a change request, with its own price and date.
- It ends in a decision. The outcome is a signature, or a list of what stands in the way of one.
Who takes part and who signs off
| Role | Who | What they do |
|---|---|---|
| Sign-off owner | One named person at the client with the authority to accept the site. | Agrees the scenarios beforehand. Signs at the end. Settles it when testers disagree. |
| Testers | The people who will use the site: whoever publishes content, handles orders or answers enquiries. | Run the scenarios on their own devices and record what happened. |
| Agency lead | The project manager or producer. | Prepares the template and test accounts, goes through the results each day, and keeps change requests apart from faults. |
| Developer | Whoever built it. | Fixes what failed. Does not mark their own fix as passed: the tester who raised it tests it again. |
One sign-off owner, not a committee. If three people must all agree, name the one who signs once the other two are content.
The template
Four parts. Replace the examples with your own.
1. Scope
UAT scope
- Project
- [Client and site name]
- Address under test
- [Staging address, and the version or date of the build]
- Test window
- [Start date] to [end date]
- In scope
- [The scenarios below, on the devices listed]
- Out of scope
- [For example: content still to be supplied, phase two features]
- Test accounts and data
- [Logins for each role, a test payment method, sample products]
- Devices and browsers
- [Which tester uses which phone, tablet or computer]
- Before testing starts
- [The agency’s QA is complete and final content is loaded]
- Testing is complete when
- [Every scenario has been run, and nothing marked Blocker or Major is open]
2. Test scenarios
One row for each task. Write the expected result before testing starts, so nobody decides afterwards what “right” meant. The first two rows show a result filled in.
| Scenario | Expected result | Actual result | Pass or fail | Severity |
|---|---|---|---|---|
| 1. A visitor finds a product from the home page and buys it by card. | The order confirmation page shows. A confirmation email arrives. The order appears in the shop’s admin with the right totals. | As expected. | Pass | None |
| 2. A visitor sends the contact form from a phone. | A thank-you message shows. The enquiry arrives in the agreed inbox. | Message shows. No email arrived. | Fail | Major |
| 3. An editor publishes a news post with a picture. | The post appears on the news page and the home page, with the picture cropped correctly. | |||
| 4. A customer resets their password. | The reset email arrives, the link works once, and they can sign in with the new password. | |||
| 5. A member of staff marks an order as sent, then refunds another. | The customer gets the right email each time, and the amounts match. | |||
| 6. A visitor refuses cookies. | The site still works, and no analytics are recorded for the visit. | |||
| 7. A visitor opens a link to a page on the old site. | They land on the matching page of the new site. |
3. Severity
Agree these four words before the first result comes in. They decide what must be fixed before launch.
| Severity | Meaning | What happens |
|---|---|---|
| Blocker | The scenario cannot be completed. | Fixed and tested again before sign-off. |
| Major | It can be completed, but with a wrong result or only by a workaround. | Fixed and tested again before sign-off. |
| Minor | Cosmetic, or a wording slip. Nobody is stopped by it. | Listed in the sign-off and fixed by an agreed date. |
| Change request | It works as agreed, and the client would now like it to work differently. | Priced and scheduled separately. It does not hold up sign-off. |
4. Sign-off
Acceptance
We tested [site name] at [address] between [start date] and [end date] against the scenarios in this document.
All scenarios passed, or passed with the minor items listed below, which [agency] will fix by [date].
Open minor items: [list, or “none”]
Change requests raised, to be quoted separately: [list, or “none”]
We accept the site for launch on [date].
Name and role, for the client
Signature and date
Name and role, for the agency
Signature and date
How to run the round
- Finish QA first. UAT is not where broken links should be found. Work down a QA checklist before the client starts.
- Write the scenarios with the client, from the brief. Ten good ones beat fifty that nobody finishes.
- Prepare the ground. Test logins, a test payment method, sample content, and who tests on which device.
- Start with a short call. Run one scenario together and show how to record a result.
- Fix the window. A few working days is enough for a small site. An open-ended test never ends.
- Record each failure where it happened: the page, the element and the device, with the scenario’s number.
- Go through the results every day. Set the severity, merge duplicates and move change requests to their own list.
- Fix, then hand back. The tester who raised a failure tests it again.
- Sign off when the scope’s last line is true. Minor items still open go into the sign-off with a date.
Recording results without retyping them
The table says pass or fail. What the developer needs is the detail of each failure, and a table cell is a poor place for it.
On our own projects the testers record failures with ClickNote, the feedback tool we make. They open a review link, click the element that went wrong and write what happened, with the scenario’s number. Each note keeps the page, the element’s CSS selector, a screenshot, and the device and browser, and can be marked “Something’s broken” or “Question”. The project can be limited to the email addresses of the named testers. When a tester presses “I’ve finished this round”, the agency is emailed.
ClickNote does not produce the sign-off. Keep that as a signed document or an email from the sign-off owner.
Written in November 2026. Spotted something out of date? Tell us.