Acceptance testing
System testing checks a system against its documented technical requirements, done by the team that built it. Acceptance testing goes one step further, checking the same system against what the actual customer or end user needs, which doesn't always perfectly match what the original spec said. A requirement can be technically met and still miss what the person who asked for it actually wanted.
A few forms of this show up regularly. User acceptance testing, often shortened to UAT, has actual end users or their representatives try the system against real-world scenarios. Business or operational acceptance testing confirms the system is actually ready to run day to day, with backups, monitoring, or support processes in place. Contractual or regulatory acceptance testing confirms specific, often legally binding criteria are met before a formal handoff or go-live.
This work typically runs against predefined acceptance criteria, agreed in advance, often as part of requirements or a contract, so there's a clear, shared definition of what counts as accepted rather than a subjective judgment call made after the fact. Failing acceptance testing is often a bigger deal than failing an earlier stage, since it can mean a contractual delay, a missed go-live date, or a formal rejection of the delivered system.
Common forms
- User acceptance testing, where actual end users or their representatives try the system against real-world scenarios.
- Business or operational acceptance testing, confirming the system is actually ready to run day to day, backups, monitoring, support processes in place.
- Contractual or regulatory acceptance testing, confirming specific, often legally binding criteria are met before a formal handoff.
- Alpha and beta acceptance testing, where a limited group of real users tries the system before a wider release.
Where it shows up
- A client trying out a custom-built system against the scenarios described in the original contract before formally accepting delivery.
- End users piloting a new internal tool before it replaces the system they currently rely on.
- Confirming operational readiness, support processes, monitoring, backups, before a system goes live, not just that its features work.
- A beta group using a near-final release in real conditions before it ships broadly.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| Catches a mismatch between what was technically specified and what the actual user or customer needed, before release. | Can surface a disagreement late, if the original requirements were themselves unclear, acceptance testing is where that gap finally becomes visible. |
| Gives a clear, agreed-on definition of done through predefined acceptance criteria, rather than a subjective judgment call. | Scheduling real end users or clients to actually participate can be harder than running an internal test pass. |
| Confirms operational readiness, not just functional correctness, catching a gap like a missing support process before go-live. | Failing acceptance testing this late is more costly than failing an earlier stage, often meaning a missed deadline or formal rejection. |
Frequently asked questions
What's the difference between acceptance testing and system testing?
System testing is done by the team that built the software, checking it against its documented technical requirements. Acceptance testing comes right after, done by or on behalf of the actual customer or end user, checking the same system against what they actually need, which isn't always identical to the original spec.
What is user acceptance testing (UAT)?
UAT is the most common form of acceptance testing, where actual end users or their representatives try the system against real-world scenarios before it's considered ready, rather than relying only on the development team's own testing to judge readiness.
What happens if a system fails acceptance testing?
It depends on the relationship and the contract, but typically the system goes back for rework on whatever didn't meet the agreed criteria, rather than shipping as is. Because this is the last stage before release, failing here is usually more costly, in time and sometimes contractually, than failing an earlier testing stage.
How Klarent helps
Klarent's AI agents generate tests directly from a plain-language description of a real user flow, which keeps the automated coverage running earlier in development closely aligned with the same scenarios acceptance testing eventually checks against.