Software Testing: What is User Acceptance Testing
The video above is a short introduction to user acceptance testing, where I focus on one idea that matters more than any checklist: UAT is where the business users decide whether the system works the way they actually expect. Below is the written version, expanded into a fuller guide.
Watch the full video on YouTube: Software Testing, What is User Acceptance Testing.
User acceptance testing is the last gate before software reaches production, and it is run by the people the software is built for. In the video I keep it short and make one distinction the rest of this guide builds on. The QA team asks whether the system works correctly. The business users ask whether it works the way their actual job needs it to. Those are not the same question, and the gap between them is exactly where UAT lives. This guide expands the short version into how to run that phase without it becoming the bottleneck that delays your release.
Passing QA proves the software is built right. UAT proves it is the right software.
What User Acceptance Testing Actually Is
User acceptance testing is the process where business users confirm the system operates the way they expect before it is released into production.
QA and UAT look at the same application through different eyes. QA is interested in functionality: does it work, does this button do the right thing, are the systems behaving correctly. The business users are interested in something the QA team cannot fully judge from the outside, which is whether the software fits the real business process and workflow they live in every day. A feature can pass every QA check and still be wrong, because it solves the problem the team thought the users had instead of the one they actually have. UAT is the step that catches that before customers do.
Why the Business Users See What QA Cannot
Business users catch process and workflow problems because they are the only ones who know how the work is really done.
This is the heart of what I say in the video. A tester can confirm that a screen saves a record. Only the person who processes forty of those records a day knows that the new screen made their workflow slower, skipped a step they depend on, or broke an assumption no requirement ever wrote down. That knowledge does not live in the test cases. It lives in the people, which is why their involvement is not a formality. In my testing, the problems business users caught were never the ones already sitting in the QA suite. When you skip real UAT, you ship software that works in theory and fails the first time it meets the actual job.
Their Tests Look Different, On Purpose
Business users write fewer test cases than QA, and they aim them at their own area of expertise rather than at full coverage.
Do not expect UAT to look like a QA test pass, and do not measure it that way. The test cases the business users develop are usually fewer in number, and they are deliberately focused on their particular area of expertise. That is a strength, not a shortfall. QA chases broad, systematic coverage. UAT chases depth in the few workflows that actually carry the business. On releases I have run, I found that a short list of scenarios written by someone who does the job for a living surfaced problems a thousand generic cases never would. Let them test what they know, and do not pad it to make it look like QA.
Run It in Parallel When Speed Matters
Users should start testing as soon as QA is finished, or in parallel with QA, depending on how much speed to market matters.
The textbook order is QA first, then UAT. Reality is more flexible. When speed to market is the priority, business users can begin testing in parallel with QA rather than waiting for a clean handoff, as long as everyone understands they are testing a moving target. The thing to plan around is availability. There are usually far fewer business users free to test than there are QA testers, and they still have their day jobs, so their time is constrained. That constraint, not the test design, is what most often turns UAT into the bottleneck. Schedule their hours early, give them the few scenarios that matter most, and protect that time like part of the release plan, because it is.
Final Thought
User acceptance testing is the critical element of the software development life cycle where the people who will live with the software get the final word. Keep the distinction clear: QA proves it works, UAT proves it works for them. Bring the business users in early, let them test the workflows they own, run it in parallel when the schedule demands it, and respect that their time is the scarce resource. Do that and production stops being the place where the real problems are discovered.
The full video is the short introduction. Watch it above, and tell me in the comments: what is the most surprising thing a business user ever caught in your UAT?
