UAT vs QA
QA testing is run by the delivery team against the specification and finds defects: places where the build departs from what was written. User acceptance testing (UAT) is run by the customer or business users against the job the software must do and finds mismatches: places where the specification departed from the work. They share a build, run in that order, and overlap only per feature once QA is done.
The longer version
The two differ in who tests, what they test against and what the outcome is. QA is run by testers, or by developers, inside the delivery team, working from the requirements, the acceptance criteria and the test cases derived from them; its output is a list of defects and a verdict on whether the build meets its specification. UAT is run by the people who will use or pay for the system, working from the business process the software is meant to support; its output is a sign-off, a rejection, or a list of conditions on acceptance.
The confusion comes from treating UAT as a final round of QA done by different people, and running it that way wastes it. Business users are poor at finding defects: they do not know the edge cases, they do not write steps to reproduce, and they stop when something is confusing rather than when it is broken. What they alone can judge is whether the software fits the job, whether the invoice matches how finance invoices, whether the approval flow matches who approves. A defect found in UAT is a QA escape; a mismatch found in UAT is UAT doing its job.
UAT that starts before QA has finished wastes both phases. Users open the build, hit a crash in the first ten minutes, and spend their allotted time filing bugs the test team would have found. UAT then ends with no acceptance decision because nobody got far enough to make one. The entry criterion for UAT is a build that has passed QA, on an environment that resembles production, with the known defects listed so the users do not rediscover them. In the standard vocabulary, QA answers the verification question and UAT answers the validation one.
Common questions
Is UAT part of QA?
Organisationally, no: UAT is owned by the business or the customer, and QA is owned by the delivery team. In a test plan the two appear as consecutive phases, and QA often organises the UAT environment, the test data and the logistics. The judgement itself belongs to the users, which is the whole point of the phase.
Can QA do UAT?
A tester can prepare UAT, coach the users and record the results, and cannot make the acceptance decision, because the decision is a statement by the customer that the delivery meets their need. A tester declaring that the software passes UAT is QA under a different label, and it leaves the team with no evidence the users agree.
What comes first, QA or UAT?
QA comes first. UAT starts when the build has passed the team's own testing, the known defects are listed and the environment holds realistic data. Starting UAT before that turns business users into an expensive and unreliable test team, and leaves the phase without the acceptance decision it exists to produce.
What does UAT find that QA does not?
Mismatches between the software and the job it is meant to do: an invoice layout that finance cannot file, an approval flow that routes to the wrong role, a report that omits the column the business reconciles on. Each of these passes QA, because the build does what the specification says. Only the people who do the work can see that the specification described the work wrongly.
Can UAT and QA run at the same time?
Overlap is workable when QA has finished on the scope UAT covers and continues on scope UAT has not reached yet. Running both on the same build at the same time is not, because users hit the defects QA is still finding, spend the window filing them, and end without an acceptance decision. The condition is per feature: QA done, known defects listed, then UAT.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.