Acceptance Testing

What it is

Acceptance testing checks whether a system satisfies the business requirements and is fit to release. Where other tests ask “does it work?”, acceptance tests ask “does it do what the customer actually needs, and would they accept it?”. The best-known form is User Acceptance Testing (UAT), performed by or on behalf of end users.

1
  requirements ──► acceptance criteria ──► acceptance tests ──► accept / reject
2
                        │                        │
3
                        └ written by the business └ run against a release candidate

Acceptance testing comes in several flavours: UAT (users sign off), business acceptance (business rules), contract/regulatory acceptance (compliance) and operational acceptance (runbooks, backups, monitoring). It is usually the last gate before release and is driven by criteria agreed up front, not by code.

Robot Framework is a natural fit here: its keyword-driven, plain-language syntax lets business stakeholders read and even author the acceptance criteria using keywords like Given/When/Then, while testers extend them with deeper checks.

When to use it / when to avoid it

Use it for

Sign-off before a release, milestone or contractual delivery
Validating that delivered behaviour matches the agreed acceptance criteria
Business-rule and regulatory/compliance verification
Confirming operational readiness (monitoring, rollback, backups)

Avoid it when

You want fast feedback during development → push checks down to unit and integration tests
There are no written acceptance criteria yet — write those first, with the business
You are trying to use UAT to find basic defects; those should never reach the user stage

Frameworks & tools

Tool	Ecosystem	Notes
Robot Framework	Python	Keyword-driven acceptance; readable by non-programmers, rich library ecosystem
Cucumber	Multi	Gherkin `Given/When/Then`; BDD-style acceptance
SpecFlow / Reqnroll	.NET	Gherkin on .NET
Behave	Python	Gherkin + Python step definitions
FitNesse	Java/JVM	Wiki-based acceptance tables
Gauge	Multi	Markdown specs, plugin-based
Playwright / Cypress	Multi	Automate the UAT journeys once criteria are stable
TestRail / Xray / Zephyr	Multi	Track manual UAT sessions and sign-off
Robot Framework Browser	Python	Modern Playwright-backed library for RF

Quick setup

1
pip install robotframework
2
pip install robotframework-browser   # optional: real browser
3
rfbrowser init
4
robot --outputdir results tests/

1
*** Settings ***
2
Documentation    Acceptance tests for the checkout flow

1
npm install -D @cucumber/cucumber
2
npx cucumber-js

1
pip install behave
2
behave features/

1
go install github.com/cucumber/godog/cmd/godog@latest
2
godog run

1
<!-- Maven: Cucumber JVM -->
2
<dependency>
3
  <groupId>io.cucumber</groupId>
4
  <artifactId>cucumber-java</artifactId>
5
  <version>7.20.0</version>
6
  <scope>test</scope>
7
</dependency>

1
dotnet add package Reqnroll
2
dotnet test

Example

1
*** Settings ***
2
Documentation     Acceptance: a registered user can complete checkout
3
Library           Browser
4

5
*** Variables ***
6
${BASE_URL}       https://staging.example.com
7

8
*** Test Cases ***
9
Registered User Completes Checkout
10
    [Documentation]    AC-14: a signed-in user pays and sees confirmation
11
    New Browser       chromium    headless=true
12
    New Page          ${BASE_URL}/login
13
    Fill Text         id=email        ada@example.com
14
    Fill Text         id=password     s3cret
15
    Click             text=Sign in
16
    Click             text=Add to cart
17
    Click             text=Checkout
18
    Click             text=Pay now
19
    Wait For Elements State    text=Order confirmed    visible
20
    [Teardown]        Close Browser

1
// Feature: Checkout
2
//   Scenario: Registered user completes checkout
3
//     Given a signed-in user
4
//     When they pay for their cart
5
//     Then they see an order confirmation
6

7
import { Given, When, Then } from '@cucumber/cucumber';
8

9
Given('a signed-in user', async function () {
10
  await this.signIn('ada@example.com', 's3cret');
11
});
12
When('they pay for their cart', async function () {
13
  await this.pay();
14
});
15
Then('they see an order confirmation', async function () {
16
  await this.expectText('Order confirmed');
17
});

1
from behave import given, when, then
2

3
@given("a signed-in user")
4
def step_sign_in(context):
5
    context.page.sign_in("ada@example.com", "s3cret")
6

7
@when("they pay for their cart")
8
def step_pay(context):
9
    context.page.pay()
10

11
@then("they see an order confirmation")
12
def step_confirm(context):
13
    assert context.page.text("Order confirmed")

1
func aSignedInUser(ctx context.Context) (context.Context, error) {
2
  return ctx, signIn("ada@example.com", "s3cret")
3
}
4

5
func theyPayForTheirCart(ctx context.Context) (context.Context, error) {
6
  return ctx, pay()
7
}
8

9
func theySeeAnOrderConfirmation(ctx context.Context) (context.Context, error) {
10
  return ctx, expectText("Order confirmed")
11
}

1
import io.cucumber.java.en.*;
2

3
public class CheckoutSteps {
4
  @Given("a signed-in user")
5
  public void aSignedInUser() {
6
    page.signIn("ada@example.com", "s3cret");
7
  }
8

9
  @When("they pay for their cart")
10
  public void theyPay() {
11
    page.pay();
12
  }
13

14
  @Then("they see an order confirmation")
15
  public void theySeeConfirmation() {
16
    page.expectText("Order confirmed");
17
  }
18
}

1
using Reqnroll;
2

3
[Binding]
4
public class CheckoutSteps
5
{
6
    [Given("a signed-in user")]
7
    public void GivenASignedInUser() => Page.SignIn("ada@example.com", "s3cret");
8

9
    [When("they pay for their cart")]
10
    public void WhenTheyPay() => Page.Pay();
11

12
    [Then("they see an order confirmation")]
13
    public void ThenTheySeeConfirmation() => Page.ExpectText("Order confirmed");
14
}

Anti-patterns & best practices

Agree acceptance criteria first. Tests are derived from criteria the business signed off on, not invented after coding.
Keep scenarios business-readable. Robot Framework keywords and Gherkin should describe outcomes in the user’s language, not UI mechanics.
One scenario, one rule. Each acceptance test should trace to a single requirement (e.g. AC-14).
Automate the stable paths. Once criteria settle, move them into an automated Robot Framework or Cucumber suite; keep humans for judgement calls.
Never let UAT be the first place a defect is seen. Cheap defects belong to unit and integration tests.
Record the sign-off. Acceptance is a decision — capture who accepted and against which criteria.