What Is Acceptance Testing? 5 Types, One Gate

A build clears system testing clean. Every automated check is green. It still doesn't ship. Not because anything is broken, but because nobody who actually has to sign off on it has looked at it yet.

There are five acceptance gates, not one, and which gate applies depends on who has to sign off on this build. Each has its own owner, and every one draws the same honest line: the half a machine can run, and the half that's somebody's judgement call. That's the engineer, SDET, or release owner deciding whether today's build ships, not a QA lead planning a quarter's suite-allocation strategy, the question of whether an AI-generated suite is testing anything real, or picking edge-case inputs for one test case.

What Is Acceptance Testing? Five Gates, Not One

Most pages that define acceptance testing quietly mean one specific thing: a business stakeholder clicking through a staging build before sign-off. That's real, and it's one of five main forms, but treating it as the whole category hides the other four gates that ask a version of the same question in a different room. An engineering team runs its own internal acceptance pass before anyone outside sees the build (alpha). A product team runs one with real external users, in the open (beta). An operations team runs one that has nothing to do with features and everything to do with whether the system can survive being run in production (operational acceptance). A client or a legal department runs one against the literal terms of a contract (contract acceptance). All five are acceptance testing. Only one of them is UAT.

The Five Types of Acceptance Testing

The ISTQB Foundation Level syllabus names the main forms of acceptance testing as user acceptance testing, operational acceptance testing, contractual and regulatory acceptance testing, alpha testing, and beta testing. Here is the complete map: five rows, one gate each, who runs it, what it actually checks, and where it sits in the lifecycle.

Type	Who performs it	What it checks	When	Deep dive
User acceptance (UAT)	Business stakeholders, real users	Build matches business intent	Before release, after system testing	UAT guide
Alpha testing	Internal testers, staging build	Real flows work, no external exposure	Just before beta	Alpha guide
Beta testing	External users, limited cohort	Real usage in real conditions	After alpha, before general release	Beta guide
Operational acceptance (OAT)	Ops or SRE team	System can deploy, back up, recover	Alongside or before release	OAT guide
Contract acceptance	Client, legal, procurement	Delivery satisfies contractual terms	At contractual delivery milestones	Covered below

Four of these have their own deep dive, because each earns more depth than a table row can hold, including the two-audience distinction alpha and beta get treated as. The fifth, contract acceptance, doesn't have a companion article in this cluster. It's a legal and procurement activity as much as a testing one, so its full definition lives right here.

Contract acceptance testing (ISTQB calls this contractual and regulatory acceptance testing) is a formal check that the delivered software satisfies the contractual or regulatory terms of the agreement between a vendor and a client. It's usually run by or for the client, and it often ends with a legal or procurement signature rather than a test report. The checks themselves can look like any other acceptance pass: confirm each contracted feature exists, confirm each SLA is met. What makes it "contract" acceptance is what happens when it fails: a contractual dispute, not a bug ticket.

Five types run in sequence, from an internal team's own pass to the client's signature.

The Coverage Half and the Intent Half

Every one of the five types above is really two different activities wearing one name. There's a mechanical half: running a defined flow against a build and confirming it behaves the way the flow says it should. That half is repeatable, and it was only ever manual because writing and re-running those flows by hand used to be the expensive part. Then there's the intent half: a person looking at what came back and deciding whether it matches what the business, the user, or the contract actually meant. That decision was never a coverage problem. It's a judgement call, and no amount of generated flow execution changes who has to make it.

Type	Mechanical coverage half	Human-intent half that stays human
UAT	Running real workflows against the build	Does this match what the business meant
Alpha	Repeating real flows on the staging build	Does a tester's complaint signal a bug
Beta	Getting the build in front of users	Do real users get what they expected
OAT	Running backup, failover, alerting drills	Would ops trust this runbook in an incident
Contract	Confirming each contracted feature or SLA item	Does delivery satisfy what the agreement intended

Generated testing is built for the left column. An agent that reads the codebase can run the day's real workflows against a live build every time the code changes, which is exactly the coverage half of all five rows above. It cannot do the right column, because nothing about reading a codebase tells a machine what a stakeholder, a user, or a contract actually meant. A vendor claiming otherwise is selling something that doesn't exist yet.

The coverage half is mechanical and generatable. The intent half is a person's call, every time.

Where Acceptance Sits in the Gate Stack

Acceptance doesn't run alone. It's the gate right after system testing confirms the fully assembled product meets its requirements as a black box, and right before release. A smoke test decides whether a build is even alive enough to test further. System testing decides whether the assembled product behaves correctly. Acceptance decides whether the person who has to live with that correct behavior actually wants it. Three different gates, three different oracles, run in that order for a reason: there's no point asking a stakeholder to accept a build that hasn't cleared the checks that come before it. For how all of these terms relate beyond this one gate, the software testing terminology guide maps the wider vocabulary.

That ordering also settles what today actually requires of whoever is standing at the ship decision. Everything above this gate already ran; acceptance is the one still open, right now, for this build. That's a release-day problem, distinct from planning next quarter's coverage or arguing about what a generated suite proves, and the entry and exit criteria below decide exactly when this particular stage counts as cleared.

Four gates run before acceptance. It's the only one asking what a person wants.

How Autonoma Fits the Acceptance Gate

The mechanical half of acceptance testing, the flow-running part of UAT, alpha, and beta, used to mean a person clicking through the same scenarios by hand every release, or a hand-written suite that drifted out of date the moment the flow it covered changed shape. Either way, the scarce resource, a person's judgement, ended up spent re-running or re-writing checks instead of deciding whether the result meant the build was actually ready.

We built Autonoma's agents to read the codebase directly and generate end-to-end checks from the routes, components, and flows that already exist, then run those checks against a live preview environment instead of a saved snapshot of the DOM. On every pull request, the Diffs Agent re-reads what changed and updates the suite to match, so the coverage half of UAT, alpha, and beta regenerates itself instead of going stale between releases. None of that is a speed or coverage number. It's an architecture choice, reading the codebase and verifying against the running application, built specifically so the mechanical half of these gates stops being something a person maintains by hand.

Mapped back onto the five types: our agents cover the coverage half of UAT, alpha, and beta, the part where a defined flow gets run against a real build. They don't touch operational acceptance's ops tooling, they aren't a contract-testing framework for the legal half of contract acceptance, and they don't replace the real users a beta program needs. What they do is make sure the mechanical half of the gate is never the reason a stakeholder is looking at a stale result.

Acceptance Is the Validation Side of the Gate

Verification and validation name the two different questions every check in a release pipeline is really answering. Verification asks whether the build matches its own spec. Validation asks whether the build matches what the user actually needed, which nothing written down inside the codebase can answer for you. Acceptance testing lives entirely on the validation side of that line, and that placement is the whole reason it resists automation better than the other gates in the stack: the oracle was never inside the system to begin with.

Two examples on the verification side. All five acceptance types on the validation side.

The Honest Taxonomy: What Stays Human

Beta testing carries this furthest. There's no generated test that produces the beta signal, because the beta signal is a real person choosing to keep using something, or not, in conditions nobody scripted. That's not a gap generation closes later. It's the nature of the question beta asks, and beta should survive the move to generated testing completely intact.

Contract acceptance carries a different kind of human signature: a legal or procurement sign-off that the delivery satisfies an agreement's terms. That's not a test-execution problem at all. It's a document-and-relationship problem, and treating it like one more suite to automate misunderstands what it's actually for. If a team needs consumer-driven contract testing between services, that's a real and separate category, and Pact and its peers are built specifically for it.

Operational acceptance leans the other direction. Much of what an OAT checklist covers, backup and restore, failover, alerting thresholds, is genuinely mechanical, and it belongs to ops tooling and observability platforms built for exactly that job, not to a tool built to drive an application's UI end to end.

Load testing and accessibility testing sit outside acceptance testing's five types entirely, even where some pages lump them in under "non-functional acceptance." They're their own specialities with their own tools, answering questions about capacity and inclusivity that none of the five types above actually cover. Recommending one vendor for contracts, operations, capacity, inclusivity, and behavioural coverage all at once would be a taxonomy nobody should trust.

What's left, after all of that gets its honest home, is the mechanical half of UAT, alpha, and beta: running the real flows those types depend on, against a real build, every time the code changes. That's the part of acceptance testing that was always going to move first, and it's also the smallest part of what makes acceptance testing valuable in the first place.

Naming the Gate You're Actually Running

Acceptance testing earns its complexity honestly: five different types because five different people need their own version of "yes, ship it," and one honest boundary because four of those five types split cleanly into a mechanical half and a human half that never should have been the same job. Naming which gate applies to your build, and being precise about which half of it a machine can actually run, is most of the work. The rest is just running it.

A release owner who can say, in one sentence, which of the five gates a build still needs and which half of that gate is mechanical versus human has already done the hard part. The scheduling, who runs the OAT checklist, when the beta cohort gets access, what the contract sign-off requires, follows from that sentence instead of preceding it. Most of the friction teams describe as "our acceptance process is slow" turns out to be this sentence never getting said out loud, so the same stakeholder ends up re-litigating the definition of done on every release instead of just applying it.

If the coverage half is the part eating your team's time, Autonoma connects to your codebase and keeps that half current on every pull request, so the human half of acceptance testing, the actual judgement call, is the part your team's attention goes to instead.

Frequently Asked Questions