Acceptance Testing Explained: Bridging the Gap Between Dev and Business

You can build something that works perfectly and is completely wrong. Unit tests pass. Integration tests pass. The feature isn't what anyone asked for.

Acceptance testing is the checkpoint that catches this. It answers the question: did we build the right thing?

What Acceptance Testing Is (and Isn't)

It is: Verification that the system meets the business requirements as defined by stakeholders.

It is not: Finding bugs in implementation details. Unit tests do that.

It is: Testing the system from the user's perspective against agreed acceptance criteria.

It is not: A developer self-review. Acceptance testing should involve the person who defined the requirements.

Acceptance Criteria: The Foundation

Every user story should have acceptance criteria before development starts. Not vague success conditions — specific, testable statements:

Bad acceptance criteria:

The user can manage their tasks.

Good acceptance criteria:

• Given a user is on the task list screen
• When they tap "Add Task" and enter a non-empty title
• And tap "Save"
• Then the task appears in the list with the entered title and "Active" status

This is the Gherkin syntax (Given/When/Then). You don't need the Gherkin framework — the structure is what matters. It forces specificity.

The Acceptance Testing Process

Step 1: Agree on criteria before development begins.

Not during. Not after. Before. If you're writing acceptance criteria after the feature is built, you're rationalizing what was built, not verifying what was specified.

Step 2: Develop against the criteria.

The acceptance criteria are essentially a contract. Development is finished when all criteria pass, not when the code "looks done."

Step 3: QA or product owner runs the acceptance tests.

Ideally, the person who wrote the criteria runs them. They know the intent behind each criterion better than anyone.

Step 4: Disagreements are resolved against the criteria.

If the implementation works but doesn't match the criteria, the criteria wins. Either the implementation is wrong, or the criteria were wrong — both are valid outcomes, but they need to be explicitly resolved.

User Acceptance Testing (UAT)

UAT is acceptance testing by actual end users. This is different from QA acceptance testing — it surfaces usability issues and domain-specific issues that QA engineers might miss.

UAT is valuable for:

• New features with complex workflows
• Features affecting power users with specific domain knowledge
• Features where "correct" depends on business context a developer doesn't have

Running effective UAT:

• Provide structured scenarios, not a list of requirements
• Ask users to complete tasks, not "look for bugs"
• Watch them use it without guiding them
• Note confusion and friction, not just hard failures

Behavior-Driven Development (BDD) — Connecting Tests to Criteria

BDD automates acceptance testing using the Gherkin format. Scenarios written by product/QA become executable tests:

# task_creation.feature
Feature: Task Creation

  Scenario: Successfully creating a task
    Given I am on the task list screen
    When I tap "Add Task"
    And I enter "Buy groceries" as the title
    And I tap "Save"
    Then I should see "Buy groceries" in the task list
    And the task status should be "Active"

  Scenario: Attempting to create task with empty title
    Given I am on the task list screen
    When I tap "Add Task"
    And I leave the title empty
    And I tap "Save"
    Then I should see the error "Title cannot be empty"
    And no new task is added to the list

These scenarios are written by product owners or QA engineers — people who understand requirements, not necessarily code.

The step implementations are written by developers:

@Then("I should see {string} in the task list")
fun verifyTaskInList(taskTitle: String) {
    composeTestRule.onNodeWithText(taskTitle).assertIsDisplayed()
}

Tools: Cucumber for Android, Karate (for API-level BDD)

When BDD Adds Value (and When It Doesn't)

BDD adds value when:

• Non-technical stakeholders can read and contribute to scenarios
• Requirements are complex enough that their translation to code isn't obvious
• You have a dedicated QA engineer writing scenarios

BDD adds overhead without value when:

• You're a solo developer who writes both scenarios and step definitions
• The test scenarios are just duplicating unit tests in verbose prose
• Nobody actually reads the .feature files

For small teams or solo developers, writing acceptance criteria as comments in tests is often sufficient:

// AC: Task with empty title should not be saved and show validation error
@Test
fun `empty title shows validation error`() { ... }

Acceptance Testing in Practice

The lightweight version that works for most teams:

1. Before development: write acceptance criteria in the ticket
2. During development: keep the criteria visible and develop against them
3. Before merging: QA or developer runs through each criterion manually
4. Automate: any manual criterion that's executable becomes an automated test

This isn't ceremonial BDD. It's just ensuring someone verifies each requirement was met before shipping.

Takeaways

• Acceptance testing answers "did we build the right thing?" — unit tests answer "did we build it right?"
• Acceptance criteria must be written before development starts, not after
• Given/When/Then format forces specificity and removes ambiguity
• BDD is valuable for teams with non-technical stakeholders — overhead for solo developers
• The minimum viable practice: write criteria in the ticket, verify each one before closing it