Skill

acceptance-criteria-authoring

Write clear, testable acceptance criteria in Given-When-Then format following INVEST principles and BDD best practices.

From test-strategy
Install
1
Run in your terminal
$
npx claudepluginhub melodic-software/claude-code-plugins --plugin test-strategy
Tool Access

This skill is limited to using the following tools:

ReadWriteGlobGrepTask
Skill Content

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

ComponentPurposeExample
GivenSet up initial context"Given a logged-in premium user"
WhenTrigger action/event"When they click 'Download Report'"
ThenAssert expected outcome"Then a PDF report downloads"
AndChain multiple conditions"And the report includes all orders"
ButNegative assertion"But archived orders are excluded"

INVEST Principles for User Stories

LetterPrincipleDescription
IIndependentCan be developed in any order
NNegotiableDetails can be discussed
VValuableDelivers user/business value
EEstimableCan be sized by team
SSmallFits in one sprint
TTestableHas clear acceptance criteria

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
Stats
Parent Repo Stars40
Parent Repo Forks6
Last CommitDec 27, 2025