Once a build has passed every automated check, there is still one question left: will real people accept it? That question is answered by three overlapping practices — alpha testing, beta testing, and User Acceptance Testing (UAT). They look superficially similar (humans using a near-final product) but they happen at different times, with different audiences, and answer different questions.
A typical pre-release timeline
Step 1 of 4
Alpha testing
Internal testing by the QA team in a controlled environment. Bugs are expected and frequent.
A common release path looks like this:
Internal alpha. The build is given to employees — sometimes only the team, sometimes a broader internal audience. Alpha builds are still rough; bugs are expected; the goal is to find issues fast in a forgiving environment. Crashes, missing features, and visual glitches are normal.
External beta. A larger group of real users — opted in, often via a public sign-up — gets a near-final build. Beta testing is the first contact with real-world conditions: every browser, every operating system, every flaky network, every weird use case. The team collects bugs, performance data, and qualitative feedback.
UAT. A defined set of acceptance criteria are exercised by representatives of the customer. UAT is formal: there is a sign-off, a scope, and a defined set of test cases tied to business requirements. Common in B2B software, regulated industries, and enterprise contracts.
General availability (GA). The release ships to everyone.
What each phase is good for
Alpha finds the bugs nobody planned for. Internal users have a tolerance for breakage and the technical literacy to file useful reports. Alpha is also where the team validates that the feature is even directionally right — does it solve the problem we thought it would?
Beta finds the bugs that only appear at scale or in messy real-world conditions. A new region with a different mobile network, a screen reader the team has never tested with, a payment method nobody on the team uses. The diversity of beta users uncovers diversity of bugs.
UAT is not really a bug-finding exercise — it is a contract. UAT exists so the customer can say, in writing: "Yes, this matches what we agreed to buy." Functional defects discovered during UAT are upsetting because they should have been caught earlier; the goal of UAT is to confirm scope, not find escapees.
Common confusions
"UAT and beta are the same thing." They are not. Beta is open(ish), exploratory, and informal. UAT is closed, contractual, and formal. A consumer app might never run UAT; a banking platform never ships without it.
"Alpha and beta are just beta with different names." Alpha is internal and rough; beta is external and near-final. Releasing your alpha build to external users is a way to lose users in a hurry.
"We don't need any of this — we ship continuously." Continuous deployment teams still do alpha-style internal exposure (feature flags for staff), beta-style limited rollout (canary releases to 1%, then 10%), and acceptance equivalents (sign-off on the spec, monitoring on the deploy). The names changed; the activities did not.
What QA owns in each phase
In alpha, QA usually owns triage. Internal users file lots of reports of varying quality; QA filters them, dedupes them, prioritises them, and feeds the actionable ones back into engineering.
In beta, QA owns the feedback loop. They monitor the bug tracker, the support inbox, and any in-app feedback channel. They look for patterns — three reports of the same issue may signal a deeper problem than ten unrelated reports. They also monitor passive signals: error rates, crash reports, performance metrics on real user devices.
In UAT, QA owns preparation. They write the acceptance test cases, prepare the test environment with realistic data, walk the customer's UAT team through the scenarios, and capture sign-off. They are not usually the ones running UAT — the customer is — but they make UAT possible.
What you should walk away with
Alpha, beta, and UAT are three different conversations with three different audiences. Alpha is the team talking to itself; beta is the team talking to the world; UAT is the team talking to a contract. A serious release uses all three.
Next chapter dives into the most underrated skill in QA: how to design test cases. You will learn the formal techniques that turn "I have a feature, I should test it" into a structured, defensible plan.