/attest

BDD Scenario Generation

Purpose: Read this when turning AC-* criteria into SC-* scenarios, checking scenario coverage by priority, or validating Given/When/Then quality.

For Gherkin block-element syntax (Feature / Background / Scenario / Scenario Outline / Examples / Tags / Steps), see gherkin-authoring.md § Gherkin Anatomy. This file focuses on scenario generation from acceptance criteria — coverage minimums by priority, scenario types (HP/NP/BP/EP), and generation anti-patterns.

Contents

• Generation rules
• Given/When/Then structure
• Scenario templates by category
• Coverage matrix
• Output format
• Anti-patterns
• Quality checklist

Generation Rules

Core Principle

Every acceptance criterion produces at least:

1. Happy path
2. Negative path
3. Edge or boundary path

Scenario ID Convention

SC-{criterion_id}-{type}-{NNN}

Types:
  HP = Happy Path
  NP = Negative Path
  BP = Boundary Probe
  EP = Edge / Error Path

Given/When/Then Structure

Given

• Establish the starting state.
• Include roles, data state, or system configuration when relevant.
• Prefer concrete examples over abstract placeholders.

Given a registered user with email "user@example.com" and role "admin"

When

• One primary action per scenario.
• Include the relevant input values.
• Describe the business action, not incidental UI clicks.

When the user submits the login form with correct credentials

Then

• Use observable, verifiable outcomes.
• Include concrete status codes, values, or state changes when possible.
• Add secondary And clauses only when they describe required outcomes.

Then the HTTP response status is 200
And the user is redirected to "/dashboard"

Scenario Templates by Category

Happy Path

@happy-path @{criterion_id}
Scenario: {Business rule succeeds}
  Given {valid preconditions}
  When {the primary action with valid inputs}
  Then {the successful outcome}

Negative Path

@negative @{criterion_id}
Scenario: {Business rule rejects invalid input}
  Given {preconditions}
  When {the action with invalid or unauthorized input}
  Then {the expected rejection}
  And {state remains unchanged if required}

Boundary Probe

@boundary @{criterion_id}
Scenario: {Boundary value handling}
  Given {boundary preconditions}
  When {the action with boundary input}
  Then {the expected boundary behavior}

Edge / Error Path

@edge-case @{criterion_id}
Scenario: {Unusual but valid situation}
  Given {edge-condition preconditions}
  When {the action under edge conditions}
  Then {the graceful outcome}

Must-Keep Example

# AC-LOGIN-001: Valid credentials grant access
Scenario: Successful login with valid credentials
  Given a registered user with email "user@example.com"
  And the user has a valid password
  When the user submits the login form with correct credentials
  Then the user is redirected to the dashboard
  And a session token is issued

Scenario: Login failure with invalid password
  Given a registered user with email "user@example.com"
  When the user submits the login form with an incorrect password
  Then an error message "Invalid credentials" is displayed
  And no session token is issued

Scenario: Login with boundary email length
  Given a registered user with a 254-character email
  When the user submits the login form with correct credentials
  Then the user is redirected to the dashboard

Coverage Matrix

SCENARIO_COVERAGE:
  criterion_id: AC-LOGIN-001
  criterion_text: "Valid credentials grant access"
  scenarios:
    happy_path: 1
    negative: 2
    boundary: 1
    edge_case: 0
  total: 4
  coverage_verdict: SUFFICIENT

Minimum Coverage Requirements

Coverage verdict: SUFFICIENT when the minimum requirement is met or exceeded.

Output Format

BDD_SCENARIOS:
  spec_source: "docs/login-spec.md"
  total_criteria: 12
  total_scenarios: 42
  scenarios_by_type:
    happy_path: 12
    negative: 15
    boundary: 10
    edge_case: 5
  coverage_verdict: SUFFICIENT
  gherkin_file: "generated/login.feature"

Anti-Patterns

Quality Checklist

• Scenarios were generated before or during implementation
• One scenario covers one business rule
• Language is business-facing, not implementation-facing
• Given = state, When = one action, Then = verifiable result
• Titles describe the business purpose clearly
• Negative and boundary coverage is present where required
• Scenario count satisfies priority-based minimums

Scenario Quality Validation (SKILL.md excerpt)

Before finalizing generated scenarios, validate each against these attributes:

Flag violations as SCENARIO_DEFECT:{attribute}. Rewrite before including in deliverable. Source citations in reference/modern-tooling.md.