User acceptance testing (UAT) is the stage where the people who will use a new system check that it supports their real work before it goes live. Developers test that the software works as built. UAT asks a different question: does the system do what the business needs, in the way staff and customers will use it? For a company buying custom software, it is often the main chance to confirm the delivery before handover or launch.
How UAT differs from other testing
A software project usually includes several rounds of testing. They overlap, but each has a different owner and purpose:
- Developer and QA testing checks that features work as specified and that the code behaves correctly. It is normally done by the delivery team.
- Regression testing checks that existing features still work after a change.
- User acceptance testing checks that the system fits the business process, using realistic tasks, data and user roles. It is done by, or with, the business users.
Passing developer testing does not guarantee acceptance. A form can work perfectly and still ask for information in an order that does not match how front-desk staff take a booking.
Who should take part
UAT works best when the testers are the people who will rely on the system, not only the project sponsor. Depending on the project, that might include:
- front-line staff who handle daily tasks such as bookings, orders or enquiries;
- supervisors or administrators who approve, edit or report on records;
- finance or operations staff who check amounts, exports and reconciliations;
- where suitable, a small group of customers or members testing public-facing journeys.
The delivery team usually prepares the test environment, explains how to report issues and fixes what is found. The business decides whether the result is acceptable.
What to prepare before UAT starts
- Acceptance criteria: agree in writing what "accepted" means for each feature or journey, ideally when the scope is set rather than at the end of the project.
- Test scenarios: short, realistic tasks such as "create a booking for a member, change the time, then cancel it", with the expected result for each step.
- A test environment: UAT is normally done on a staging or test version of the system, separate from live data, so testers can make mistakes safely.
- Test accounts and data: an account for each user role and sample data that resembles real records. Avoid using real personal or payment details unless this has been properly agreed.
- A way to log issues: a shared list or tracker recording the steps taken, the expected result, what happened and a screenshot.
- A timetable: testers have their normal jobs, so set aside time for UAT and for a second round to recheck fixes.
Illustrative example: A company replacing a spreadsheet-based booking process with a web app asks two front-desk staff and one manager to run UAT. The developers' tests all pass, but the staff find that the system cannot save a phone booking for a customer who has no email address. The issue is logged, both sides agree whether it is a defect or a change to scope, and the fix is rechecked before launch.
Sorting the issues you find
Not every UAT issue is a bug, so it helps to classify each one:
- Defects: the system does not do what was agreed.
- Change requests: the system works as agreed, but the business now wants something different. These may affect timeline or cost and should be agreed separately.
- Questions and training needs: the feature exists, but users did not know how to use it.
Agree a severity for each defect, such as whether it blocks launch or can wait for a later release, so sign-off is based on clear priorities, not the total number of issues.
Sign-off and after go-live
UAT usually ends with sign-off: a recorded decision that the system is acceptable for launch, sometimes with a list of known minor issues and a plan to fix them. Check what sign-off means in your agreement, for example whether it starts a warranty period or a support arrangement.
UAT checks a system at one point in time. After launch, changes and updates can affect features that were accepted earlier, which is where regression testing and ongoing website monitoring help. Support terms after sign-off are often set out in a software support SLA. If you are building a first version to test an idea, read what an MVP is.
For a service-focused overview, see technine.io’s website and web app development service, which includes UAT and launch validation.
Frequently asked questions
Is UAT the client's job or the developer's?
Usually both. The developer prepares the test environment, supports testers and fixes defects. The business runs or takes part in the tests and makes the acceptance decision. Agree these roles before the project starts.
How long should UAT take?
It depends on the size of the system, the number of user roles and how much time testers can give. Plan at least one round of testing plus a round to recheck fixes, and agree the timetable early so staff are available.
Can UAT be automated?
The acceptance decision needs people, because it is a judgement about whether the system fits the business. Repeatable checks of agreed journeys can be automated, and those scripts can later be reused for regression testing; see technine.io’s automated UI and user journey testing.