Acceptance Criteria Authoring

Acceptance Criteria Authoring

When to Use This Skill

Use this skill when:

• Acceptance Criteria Authoring tasks - Working on write clear, testable acceptance criteria in given-when-then format following invest principles and bdd best practices
• Planning or design - Need guidance on Acceptance Criteria Authoring approaches
• Best practices - Want to follow established patterns and standards

Overview

Acceptance criteria define the conditions that must be met for a user story to be considered complete. Well-written acceptance criteria enable clear communication between stakeholders and drive automated acceptance tests.

Given-When-Then Format

Given [precondition/context]
When [action/event]
Then [expected outcome]

Components

INVEST Principles for User Stories

Acceptance Criteria Best Practices

Do ✅

• Use business language, not technical jargon
• Be specific and measurable
• Include happy path and edge cases
• Keep scenarios focused and atomic
• Write from user perspective
• Include error scenarios

Don't ❌

• Include implementation details
• Make criteria too broad
• Use ambiguous terms ("fast", "user-friendly")
• Combine multiple behaviors in one scenario
• Skip error handling scenarios

Example: E-commerce Checkout

User Story

As a registered customer
I want to checkout with a saved payment method
So that I can complete purchases quickly

Acceptance Criteria

Feature: Checkout with Saved Payment

  Background:
    Given I am logged in as a registered customer
    And I have a saved Visa card ending in 4242

  Scenario: Successful checkout with saved card
    Given I have items in my cart totaling $50.00
    When I proceed to checkout
    And I select my saved Visa card
    And I click "Place Order"
    Then I see an order confirmation page
    And I receive a confirmation email
    And my card is charged $50.00

  Scenario: Checkout with expired saved card
    Given my saved card has expired
    And I have items in my cart
    When I proceed to checkout
    And I select my expired card
    Then I see a message "This card has expired"
    And I am prompted to update the card or add a new one

  Scenario: Checkout when card is declined
    Given I have items in my cart
    When I proceed to checkout
    And I select my saved card
    And I click "Place Order"
    And the payment is declined
    Then I see a message "Payment declined. Please try another payment method."
    And the order is not created
    And my cart is preserved

  Scenario: Checkout with insufficient inventory
    Given I have 3 units of "Widget X" in my cart
    And only 2 units are in stock
    When I proceed to checkout
    Then I see a message "Widget X: Only 2 available"
    And I am prompted to update quantity

Scenario Patterns

Happy Path

Scenario: User successfully [action]
  Given [valid preconditions]
  When [correct action]
  Then [expected positive outcome]

Error Handling

Scenario: [Action] fails due to [reason]
  Given [preconditions that lead to failure]
  When [action that will fail]
  Then [appropriate error message]
  And [system state is preserved/recovered]

Edge Cases

Scenario: [Action] with boundary condition
  Given [boundary condition setup]
  When [action at boundary]
  Then [expected behavior at boundary]

Security

Scenario: Unauthorized user attempts [action]
  Given I am not logged in
  When I try to access [protected resource]
  Then I am redirected to login page
  And I see "Please log in to continue"

Scenario Outlines

Use for testing multiple data variations:

Scenario Outline: Discount applied based on order value
  Given I have items in my cart totaling <order_total>
  When I proceed to checkout
  Then I see a discount of <discount>
  And my final total is <final_total>

  Examples:
    | order_total | discount | final_total |
    | $50.00      | $0.00    | $50.00      |
    | $100.00     | $5.00    | $95.00      |
    | $200.00     | $20.00   | $180.00     |

.NET SpecFlow Example

[Binding]
public class CheckoutSteps
{
    private readonly CheckoutContext _context;

    public CheckoutSteps(CheckoutContext context)
    {
        _context = context;
    }

    [Given(@"I am logged in as a registered customer")]
    public void GivenIAmLoggedInAsARegisteredCustomer()
    {
        _context.Customer = TestCustomers.CreateRegistered();
        _context.Session = _context.AuthService.Login(_context.Customer);
    }

    [Given(@"I have items in my cart totaling \$(.*)")]
    public void GivenIHaveItemsInMyCartTotaling(decimal total)
    {
        _context.Cart = TestCart.WithTotal(total);
    }

    [When(@"I click ""(.*)""")]
    public void WhenIClick(string button)
    {
        _context.Result = _context.CheckoutPage.Click(button);
    }

    [Then(@"I see an order confirmation page")]
    public void ThenISeeAnOrderConfirmationPage()
    {
        Assert.IsType<OrderConfirmationPage>(_context.Result);
    }

    [Then(@"I receive a confirmation email")]
    public void ThenIReceiveAConfirmationEmail()
    {
        var emails = _context.EmailService.GetEmailsFor(_context.Customer.Email);
        Assert.Contains(emails, e => e.Subject.Contains("Order Confirmation"));
    }
}

Coverage Checklist

For each user story, ensure coverage of:

• Happy path: Main success scenario
• Validation errors: Invalid input handling
• Business rule violations: Domain constraint failures
• Authorization failures: Access control
• External service failures: Third-party integration errors
• Boundary conditions: Min/max values, empty states
• Concurrency: Multiple users, race conditions
• State transitions: Valid and invalid state changes

Acceptance Criteria Template

## User Story
As a [role]
I want to [action]
So that [benefit]

## Acceptance Criteria

### Scenario 1: [Happy path description]
Given [precondition]
When [action]
Then [expected outcome]

### Scenario 2: [Error case description]
Given [error-inducing condition]
When [action]
Then [error handling behavior]

### Scenario 3: [Edge case description]
Given [edge condition]
When [action]
Then [boundary behavior]

## Out of Scope
- [Explicitly excluded scenarios]

## Notes
- [Implementation hints or business context]

Integration Points

Inputs from:

• Requirements → Story context
• jtbd-analysis skill → Job steps
• test-case-design skill → Test techniques

Outputs to:

• SpecFlow/Cucumber automation
• test-strategy-planning skill → Acceptance test scope
• Definition of Done

Converted and distributed by TomeVault — claim your Tome and manage your conversions.