Acceptance test
An acceptance test verifies whether a system meets its acceptance criteria and satisfies business requirements from the user's perspective. Unlike unit tests that verify code works correctly or integration tests that verify components work together, acceptance tests verify that the software does what users and stakeholders actually need. They're the final validation before work is considered complete.
Why it matters
Code can pass all technical tests while still failing to meet business needs. A function might work perfectly according to its specification while solving the wrong problem. Acceptance tests bridge this gap by validating outcomes that matter to users, not just technical correctness.
Acceptance tests also protect against regression. When future changes are made, acceptance tests verify that previously working features still meet their requirements. This safety net enables confident refactoring and evolution.
Perhaps most importantly, acceptance tests force clarity about requirements. You can't write a test for vague criteria. The act of writing acceptance tests often reveals ambiguity that would otherwise surface as bugs or disappointed stakeholders.
Types of acceptance tests
User acceptance tests (UAT) are performed by actual users or stakeholders to verify the system meets their needs. These often involve manual exploration rather than scripted tests.
Business acceptance tests verify that business rules and processes work correctly. These might be automated or manual depending on complexity.
Contract acceptance tests verify that the system meets contractual or regulatory requirements. These are often formally documented and auditable.
Operational acceptance tests verify that the system works in its production environment-performance, security, backup and recovery, monitoring.
Writing acceptance tests
Good acceptance tests share characteristics with good acceptance criteria-they're specific, verifiable, and written in business language.
Start from the acceptance criteria. Each criterion should have at least one test that verifies it. Multiple tests may be needed for complex criteria or edge cases.
Write tests at the appropriate level. Acceptance tests verify behavior from the user's perspective. They interact with the system the way users do-through the UI, API, or whatever interface users see.
Include both positive and negative cases. Test that the system does what it should and doesn't do what it shouldn't. Error handling and edge cases matter.
Keep tests independent. Each test should set up its own state and clean up after itself. Tests that depend on other tests are fragile and hard to maintain.
Manual vs. automated
Some acceptance tests lend themselves to automation-particularly those that verify specific behaviors that don't change frequently. Automated acceptance tests provide regression protection and can run frequently.
Other acceptance tests are better performed manually. Exploratory testing, usability evaluation, and assessments requiring human judgment don't automate well.
The appropriate mix depends on the product and team. High-change areas benefit from automation. Subjective assessments require human evaluation. Most products need both.
Acceptance test-driven development
Some teams write acceptance tests before implementation, using them to drive development. This approach, called Acceptance Test-Driven Development (ATDD) or Behavior-Driven Development (BDD), has several benefits:
Tests serve as executable specifications. They document expected behavior in a verifiable form.
Tests guide implementation. Developers know exactly what they're building toward.
Tests catch misunderstandings early. If the test is wrong, you discover it before writing code, not after.
The practice requires discipline and appropriate tooling but can significantly improve alignment between requirements and implementation.
Running acceptance tests
Acceptance tests typically run in an environment that resembles production-same configuration, similar data, equivalent infrastructure. Testing in development environments may miss issues that only appear in production-like conditions.
Run acceptance tests at appropriate points in the workflow. Common triggers include:
Failing acceptance tests should block release. If a test fails, either the code needs to be fixed or the test needs to be updated to reflect changed requirements. Don't ignore failures.
Common challenges
Flaky tests that sometimes pass and sometimes fail undermine confidence in the test suite. Teams start ignoring failures, which defeats the purpose. Invest in test reliability.
Slow tests that take hours to run don't get run frequently. Acceptance tests tend to be slower than unit tests, but excessive slowness indicates a problem. Optimize or parallelize as needed.
Test maintenance becomes a burden as the system evolves. Tests that break with every change consume more effort than they save. Write tests at appropriate abstraction levels to reduce brittleness.
Unclear ownership leaves tests unmaintained. Someone should be responsible for the acceptance test suite-keeping it current, investigating failures, and improving coverage.
Acceptance tests and product quality
Acceptance tests don't guarantee quality-a passing test suite doesn't mean users will be satisfied. Tests verify what you thought to test for. Unexpected issues, usability problems, and unspecified requirements can still cause problems.
Think of acceptance tests as a safety net, not a guarantee. They catch known issues but don't discover unknown ones. Complement them with other quality practices: code review, exploratory testing, user research, and production monitoring.
Klero helps teams identify what should be acceptance tested by revealing what matters to customers. When you can see the requirements and expectations users express, acceptance criteria and tests better reflect actual needs.
