What Is Acceptance Testing, and How to Do It?

Acceptance testing determines whether software meets the agreed user, business, contractual, operational, or regulatory requirements needed for approval.

It answers a different question from ordinary defect testing. A feature may work technically but still be unacceptable because it supports the wrong workflow, applies an incorrect business rule, omits an agreed requirement, or is not ready to operate in production.

This guide explains what acceptance testing covers, who is responsible, and how to plan and perform it step by step.

What Is Acceptance Testing?

Acceptance testing is a test level used to determine whether a system meets the agreed conditions for acceptance.

It evaluates the software from the perspective of the people or organisation receiving, using, operating, or governing it. Tests are based on user needs, business processes, requirements, acceptance criteria, contracts, regulations, and operational expectations.

For example, an e-commerce checkout may be technically functional: buttons respond, the payment API returns success, and an order record is created. Acceptance testing checks the complete outcome:

• Can the intended customer complete the agreed checkout journey?
• Are discounts, taxes, shipping, and totals calculated according to business rules?
• Does inventory change correctly?
• Are the required confirmation and fulfilment processes triggered?
• Can authorised staff find and manage the order?
• Does the workflow satisfy the criteria agreed for release?

The ISTQB glossary describes acceptance testing as formal testing against user needs, requirements, and business processes to determine whether a system satisfies its acceptance criteria.

What Are Acceptance Criteria?

Acceptance criteria are the conditions a product, feature, or other work item must satisfy to be accepted by its stakeholders.

They define what success means before testing begins. Strong criteria are:

• Specific
• Observable
• Testable
• Relevant to user or business value
• Clear about important rules and boundaries
• Agreed by the appropriate stakeholders

Weak and improved acceptance criteria

Acceptance criteria state the conditions to satisfy. Acceptance test cases provide the data, steps, and expected results used to verify those conditions.

Acceptance Testing vs. User Acceptance Testing

Acceptance testing is the broader test level. User acceptance testing is one of its forms.

Calling every acceptance activity “UAT” can hide important responsibilities. A business user may approve the workflow while an operations team separately confirms backup, monitoring, recovery, access, and deployment readiness.

Acceptance Testing vs. System Testing

System testing verifies the behaviour and quality of the complete integrated system. Acceptance testing evaluates whether that system is acceptable for its intended use or obligation.

System testing should normally provide enough stability before formal acceptance begins. Finding a large volume of basic functional defects during acceptance testing indicates that the product entered the stage too early.

Why Acceptance Testing Matters

Acceptance testing:

• Confirms that delivered software addresses the agreed need
• Finds misunderstandings between requirements and implementation
• Validates complete business processes rather than isolated controls
• Gives intended users direct evidence before operational use
• Supports contractual or regulatory proof
• Confirms that operations teams can support the system
• Makes unresolved risks visible to the acceptance authority
• Creates a defined basis for approval, rejection, or conditional acceptance

It does not guarantee that the software has no defects. Acceptance means the authorised stakeholders judge that the system satisfies the agreed criteria and that any remaining risk is understood and acceptable.

Types of Acceptance Testing

The current ISTQB Foundation Level syllabus identifies user, operational, contractual, regulatory, alpha, and beta acceptance testing as the main forms.

1. User acceptance testing

UAT checks whether intended users can use the system to meet their needs and complete real business processes.

Examples:

• A finance user creates, reviews, and closes a monthly report.
• A warehouse employee receives, picks, and dispatches an order.
• A customer changes a booking and receives the correct refund.

2. Operational acceptance testing

Operational acceptance testing determines whether operations or system-administration teams can run and support the system.

It may cover:

• Installation, deployment, upgrade, and rollback
• Monitoring and alerting
• Backup and restore
• Disaster recovery
• Access and user management
• Scheduled jobs
• Data migration
• Capacity and performance readiness
• Support procedures and documentation

3. Contractual acceptance testing

Contractual acceptance testing verifies the criteria defined in a contract, statement of work, or service agreement.

Criteria may cover:

• Required functions
• Integrations and deliverables
• Performance thresholds
• Supported environments
• Documentation and training
• Defect tolerances
• Milestones and completion conditions

Contract wording should define how acceptance is tested, who decides, the review period, how defects affect acceptance, and whether conditional acceptance is possible.

4. Regulatory acceptance testing

Regulatory acceptance testing produces evidence that the system satisfies applicable legal, regulatory, safety, or industry obligations within the agreed scope.

The appropriate compliance, legal, safety, or domain specialists should define or review the criteria. Passing internal QA does not by itself demonstrate regulatory compliance.

5. Alpha testing

Alpha testing gathers acceptance feedback in a controlled environment associated with the developing organisation. Potential users, customers, operators, or an independent test group may participate.

6. Beta testing

Beta testing gives selected external users access in their own environments before wider release. It can reveal differences in devices, workflows, configurations, networks, and expectations that internal environments do not reproduce.

Beta feedback is valuable but less controlled than formal scripted acceptance testing. Define eligibility, data handling, support, feedback channels, telemetry, exit criteria, and known limitations before the beta begins.

Who Performs Acceptance Testing?

The performer depends on what is being accepted.

QA professionals can help design scenarios, prepare data, manage environments, execute agreed checks, collect evidence, and report defects. Internal teams or external software testing services may support this work, but the final acceptance decision should remain with the stakeholder authorised to accept the product and its risks.

Developers should help diagnose and resolve findings but should not silently determine that their own delivery is acceptable when independent business, contractual, or regulatory approval is required.

When Is Acceptance Testing Performed?

Formal acceptance testing normally occurs after the relevant product scope has passed earlier testing and is stable enough for stakeholder evaluation.

It may happen:

• Before a production release
• Before client handover or contractual milestone approval
• At the end of a feature, sprint, or release increment
• Before operational ownership transfers to a support team
• Before a regulated system or change enters use
• During alpha or beta programmes
• After a major migration, replacement, or integration

Acceptance work should begin much earlier than execution. Stakeholders should define acceptance criteria during requirement analysis or story refinement so developers and testers share the same understanding of “done.”

Entry and Exit Criteria

Example entry criteria

Acceptance testing can begin when:

• Scope and acceptance criteria are approved
• Planned system testing is complete
• No unresolved defect blocks the critical acceptance journeys
• The acceptance environment is stable
• The correct build and configuration are deployed
• Test accounts, roles, data, and integrations are ready
• Known defects and workarounds are disclosed
• Participants understand the plan and responsibilities
• Evidence and defect-reporting tools are available

Example exit criteria

Acceptance testing can finish when:

• Required acceptance tests have been executed
• Every criterion has a recorded result
• Critical workflows pass
• Disallowed defect severities are resolved
• Permitted open defects have owners, workarounds, and accepted risk
• Required operational, contractual, or regulatory evidence is complete
• Regression testing of fixes is complete
• The authorised stakeholder records approval, conditional approval, or rejection

Avoid using “100% tests passed” as the only exit rule. Test cases may be incomplete, a blocked test may hide risk, and a low-severity defect count may not reflect business impact.

How to Perform Acceptance Testing Step by Step

Step 1: Identify the acceptance authority and scope

Define:

• What product, feature, release, migration, or deliverable is being accepted
• Who can approve or reject it
• Which acceptance types apply
• Which environments, users, data, integrations, and regions are included
• What is explicitly out of scope

This prevents a situation in which tests pass but no one has authority to approve the release.

Step 2: Review the test basis

Collect the source material that defines acceptable behaviour:

• User stories and acceptance criteria
• Business requirements and process models
• Contracts and service-level agreements
• Regulations and internal policies
• Designs and prototypes
• Operational runbooks
• Data and migration rules
• Known risks and previous incidents

Resolve contradictions before execution.

Step 3: Refine acceptance criteria

Work with business, product, QA, development, operations, and domain specialists. Use examples to expose hidden rules.

For a coupon, ask:

• Which customers qualify?
• Which products and locations qualify?
• Can coupons be combined?
• How are tax and shipping affected?
• What happens after a return?
• What happens if the coupon expires during checkout?

The criterion becomes more testable as these decisions are made.

Step 4: Build requirement traceability

Map every acceptance criterion to one or more tests. Also identify criteria with no test and tests with no acceptance basis.

Traceability supports coverage, review, and audits without requiring unnecessarily long test cases.

Step 5: Design real-world acceptance scenarios

Prioritise complete workflows that represent user or business value.

Include:

• Primary successful journeys
• High-impact alternative journeys
• Important validation and failure scenarios
• Relevant roles and permissions
• Business boundaries
• Integration outcomes
• Recovery from interruptions

Acceptance testing is not the stage for exhaustive technical combinations. Earlier test levels should provide that depth. Acceptance scenarios should demonstrate that the agreed outcomes work in realistic use.

Step 6: Prepare a production-like environment

Align the environment with the acceptance scope:

• Application build and feature flags
• User roles and permissions
• Database schema and representative data
• External-service sandboxes
• Email, SMS, payment, file, and reporting behaviour
• Browser, device, locale, and network conditions
• Monitoring and audit evidence

Document any difference from production and assess its impact on the acceptance result.

Step 7: Prepare safe, representative test data

Use realistic but synthetic or appropriately protected data. Include the roles, accounts, products, dates, statuses, limits, and edge conditions needed by the scenarios.

Each tester should know:

• Which data to use
• Whether data may be changed
• How to identify the resulting records
• How to reset or clean up
• Which data must never be entered

Step 8: Run a readiness check

Before bringing business users into a formal session, confirm:

• The build opens
• Accounts work
• Critical integrations respond
• Test data exists
• Known blockers are absent
• Evidence capture and defect reporting work

A short readiness test prevents stakeholder time being wasted on environment failures.

Step 9: Execute and collect evidence

For every test:

1. Confirm the starting conditions.
2. Follow the business scenario.
3. Compare the result with the acceptance criterion.
4. Record pass, fail, or blocked.
5. Capture the required evidence.
6. Create a defect or decision item for any deviation.

Do not coach users around unexpected behaviour merely to complete a test. Record the problem and its business impact.

Step 10: Triage findings

Classify findings as:

• Product defect
• Requirement or acceptance-criteria gap
• Environment or data problem
• Usability concern
• Training or documentation issue
• Enhancement request
• Accepted deviation

Not every piece of feedback is a release-blocking defect, but every material finding needs a decision and owner.

Step 11: Retest and run focused regression

After a fix:

• Repeat the failed acceptance test
• Verify the original business outcome
• Check nearby workflows affected by the change
• Update evidence and status

Step 12: Make and document the decision

The outcome may be:

• Accepted: Criteria are satisfied and remaining risk is acceptable.
• Conditionally accepted: Release is approved with documented conditions, owners, and deadlines.
• Rejected: Blocking criteria are unmet or risk is unacceptable.

Record who made the decision, when it was made, the tested build and scope, open findings, conditions, and supporting evidence.

How to Write Acceptance Test Cases

An acceptance test case should be understandable to a business stakeholder without requiring knowledge of implementation details.

Acceptance test case template

Keep steps focused on the business action. Excessive mouse-click detail makes cases hard to maintain and can distract from the result being accepted.

Acceptance Testing Example: Ecommerce Checkout

User story

As an eligible customer, I want to apply a valid coupon and complete payment so that I can place an order at the discounted total.

Acceptance criteria

1. An eligible customer can apply the coupon to qualifying items before its expiry.
2. The discount, tax, shipping, and final total follow the agreed calculation rules.
3. Successful payment creates one confirmed order and reduces available inventory as specified.
4. The customer receives the order number and required confirmation.
5. Declined payment does not create a confirmed order or permanently consume inventory.

Example acceptance tests

Given–When–Then example

Given an eligible customer has one qualifying in-stock product in the cart
And the SAVE10 coupon is valid
When the customer applies SAVE10 and completes payment successfully
Then the agreed discount is included in the final total
And exactly one confirmed order is created
And the customer receives the order number

The Agile Alliance describes Given–When–Then as a template for expressing context, an action, and observable consequences. It improves readability but does not remove the need for clear business rules and test data.

Acceptance Testing Checklist

Planning

• Acceptance authority is named.
• Scope and exclusions are agreed.
• Applicable acceptance types are identified.
• Acceptance criteria are specific and testable.
• Entry and exit criteria are approved.
• Defect and conditional-acceptance rules are defined.
• Responsibilities and schedule are clear.

Coverage

• Every acceptance criterion maps to a test.
• Critical business journeys are included.
• Relevant roles and permissions are covered.
• Important failures and alternatives are included.
• Contractual, regulatory, or operational criteria are covered where applicable.

Readiness

• Correct build and configuration are deployed.
• Environment is stable and representative.
• Test accounts, roles, and data are ready.
• Required integrations work.
• Known issues are disclosed.
• Evidence and defect tools are accessible.

Execution and closure

• Starting conditions are confirmed.
• Results and evidence are recorded.
• Failed and blocked tests have owners.
• Fixes are retested.
• Relevant regression checks are complete.
• Open risks and deviations are documented.
• Acceptance decision is signed by the authorised stakeholder.

Manual vs. Automated Acceptance Testing

Acceptance testing may be manual, automated, or both.

Manual acceptance testing is useful for:

• First-time business workflows
• User judgement and usability
• Exploratory feedback
• Contract reviews requiring human evidence
• New or rapidly changing requirements
• Operational drills and recovery exercises

Automated acceptance testing is useful for:

• Stable, repeatable acceptance criteria
• High-value workflows run every release
• Data-driven business-rule examples
• Regression checks
• API and service outcomes
• Executable specifications in ATDD or BDD

Automation can show that an agreed example still passes. It cannot decide whether the underlying business need has changed or whether stakeholders accept a newly discovered risk.

Acceptance Test-Driven Development

Acceptance test-driven development (ATDD) is a collaborative, test-first approach in which business, development, and testing participants agree on acceptance examples before implementation.

A practical ATDD conversation asks:

1. What outcome does the user or business need?
2. Which examples illustrate success?
3. Which boundaries or failures could change the result?
4. How will the team observe the result?
5. Which examples should become automated regression tests?

ATDD moves acceptance thinking earlier. Formal acceptance may still be required later, but fewer surprises should remain because the team shared concrete examples before building.

Common Acceptance Testing Mistakes

Starting without an acceptance authority

Tests can finish without a valid decision. Name the person or body authorised to accept the scope.

Writing criteria after development

Late criteria turn acceptance into negotiation after the work is built. Define and refine them before implementation whenever possible.

Treating UAT as final QA

Business users should not be expected to find ordinary functional defects that system testing should already have caught.

Testing screens instead of workflows

Acceptance is normally about completing a meaningful process, not proving that individual buttons respond.

Using unrealistic data or permissions

A workflow may pass for an administrator and fail for the real user role. Prepare representative accounts, records, limits, and statuses.

Ignoring failure and recovery

Important acceptance outcomes include what happens after decline, timeout, interruption, duplicate submission, or unavailable integration.

Allowing developers to reinterpret failed criteria during execution

If a criterion is ambiguous, record a decision with the authorised stakeholder. Do not silently change the expected result to match the implementation.

Using pass percentage as the decision

A 98% pass rate can still conceal a failed payment, unsafe migration, or unavailable recovery procedure. Evaluate business impact and explicit exit rules.

Failing to document conditional acceptance

Every condition needs an owner, due date, risk statement, and verification plan.

Best Practices

• Define acceptance criteria through collaborative examples.
• Keep tests traceable to an acceptance basis.
• Separate acceptance authority from test support.
• Enter formal acceptance only with a stable build.
• Use representative users, data, permissions, and integrations.
• Prioritise business-critical workflows.
• Include important negative and recovery scenarios.
• Capture evidence appropriate to the decision.
• Triage requirement gaps separately from defects.
• Retest fixes and affected workflows.
• Document deviations and residual risk.
• Record approval against a specific build and scope.

Conclusion

Acceptance testing determines whether software is suitable for approval against agreed user, business, operational, contractual, or regulatory needs.

The most effective process starts before execution. Define testable acceptance criteria, name the acceptance authority, prepare realistic scenarios and data, and agree on entry, exit, and defect rules. During testing, collect evidence and record deviations rather than relying on informal feedback.

The final deliverable is not merely a test report. It is a clear, authorised decision to accept, conditionally accept, or reject a defined software scope.

Frequently Asked Questions

What is acceptance testing?

Acceptance testing determines whether software satisfies the agreed user, business, operational, contractual, or regulatory conditions required for approval. It evaluates complete outcomes and provides evidence for an authorised acceptance decision.

Who performs acceptance testing?

Depending on its purpose, acceptance testing may involve intended users, product owners, clients, business specialists, operations teams, compliance representatives, independent testers, or QA professionals supporting an authorised stakeholder.

Is acceptance testing the same as UAT?

No. User acceptance testing is one form of acceptance testing. The wider category also includes operational, contractual, regulatory, alpha, and beta testing, each addressing a different acceptance perspective.

When should acceptance testing begin?

Acceptance criteria should be defined during requirements or story refinement. Formal execution normally begins after relevant system testing is complete and the build, environment, data, integrations, and participants are ready.

What is an acceptance test case?

An acceptance test case is a scenario used to verify a specific acceptance criterion. It records the business context, role, preconditions, data, actions, expected outcome, actual result, status, and evidence.

What happens when acceptance testing fails?

The team records the deviation, assesses impact, fixes and retests where appropriate, and updates the decision. The authorised stakeholder may reject the release or grant documented conditional acceptance.

Can acceptance testing be automated?

Yes. Stable acceptance examples can become automated regression tests, particularly at API or workflow level. Human participation remains important for business judgement, usability, operational drills, changing needs, and formal approval.