User Acceptance Testing (UAT)

Prev Next

Every testing activity covered so far in this track — functional testing, regression, exploratory testing — has one thing in common: it's performed by QA, people whose job is to find defects. User Acceptance Testing (UAT) is different on a fundamental level. It's the final phase of testing, done by real end users or the client, to answer one specific question: "does this software actually do what we, the business/users, needed it to do?" — not "does it match the written requirements" (QA already checked that), but "does it work for us, in practice."

Working definition: UAT is formal testing performed by intended end users (or their representatives) to determine whether a system satisfies its acceptance criteria and is acceptable for delivery, typically as the very last step before release.

How UAT Differs From Everything Earlier in This Track

Aspect	Earlier QA Testing (functional, regression, etc.)	UAT
Who performs it	QA / testers who know the app's internals and the written test cases	Real end users, or client/business representatives, with no special knowledge of test cases
What it checks	Does the software match the requirements/spec?	Does the software actually meet the real-world need, the way a real user experiences it?
When it happens	Throughout development, before release	Right before release — the last gate
Bugs found	Functional defects, edge cases, regressions	Usability friction, missing "obvious" expectations, real-world workflow mismatches QA didn't think to test because they know the app too well
Outcome	Bug reports, pass/fail per test case	A sign-off (accept) or a rejection with reasons

Note: A QA tester can become "blind" to a confusing screen simply because they've stared at it for weeks and know exactly how to use it. A real, first-time user has no such blind spot — which is exactly why UAT exists as a separate step rather than "more QA testing."

Alpha Testing vs Beta Testing

UAT is often carried out in two stages, especially for consumer products like RecipeBox:

	Alpha Testing	Beta Testing
Who	Internal staff not on the dev/QA team (e.g. support, sales, other departments), or a small trusted client group	A wider group of real external end users, sometimes public
Where	At the company's own site/environment, often still somewhat controlled	In the users' own real environment (their own phone, their own network, their own daily routine)
Goal	Catch obvious issues before wider exposure; a "dress rehearsal"	Validate real-world usability and catch issues only real, uncontrolled usage surfaces
RecipeBox example	Internal marketing team tries the new Search feature for two days at the office and reports friction points	50 users from the public beta list use RecipeBox at home for a week, cooking real meals with it

Worked Example: RecipeBox v2.0 UAT

Continuing the RecipeBox v2.0 release from the previous lesson's test plan: QA has finished functional and regression testing, and all Critical/High bugs are fixed. Before public launch, the team runs a UAT round.

Who participates: 5 real home cooks recruited from the existing RecipeBox waitlist — not developers, not testers, just people who cook regularly and want to try the app. None of them have seen a test case or a requirements document.

What they're asked to do: Use RecipeBox naturally for one week — add their own real recipes (not sample data), search for recipes they've saved, edit a recipe after realizing they made a mistake — and report anything confusing, broken, or missing, in their own words.

What comes back (a real mix of UAT feedback):

"I couldn't tell if my recipe actually saved — there's no confirmation message." (usability gap QA didn't flag as a "bug" because the save technically worked)
"Search only matches the exact title — I typed 'pasta' and my recipe called 'Creamy Pasta Bake' didn't show up until I typed the full name." (a real functional gap in how users expect search to behave)
"Prep time in minutes is annoying for a 2-hour slow-cooker recipe — I had to type 120." (a workflow mismatch, not a defect against the spec)
"Everything else worked great, I use it every day now." (positive signal — accept as-is for that flow)

Why this couldn't have come from QA alone: Every one of these is something the app does exactly as specified — no test case would have "failed." UAT surfaces the gap between "meets the spec" and "meets the actual need," which is precisely its job.

What a UAT Sign-Off Looks Like

UAT ends with a formal decision, not just a list of comments. A typical sign-off document records:

Field	RecipeBox v2.0 example
Feature/release under test	RecipeBox v2.0 — Search & redesigned Add/Edit Recipe
UAT period	Aug 10 – Aug 17
Participants	5 external beta users
Issues found	3 usability items logged (see above); 0 blocking defects
Decision	Accepted for release, with the "search partial match" issue scheduled for a fast-follow patch rather than blocking launch
Signed off by	Product owner + 3 of 5 participants confirming satisfaction

Note: A sign-off doesn't require zero feedback — it requires a conscious decision about what gets fixed now vs later vs accepted permanently, made by people authorized to accept that risk (usually the product owner or client, not QA).

Next up: With UAT signed off, how do you actually prove, on paper, that every requirement got tested at all? That's the job of the Requirement Traceability Matrix, covered next.

Prev Next