What Is User Acceptance Testing (UAT)? A Practical Guide
Your development team has finished the build and QA has signed off. Now it is your turn: UAT is where you and your real users confirm the software actually solves the business problem before it goes live.
- User acceptance testing (UAT) is the last gate before go-live, where the real users and business owners - not just QA engineers - confirm the software does what they actually need in real-world scenarios.
- UAT answers "did we build the right thing", not "did we build it right". It catches requirement misunderstandings, workflow gaps and last-mile issues that only real users notice, while they are still cheap to fix.
- It is the client's responsibility, not the vendor's. Plan the time, agree acceptance criteria before the build starts, and settle how a bug differs from a change request up front.
- Run it in a production-like environment with realistic, non-sensitive data, using the people who actually do the work, and end with a clear, documented sign-off.
User acceptance testing (UAT) is the final stage of software testing, where the real users and business owners - not just QA engineers - confirm the software does what they actually need in real-world conditions before it goes live. It is the last gate before go-live, and it answers a different question from earlier testing: not "was the software built right", but "did we build the right thing".
UAT is the client's responsibility rather than the vendor's, because only the people who do the work can judge whether the software fits it. If you are a founder, product owner or business stakeholder rather than an engineer, this guide explains what UAT actually is, why it is your job, how to run it well enough to sign off with confidence, and how to tell a genuine bug from a new change request.
What UAT Is, In Plain Terms
User acceptance testing is the stage where real users or business representatives validate that the delivered software solves the business problem and fits the way people actually work. They run through the tasks they will do every day - raise an order, approve an invoice, onboard a customer - using realistic data, and they confirm each one works the way the business needs it to.
The key word is acceptance. UAT is not about whether a button turns the right shade of blue or whether an edge case throws an error deep in the code - a good QA and testing process has already handled that. It is about fitness for purpose: does this software let us do our jobs, in our process, without new friction. When UAT passes, the business is formally saying "yes, this is what we asked for, we accept it".
UAT does not ask whether the code works. It asks whether the working software is the right software for how your business actually operates.
Where UAT Sits And How It Differs From QA
UAT comes near the very end of the delivery process. Development builds the software. The QA team then runs functional, integration and system testing to confirm it works as specified and is free of defects. Only once that is stable does UAT begin, and it is typically the last gate before the software is released to production.
That position matters. By the time software reaches UAT it should already work. If your users are tripping over broken screens and crashes, the build was not ready for UAT and should go back to QA. UAT is your chance to confirm the working software is the right working software - the final sign-off before go-live, not a second round of bug-finding. It differs from earlier QA testing on a few axes that change everything about how you approach it, and the core distinction is who performs the testing and what they test against.
| Dimension | QA Testing | User Acceptance Testing |
|---|---|---|
| Who runs it | QA engineers and automated scripts | Real users, subject-matter experts and business owners |
| Tests against | Technical specification and tickets | Real business scenarios and workflows |
| Core question | Was the software built right | Did we build the right thing |
| Focus | Code correctness and defects | Fitness for purpose and workflow fit |
| Environment | Controlled test environments | Production-like, with realistic data |
| Ends with | An internal QA pass | A formal business acceptance and sign-off |
One useful way to hold the distinction is by who performs the testing and why. Our guide to manual versus automated testing covers the who-runs-it and how axis for QA in detail; UAT sits at the human, business-facing end of that spectrum. Automated scripts and QA engineers verify the software behaves correctly. Real users in UAT verify the correct behaviour is the behaviour the business needs.
Why UAT Matters And What Skipping It Costs
The failure UAT exists to catch is the one no amount of code testing will find: "it works, but it is not what we needed". A team can build exactly what the spec said and still miss the point, because the spec was based on someone's interpretation of a requirement, and interpretations drift. UAT is where that gap surfaces, while it is still cheap to close.
Skipping UAT, or rushing it, tends to let a predictable set of problems through to production: requirement misunderstandings that no one caught on paper, workflow gaps where the software forces users into an unnatural sequence, and last-mile issues that only appear when a real person tries a real task. Catching these before launch is far cheaper than after, when they arrive as support tickets, emergency fixes and lost user trust. UAT also does something softer but real: when the people who will use the software have tested it and signed it off, they own the result rather than having it dropped on them.
Types Of Acceptance Testing
"Acceptance testing" is a small family of related activities. You do not need all of them on every project, but it helps to know the vocabulary and choose the ones that fit your risk.
| Type | What It Confirms |
|---|---|
| Alpha testing | Acceptance done in-house, often with internal users, before real external users see it. |
| Beta testing | A limited set of real end users test in their own environment, to catch issues that only show up in the wild. |
| Business acceptance testing | The software meets the business goals and processes it was built to support. |
| Contract acceptance testing | The software meets the acceptance criteria written into the contract - the basis for formal sign-off and payment. |
| Operational acceptance testing | The software is ready to run in production - backups, security, support and recovery, rather than the features themselves. |
Who Is Involved And How To Run UAT Well
UAT is a business activity, so the cast is mostly business people. The core participants are the actual users and subject-matter experts who know the workflows, because they are the only ones who can judge fitness for purpose. The product owner or project sponsor owns the outcome and, ultimately, the sign-off. On larger efforts a UAT coordinator organises the scripts, schedules the testers and tracks the results. The vendor or development team supports UAT - they set up the environment, load data, fix issues and answer questions - but they do not own the sign-off. The vendor cannot accept the software on your behalf, which is exactly why UAT is your responsibility.
Good UAT is planned, not improvised at the end. A practical sequence looks like this:
- Define acceptance criteria up front - before the build starts, not after. Clear, testable statements of what "acceptable" means give both sides a shared definition of done.
- Write real-world test scenarios and scripts from your actual workflows, not from the technical spec. Each script should walk a real task end to end, in the order a real user would do it.
- Use a production-like environment with realistic but safe data. Avoid live customer records or anything sensitive; use representative, non-sensitive data that still exercises real conditions.
- Get the right users involved - the people who actually do the work, not whoever happens to be free. The wrong testers produce false confidence.
- Log and triage every issue, sorting each into a category: genuine defect, change request, or a training or documentation gap rather than a software problem at all.
- Retest fixes. When the team resolves an issue, the tester who raised it should confirm the fix in the same scenario before it is closed.
- Get formal sign-off. A clear, documented acceptance from the business owner is what turns "we think it is fine" into a clean, agreed go-live.
Involve the people who do the work daily, not whoever is free. The wrong testers produce false confidence that only breaks once real users arrive.
Planning A Build And Want UAT Done Right?
We help clients scope acceptance criteria early, run structured UAT with the right people, and reach a clean sign-off - so what goes live is genuinely fit for purpose.
Cost And Timeline Factors
UAT does not carry a fixed price or duration; it scales with the size of the system, the number of distinct workflows to validate, and how many real users you need to involve. The honest way to budget it is by the factors that drive effort, not a single headline figure. The variables below tend to move a UAT window from a few days to a few weeks.
The largest hidden cost is not the testing itself but people's time: real users have day jobs, and UAT competes with them. Protecting that time in the plan, rather than squeezing it into the last two days before launch, is what keeps the window realistic.
Common UAT Mistakes And How To Avoid Them
Most UAT trouble comes from a handful of avoidable mistakes rather than anything technical. Watch for these, and design them out before testing begins:
| Mistake | How To Avoid It |
|---|---|
| Starting UAT with no acceptance criteria | Agree measurable criteria before the build begins, so "done" is defined in advance rather than argued at the end. |
| Using the wrong testers | Involve the real users and subject-matter experts who do the work daily, not whoever is available. |
| Treating change requests as bugs | Triage each issue; a request for something new is not a defect and should follow the change process. |
| Rushing sign-off under deadline pressure | Protect the UAT window in the plan; a hurried sign-off just moves the problems into production. |
| Testing with fake or empty data | Use realistic, non-sensitive data so real-world issues surface instead of hiding behind clean test values. |
Bug Or Change Request? Agree This Before You Start
This is the distinction that causes more UAT friction than any other, so it is worth settling before testing begins. A bug is the software failing to do what was agreed - it does not meet the acceptance criteria, and fixing it is part of the delivery. A change request is asking for something that was never agreed - a new feature, a different workflow, an extra field. That is real, legitimate work, but it is new scope.
During UAT, users naturally surface both, and often in the same breath: "this is wrong" frequently means "this is not what I would now prefer". If everything gets logged as a bug, the vendor feels asked to build new scope for free; if everything gets pushed off as a change request, the client feels short-changed on what they paid for. The way to avoid the fight is to agree, in the contract or scope, how each is defined and handled before UAT starts. A clear scope and acceptance criteria are what let you sort issues calmly instead of negotiating each one. This is one reason a well-run custom software development engagement pins down scope and acceptance early.
Almost every painful UAT dispute traces back to one skipped step: agreeing, before any code is written, what counts as a bug versus a change request.
Conclusion
User acceptance testing is the last gate before go-live, and it is the one gate that is unmistakably yours. QA confirms the software was built right; UAT confirms it is the right software - that it solves the business problem and fits the way your people actually work. Get the acceptance criteria agreed before the build, involve the real users, test with realistic data, sort bugs from change requests calmly, and sign off deliberately. Do that, and you go live knowing the software is fit for purpose, not hoping it is. If you are planning a build and want UAT scoped in from the start, talk to us.
Frequently asked questions
What is user acceptance testing in simple terms?
User acceptance testing (UAT) is the final stage of testing where the actual users or business owners confirm that the software does what they need in real-world scenarios, before it goes live. Unlike earlier testing, it is not about finding code bugs - QA has already done that. It answers whether the delivered software is the right thing and fits how people actually work. When UAT passes, the business formally accepts the software.
How is UAT different from QA testing?
QA testing is performed by engineers and checks that the software works as specified and is free of defects - it confirms the software was built right. UAT is performed by real users and business representatives against real business scenarios, and it checks fitness for purpose - whether the software is the right thing for the job. QA is technical and correctness-focused; UAT is business-focused and usually runs in a production-like environment with realistic data.
Whose job is UAT, the client's or the developer's?
UAT is primarily the client's responsibility. The people who will actually use the software are the only ones who can judge whether it fits their workflow, and the sign-off belongs to the business owner or product owner. The vendor supports UAT by preparing the environment, loading data and fixing issues, but they cannot accept the software on your behalf. Plan for your team's time accordingly.
What is the difference between a bug and a change request in UAT?
A bug is the software failing to meet what was already agreed - it does not satisfy the acceptance criteria, so fixing it is part of the delivery. A change request asks for something that was never agreed, such as a new feature or a different workflow, which is legitimate but is new scope. Confusing the two is the most common source of UAT disputes, so agree how each is defined and handled in the contract before testing begins.
How long should UAT take?
There is no fixed duration - it depends on the size and complexity of the software and how many real workflows need to be validated. In most projects UAT runs from a few days for a small application to a few weeks for a larger system with many users and scenarios. The key is to protect enough time in the plan for real users to test properly, rather than rushing sign-off under a deadline.
What are acceptance criteria and when should they be agreed?
Acceptance criteria are clear, testable statements of what "acceptable" means for each feature or workflow - the shared definition of done. They should be agreed before the build starts, not after, so both the client and the vendor build toward the same target. Agreeing them up front is also what lets you sort genuine bugs from change requests calmly during UAT, because you have an objective reference for what was promised.
Should UAT use real or test data?
UAT should use realistic but safe data in a production-like environment, so the test reflects real conditions rather than a clean lab. Avoid live customer records or anything sensitive; instead use representative, non-sensitive data that still exercises real scenarios. Testing with fake or empty data is a common mistake, because it hides the very real-world issues UAT exists to surface.