Generate Gherkin Acceptance Criteria That Survive the Testability Gate

Workflow area: Requirements Quality · Tier: Foundation · Hands-on time: ~25 minutes

Acceptance criteria are where requirements meet reality, and where most disputes at UAT are born. "The system shall handle errors gracefully" is a lawsuit, not a criterion. Gherkin's Given/When/Then structure forces concreteness, and AI is genuinely good at producing it — including the negative paths and boundary conditions humans skip when tired. What AI cannot do is know your actual business rules, so every generated criterion is either traceable to the story's evidence or it is a guess wearing syntax. The testability gate catches the guesses and the ambiguities before QA does.

When to use — and when not to

• Use it for every story entering sprint planningcriteria written at refinement time, with the product owner in the loop, are cheap; criteria reverse-engineered at UAT are expensive.
• Use it to harden existing vague criteriaa backlog full of "works correctly" clauses can be batch-rewritten and gated in an afternoon.
• Use it when edge-case coverage is the worryboundary values, empty states, permission denials, concurrency, timeouts: the model's checklist instincts beat a hurried human's.
• Skip it for exploratory or UX-subjective work"the animation feels smooth" belongs in a design review, not Gherkin; forcing it produces fake precision.
• Skip full Gherkin for trivial config changesa one-line change with an obvious check needs one sentence of acceptance, not scenarios.

The recipe

1. 1.

   Stage the story with its context. You need the story text, its evidence citations (from pb-04), any known business rules, and the field or workflow definitions the story touches. The more real rules you provide, the fewer the model invents.

2. 2.

   Generate criteria with edge cases, rules-bound.

   Copy

   You are a business analyst writing Gherkin acceptance criteria.
   Story: [PASTE STORY + EVIDENCE CITATIONS]
   Known business rules: [PASTE RULES, THRESHOLDS, FIELD CONSTRAINTS
   — e.g. "vendor tax ID is 10 digits; duplicates matched on tax ID
   + bank account; only supervisors can merge"]
   
   Produce:
   1. HAPPY PATH — 1-2 scenarios in Given/When/Then.
   2. EDGE CASES — scenarios for boundaries, empty/null inputs,
      permission denials, duplicates, and timing issues relevant to
      this story.
   3. NEGATIVE PATHS — what must NOT happen, as scenarios.
   4. QUESTIONS — every place you needed a rule I did not provide,
      as a question. Do NOT invent thresholds, formats, or role
      permissions; use [TBD] in the scenario and list the question.
   
   Rules:
   - Concrete values in every scenario (real-looking amounts, dates,
     role names), not placeholders like "valid input".
   - One behavior per scenario. No "and correctly" clauses.
   - Each scenario tagged with the rule or evidence it derives from,
     or tagged (PROPOSED) if it is your suggestion.
   

3. 3.

   Read a sample of good output.

   Copy

   Scenario: Duplicate vendor blocked at entry (rule: tax ID + bank)
     Given a vendor "Acme Ltd" exists with tax ID 4455667788
     And bank account ending 9921
     When a clerk submits a new vendor with the same tax ID and
       bank account
     Then the submission is blocked
     And the clerk sees the existing vendor's ID and creation date
   
   Scenario (PROPOSED): Near-duplicate flagged for review
     Given a vendor exists with tax ID 4455667788
     When a clerk submits a vendor with the same tax ID but a
       different bank account
     Then the vendor is created with status "review" [TBD: is this
       the intended behavior, or should it block?]
   
   QUESTIONS
   - What happens to in-flight invoices when vendors are merged?
   

4. 4.

   Apply the testability gate — the human pass. For every scenario ask two questions. First: could QA automate this exactly as written — are the Given state, the When action, and the Then observation all concrete enough to script? Second: could two reasonable people disagree on pass/fail? Words like "quickly", "appropriate", "user-friendly", and "handles" fail the gate. Rewrite or delete. Then run the model as a second gate reviewer in a fresh conversation: "For each scenario, state how an automated test would verify the Then clause, and flag any scenario where pass/fail is arguable." Disagreements between your pass and the model's are the interesting findings.

5. 5.

   Resolve every [TBD] and (PROPOSED) with the business owner. The QUESTIONS list is elicitation gold — each item is a rule the organization has not yet decided or you have not yet captured. Take them to the product owner or SME; their answers convert [TBD]s into rules and (PROPOSED) scenarios into accepted or deleted ones. Criteria go to the backlog only after this pass — the model proposes, the business decides.

6. 6.

   Attach criteria to the story with their tags intact. The rule tags and evidence links make UAT disputes short: when someone challenges a criterion in cycle two, the tag says exactly which rule or decision it encodes and who confirmed it.

Make it yours

• Claude Project with your rules library: pin the domain's business rules, field dictionary, and permission matrix in a Project; generation then draws on real rules by default and the QUESTIONS list shrinks over time.
• Jira AI for in-context drafting: generate criteria directly on the issue for speed, but paste the result through the testability-gate prompt in your chat tool — native assistants draft well and critique gently.
• ChatGPT for batch hardening: feed twenty vague legacy criteria in one go with "rewrite each into testable Gherkin, list every invented assumption" — a fast first pass over an inherited backlog.
• Team scale: make the two-question gate part of your definition of ready, and keep a shared bank of gate failures ("handles errors gracefully" and friends) — new analysts learn the standard from the examples.

Quality check

• Every Then clause is observablea specific system response, state change, or message; if you cannot name where QA would look, it fails.
• No smuggled inventionsevery threshold, format, and permission in the scenarios traces to a provided rule, cited evidence, or a resolved [TBD]; models love inventing plausible limits.
• Negative paths existcriteria with only happy paths test half the story; at least one "must not" scenario per story.
• The two-person disagreement test passedread each scenario as a hostile vendor would at UAT; ambiguity you can exploit, they will.
• Business owner signed the judgment callsevery (PROPOSED) scenario and [TBD] answer has a named human decision behind it.
• Concrete values are realistic but fictionalscenario data resembles production shape without copying production records.