Acceptance testing

What is acceptance testing?

Acceptance testing is the validation step where business stakeholders confirm that a feature or product meets agreed requirements and delivers the intended value.
It focuses on outcomes from a user and business perspective, not on internal implementation details.
Acceptance testing is guided by agreed acceptance criteria and ends with a clear approve or reject decision.

Why acceptance testing matters?

• confirms the solution meets business goals and user needs
• reduces rework by catching misalignment before launch
• provides a formal record of approval for scope and payment
• increases confidence for release and handover

Who performs acceptance testing?

• product owner or client representatives verify business fit
• end users or subject matter experts validate real workflows
• qa or a facilitator supports planning, execution, and evidence
• developers and designers assist with clarifications and fixes

When does acceptance testing happen?

• after a feature passes system, integration, and regression tests
• at the end of a sprint for sprint level acceptance
• before a release or milestone for project level acceptance
• during user acceptance testing (UAT) windows planned in the schedule

Types of acceptance testing

• user acceptance testing (UAT), verifies real user workflows against business outcomes
• business acceptance testing (BAT), checks compliance with business rules and processes
• contractual or regulatory acceptance, ensures contract terms or standards are met
• alpha and beta acceptance, early use by internal staff or a limited external audience

What does acceptance testing cover?

• end to end user flows for key scenarios and roles
• data correctness, reporting outputs, and integrations at a business level
• non functional expectations that affect users, for example performance thresholds that matter to the business
• edge cases that were defined in acceptance criteria

How to plan acceptance testing?

1. Define scope and objectives

• which features or epics are in scope
• business outcomes that must be validated
• environments and data to be used

2. Set entry criteria

• feature is in staging with the correct build number
• acceptance criteria are complete and testable
• blockers from earlier testing are resolved
• test data and accounts are prepared

3. Prepare test scenarios

Write scenarios directly from acceptance criteria. Use clear, business language.

Example scenario format:

Scenario: Refund approved by manager

Given a completed order with a refund request
When a manager reviews and approves the request
Then the order status changes to Refunded
And the customer receives a confirmation email within 5 minutes
And the refund appears in the accounting export

4. Define exit criteria

• all must have scenarios pass, should have items have known decisions
• critical defects are fixed or accepted with documented waivers
• stakeholders provide written approval or rejection with reasons

5. Plan roles and schedule

• assign a facilitator to coordinate
• identify decision makers for sign off
• schedule time windows with buffer for fixes and retests

Running acceptance testing, step by step

1. kickoff with stakeholders to confirm scope, data, and timelines
2. execute scenarios and record results with evidence, for example screenshots, IDs, logs
3. log defects and map them to scenarios and acceptance criteria
4. retake tests after fixes, record new evidence and outcomes
5. collect sign off, approvals per feature or release, plus any documented exceptions

Examples of acceptance test scenarios

payments

• user completes checkout with credit card, receives order confirmation within 2 minutes, order appears in history and in admin
• failed payment shows a clear error, cart remains intact, user can retry or change method

access control

• basic user cannot access admin routes, receives a friendly message, event is logged for auditing

reporting

• monthly revenue report matches transactions for the selected period within 0.5 percent tolerance

Acceptance testing deliverables

• acceptance test plan, scope, schedule, roles
• set of scenarios mapped to acceptance criteria
• test evidence, for example screenshots, export samples, IDs
• defect list with priorities and decisions
• final approval record and any waivers

Best practices

• write scenarios in business language, not technical steps
• base every scenario on acceptance criteria agreed earlier
• prepare realistic data, include edge cases and negative paths
• keep evidence minimal but conclusive, one screenshot or ID per check is often enough
• time box sessions, review results daily, decide fast on fixes or deferrals
• avoid scope creep, any new requirement should become a change request

Common mistakes

1. starting without entry criteria leads to churn and retesting
2. using vague scenarios like “works as expected”
3. mixing system testing with acceptance and testing internal details
4. no evidence policy which causes disputes later
5. missing sign off which delays payments and releases

Acceptance testing vs other testing

Focus	Acceptance testing	System or regression testing
Goal	validate business outcomes	verify technical correctness
Owned by	product owner, client, users	qa and engineering
Basis	acceptance criteria and business rules	specifications and code changes
Level	end to end user flows	components, integrations, and full system
Result	approve or reject for release	pass or fail for quality gates

Handling failures and waivers

• if a must have scenario fails, fix and retest before approval
• if a should have issue remains, document a waiver, include impact, workaround, and planned fix date
• update the scope of work and acceptance criteria if the requirement changed

Example acceptance sign off template

Release: v2.4.1
Environment: Staging
Date: 2025-10-31

Scopes tested:
• Checkout v2
• Admin refunds
• Revenue report export

Result:
• Must have scenarios: 18/18 passed
• Should have scenarios: 6/7 passed

Waiver:
#WR-17 Revenue export includes extra columns
Impact: cosmetic in Excel, no data loss
Workaround: ignore columns L–N
Planned fix: v2.4.2, within 7 days

Approved by:
Product owner: _____________
Client representative: _____________

FAQ

What is acceptance testing in software projects?
It is the final validation step where stakeholders verify that the product meets agreed requirements and is ready for release.

Who is responsible for acceptance testing?
The product owner or client leads it, with end users or subject matter experts executing scenarios. QA facilitates and gathers evidence.

When should acceptance testing happen?
After technical testing passes and before release. It can also happen at the end of each sprint for incremental acceptance.

How is acceptance testing different from QA testing?
QA verifies technical correctness, acceptance verifies business outcomes and user value.

What do you need to approve a release?
Passed must have scenarios, documented waivers for any remaining issues, and written sign off from the decision makers.