User Acceptance Testing: What It Is and How to Run It

User acceptance testing (UAT) is the final stage of testing, where the people who asked for a product check that it does what they need before it goes live. It answers one question: can we accept this and release it?

Earlier testing asks "did we build it correctly?". UAT asks "did we build the right thing?". A website can pass every technical check and still fail UAT because the checkout asks for details the sales team never wanted, or because the person who updates the news page cannot work out how.

Where UAT sits in testing

UAT comes last, after the people who built the product have already tested it:

1. Unit testing. Developers check individual functions.

2. Integration testing. Developers check that components and connected systems work together. SIT and UAT are easy to confuse, so check which one a client means when they ask for "testing".

3. System testing and QA. Testers check the whole product against the specification.

4. User acceptance testing. The business checks the product against real needs.

On a small website the first three stages might be one developer and a QA pass. UAT still needs to be its own step, because different people do it with a different goal. It also depends on QA being finished. A client should never be the first person to discover the contact form is broken.

Who does UAT

UAT is run by the business, with the build team in support. On a website project the roles usually look like this:

Two rules save a lot of pain. Developers should not test their own work in UAT, because they know how it is meant to behave and click accordingly. There must also be one named approver, because sign-off by committee is how a two-day round becomes a three-week one.

Choose testers who do the job for real. The person who processes orders every day will spot problems a marketing director never would.

The types of UAT

You will see these terms in contracts and testing guides:

Most website projects blend alpha and contract acceptance. Client staff test on a private copy of the site, and the result decides whether the build is accepted. Add a beta stage when the audience is large or the journeys are hard to predict, such as a new member portal.

The UAT process, step by step

1. Agree what is being accepted

Go back to the signed-off brief and turn each requirement into something a person can check. "Easy checkout" cannot be tested. "A customer can check out as a guest without creating an account" can. If the brief is thin, agree the acceptance criteria now, before anyone tests anything.

2. Write the test plan

The plan records scope, roles, schedule, environment, test data and the rules for handling issues. Our copy-paste UAT test plan template has every section filled in for an example launch.

3. Write scenarios in the user's language

Each scenario should read like a task someone would actually do, with a clear expected result:

• Weak: "Verify POST to /api/quote returns 200."

• Better: "Request a quote for a three-bedroom house. You see a confirmation and receive an email with the price."

Cover the awkward paths too: a declined card, an expired discount code, a form abandoned halfway. Ten good scenarios beat fifty vague ones.

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Start your free trial

4. Prepare the environment and test data

Testers need a stable UAT environment that behaves like the live site, with realistic data and payments in test mode. Agree a deployment window so the site does not change under them mid-test.

5. Brief the testers

Tell them what to test, by when, how to report problems and how much time to set aside. A 30-minute kick-off call is usually enough, and these UAT email templates cover the invitation, reminders and sign-off request.

6. Run the tests and log every issue in one place

Testers work through the scenarios and mark each one passed, failed or blocked. Every issue needs enough detail for a developer to reproduce it: page, steps, expected result, actual result and device.

This is where feedback tends to fall apart, with screenshots in email and comments in chat. Website UAT software keeps it in one queue. QualityHive, which is our product, lets a tester click an element and type what is wrong, and the task arrives with a screenshot and the element pinned.

7. Triage, fix and retest

Review new issues at least once a day. Sort each one into a defect, a change request or a question, then give defects a severity and an owner. Developers fix the agreed items and the person who raised each issue retests it. Re-run nearby scenarios too, because a fix in one place can break another.

Keep change requests separate. "Can the button be green?" may be a good idea, but it is not a failed test.

8. Sign off

When the exit criteria are met, the approver records the decision. Our UAT sign-off template covers full and conditional acceptance, and the user acceptance testing checklist makes sure nothing was missed on the way there.

How long it should take

These are starting points for planning, not benchmarks:

Journeys matter more than page count. A 200-page brochure site can have fewer scenarios than a 10-page booking tool.

Entry and exit criteria

Entry criteria decide when UAT can start. Exit criteria decide when it is finished. Agree both before testing begins, because arguing about what "done" means in launch week never goes well.

Entry criteria (all true before testers are invited in):

• Internal QA is complete, with no open critical or high-severity issues

• The build is deployed to the UAT environment and the version is recorded

• Test data and test accounts are loaded

• The test plan and scenarios are approved

• Testers are named, briefed and have time booked

• The route for reporting issues has been tried by at least one tester

Exit criteria (all true before sign-off):

• Every must-have scenario has been run and passed

• No critical or high-severity issues are open

• Every remaining issue has an owner and a date

• Fixes have been retested by the person who raised them

• The approver has recorded a decision

Add a stop rule as well. If checkout, login or another core journey is unavailable for more than a couple of hours, pause the round and tell testers, rather than letting them report the same outage repeatedly.

Why UAT rounds fail

• UAT is the first proper test. If QA was skipped, testers spend the round reporting broken links and the client loses confidence. Finish QA first.

• Testers have no time. "Can you have a look?" loses to the day job. Agree hours with their manager and book them in calendars.

• Scenarios only cover the happy path. Real customers mistype, go back and abandon baskets. Include those journeys.

• The environment does not behave like live. With caching off, payments faked or integrations missing, a pass proves very little.

• Feedback arrives everywhere. One bug comes by email, another on a call, a third in a spreadsheet. Pick one route and politely decline the others.

• Everything is treated as a defect. New ideas dressed as bugs eat the fix budget. Log them separately and decide on them after launch.

• Nobody can say yes. If the approver is away or must consult a board, the site waits. Confirm their availability before you set the go-live date.

• There is no time left to retest. If testing ends the day before launch, fixes go live unverified. Build the fix-and-retest window into the schedule from the start.

What to do when a round goes badly

Resist softening the exit criteria to keep the date. Choose a response based on what actually happened:

• A handful of specific failures. Fix them and rerun only the affected scenarios.

• A core journey broken, or many failures on day one. Stop. Send the build back to QA and restart once the entry criteria are met again.

• A dispute over scope. Put the approver and the original brief on one call and decide whether each item is a defect or a change.

If the date has to move, move it and explain why. A delayed launch is easier to explain than a broken one.

Revolutionise your QA processes

Start free trial

Frequently asked questions

What is the difference between QA and UAT?

QA checks that the product works correctly against its specification, and the delivery team does it. UAT checks that the product meets the business need, and the client or end users do it. QA comes first.

How long should user acceptance testing take?

For most websites, allow between two days and two weeks of testing, plus time to fix and retest. The number of user journeys drives the length more than the number of pages does.

Can developers do UAT?

They can support it by answering questions and fixing issues. They should not be the testers or the people accepting the work, because the purpose of UAT is an independent check from the business.

Is UAT the same as beta testing?

Beta testing is one kind of UAT, where real users try a near-finished product. Most website UAT happens before that stage, with client staff on a private site.

What happens if UAT fails?

The product does not go live. Issues are fixed and the affected scenarios are retested, or in a serious case the build returns to QA and the round restarts. Sign-off comes only when the exit criteria are met.