BDD Acceptance Criteria Template (Gherkin)
Feature, stories, rules with examples, Gherkin feature file (Rule, Background, Scenario Outline, tags), trace to tests, checklist, anti-patterns
Cara menggunakan: Use it when a team agrees acceptance criteria for stories as executable Given/When/Then scenarios. Fill the rules and examples first, then the feature file with scenario and story tags. The main pitfall is UI scripting instead of business-level behaviour.
Pratinjau
Acceptance Criteria (BDD): [Feature name]
Acceptance criteria for one feature, written as Gherkin feature files with Given/When/Then scenarios and traced to the user stories they accept. The syntax follows the Gherkin reference published by the Cucumber project (cucumber.io). Scenarios written this way can be read by the business and run as automated tests. Replace every
[bracketed]value and every row marked Example.
Document control
| Field | Value |
|---|---|
| Document ID | [AC-FEATURE-001] |
| Feature | [Feature name] |
| Epic | [Epic ID and title] (product/epic) |
| Stories covered | [US-nnn, US-nnn] (product/user-story) |
| Version | [0.1] |
| Status | [Draft / Agreed / Automated / Retired] |
| Owner | [@product-owner] |
| Contributors | [@developer], [@tester] |
| Feature file path | [features/claims/notify-claim.feature] |
| Last updated | YYYY-MM-DD |
1. Feature and stories
[One sentence: who gets what value from this feature.]
| Story ID | Story | Priority | Scenarios |
|---|---|---|---|
| US-101 (Example) | As a policyholder I want to report a burst pipe online so that I do not wait on the phone | Must | SC-01, SC-02 |
| US-102 (Example) | As a policyholder I want to add photos so that the handler can assess the damage quickly | Should | SC-03 |
| US-103 (Example) | As a claims handler I want claims above the referral limit routed to me so that large losses get a check | Must | SC-04, SC-05 |
| [US-nnn] | [Story] | [Priority] | [SC-nn] |
2. Business rules and examples
| Rule | Statement | Source | Examples |
|---|---|---|---|
| BR-CLM-004 (Example) | A claim can be notified online only for an active policy | requirements/business-rules-catalogue | SC-01, SC-02 |
| BR-CLM-007 (Example) | Claims with an estimated value above 5,000 are referred to a handler before any payment | Claims authority matrix | SC-04, SC-05 |
| BR-CLM-009 (Example) | Each photo must be 10 MB or smaller, at most 10 photos per claim | Upload policy | SC-03 |
3. Feature file
The example file below is the source of truth for the feature. Keep it in the code repository next to the step definitions, and copy it here only for review and sign-off. Each Rule block carries the rule ID from section 2, and each scenario carries its scenario and story tags, so a failing test in a report points straight back to the story it accepts. The Scenario Outline runs once per row of its Examples table, which gives four test runs for one written scenario.
# language: en
@feature-notify-claim
Feature: Notify a home insurance claim online
Policyholders report damage to their home online and get a claim
reference without calling the contact centre.
Background:
Given the policyholder "Ana Ruiz" is signed in
And she holds home policy "HP-20481"
Rule: BR-CLM-004 Only active policies can notify a claim online
@SC-01 @US-101
Scenario: Claim notified for an active policy
Given her policy "HP-20481" is active
When she reports "escape of water" damage that happened yesterday
Then she sees a claim reference
And she receives a confirmation e-mail with the same reference
@SC-02 @US-101
Scenario: Claim rejected for a lapsed policy
Given her policy "HP-20481" lapsed last month
When she tries to report "escape of water" damage
Then she is told that the policy is not active
And she is offered the contact centre number
Rule: BR-CLM-009 Photos are limited in size and number
@SC-03 @US-102
Scenario Outline: Photo upload limits
Given her policy "HP-20481" is active
And she has notified a claim
When she uploads <count> photos of <size> MB each
Then the upload is <result>
Examples:
| count | size | result |
| 3 | 4 | accepted |
| 10 | 10 | accepted |
| 11 | 2 | rejected |
| 1 | 12 | rejected |
Rule: BR-CLM-007 Large claims are referred to a handler
@SC-04 @US-103
Scenario: Claim above the referral limit is referred
Given her policy "HP-20481" is active
When she reports damage with an estimated value of 7,500
Then the claim status is "Referred to handler"
And no payment is offered online
@SC-05 @US-103
Scenario: Claim at the referral limit is not referred
Given her policy "HP-20481" is active
When she reports damage with an estimated value of 5,000
Then the claim status is "Open"
4. Traceability
| Scenario | Story | Rule | Automated test | Last result |
|---|---|---|---|---|
| SC-01 (Example) | US-101 | BR-CLM-004 | notify-claim.feature:14 | [Pass / Fail / Not run] |
| SC-02 (Example) | US-101 | BR-CLM-004 | notify-claim.feature:21 | [Result] |
| SC-03 (Example) | US-102 | BR-CLM-009 | notify-claim.feature:30 (4 examples) | [Result] |
| SC-04 (Example) | US-103 | BR-CLM-007 | notify-claim.feature:46 | [Result] |
| SC-05 (Example) | US-103 | BR-CLM-007 | notify-claim.feature:53 | [Result] |
Copy the links into requirements/traceability-matrix when the project
keeps one matrix for all requirements.
5. Writing checklist
| Check | Question |
|---|---|
| Business language | Would a stakeholder recognise every step without a developer explaining it? |
| One behaviour | Does each scenario test one rule, with a single When? |
| Observable outcome | Do the Then steps check what a user or another system can observe, not internal state? |
| Boundaries | Are values at, just below and just above each limit covered (SC-04 and SC-05 test both sides of 5,000)? |
| Independence | Can each scenario run alone and in any order? |
| Background | Does the Background hold only context that every scenario under it needs? |
| Keywords | Are colons used only after keywords that take them (Feature, Rule, Background, Scenario, Scenario Outline, Examples)? |
| Tags | Does every scenario carry its scenario ID and story ID? |
| Definition of done | Does the team's definition of done (product/definition-of-done) require these scenarios to pass? |
6. Common anti-patterns
| Anti-pattern | Why it hurts | Rewrite as |
|---|---|---|
| UI scripting ("When I click Submit, then I type...") | Breaks when the screen changes, hides the rule | One business-level When step |
| Several When steps in one scenario | Tests two behaviours; a failure does not say which | Split into two scenarios |
| Then steps that check database rows | Couples the test to the design | Check what the user or a downstream system sees |
| Long Background with data for one scenario only | Every scenario pays for it and readers lose context | Move that Given into the scenario |
| Examples tables with dozens of rows | Hard to review, slow to run | Keep boundary and representative rows; cover the rest with unit tests |
| Vague data ("a big claim") | Readers disagree on the limit | Use concrete values next to the boundary |
7. Open questions
| ID | Question | Owner | Due | Answer |
|---|---|---|---|---|
| Q-01 (Example) | Should a claim at exactly 5,000 be referred? Agreed: no, the rule says "above" | [@product-owner] | YYYY-MM-DD | Answered, SC-05 |
| [Q-nn] | [Question] | [@name] | YYYY-MM-DD | [Answer] |
Standard and licence note
Based on the Gherkin reference published by the Cucumber project at https://cucumber.io/docs/gherkin/reference/ (keywords Feature, Rule, Background, Scenario or Example, Scenario Outline, Examples, the step keywords Given, When, Then, And, But, tags and comments). The feature file, rules and examples are fictional and original text written for this collection. Check the current Gherkin reference before use, as keyword support can change between Gherkin versions. Template licence: MIT.
Templat terkait
Business Analysis Plan Template
Plan for BA work: approach decision, stakeholder engagement, decision rights and change control, information management, BA performance measures, effort, risks
Kebutuhan & AnalisisBusiness Requirements Specification (BRS) Template
Business purpose, measurable objectives, processes, rules, business requirements with attributes, success metrics (BRS/BRD)
Kebutuhan & AnalisisBusiness Rules Catalogue Template
Business rules: types and conventions, catalogue with ID, statement, type, source, owner, enforcement level, details, enforcement points, change log