Q17 of 38 · Test design
How do you derive test cases from acceptance criteria written in BDD/Gherkin?
Test designMidbddgherkinacceptance-criteriamid
Short answer
Short answer: Each Given-When-Then scenario maps directly to one test case; Given sets up state, When performs the action, Then asserts the outcome. Augment Gherkin scenarios with EP/BVA for the inputs they reference and add explicit negative scenarios that the AC doesn't enumerate.
Detail
Gherkin (Cucumber's syntax) gives you scenarios in a structured format. Each scenario maps to one test case directly. The Given clauses become test setup; the When is the action under test; the Thens are the assertions.
The deriving process:
- Implement each scenario as a test. One Gherkin scenario = one parameterised or specific test. Step definitions become the bridge to the production code.
- Augment Gherkin with input-level test design. Gherkin scenarios usually use one example value. Add scenario outlines with example tables to apply EP/BVA without duplicating scenarios.
- Add scenarios the AC doesn't enumerate. Acceptance criteria are usually written for the happy path and obvious negatives. The tester adds: invalid code scenarios (expired, already used, wrong format), combination scenarios (what if two valid codes are entered?), edge boundary scenarios, side-effect scenarios (apply then remove then re-apply).
- Review scenarios with stakeholders. The strength of Gherkin is that PMs can read scenarios. Walk through the augmented scenarios in the three-amigos meeting, get sign-off, then implement.
- Don't make every test Gherkin. Gherkin shines for behaviour-level acceptance tests; it's overhead for unit tests. Use it where stakeholder readability matters.
The signal: treating ACs as a starting point that needs augmentation, not as a complete test plan.
// EXAMPLE
discount.feature
Feature: Apply discount code
Scenario Outline: Discount applies based on cart total
Given a cart with total £<total>
And a valid discount code "SAVE10" worth 10%
When the user applies the code
Then the discounted total is £<discounted>
Examples:
| total | discounted |
| 100 | 90 |
| 50 | 45 |
| 0.01 | 0.01 | # boundary: tiny order
| 0 | 0 | # boundary: empty cart
Scenario: Expired discount code is rejected
Given a cart with total £100
And a discount code "EXPIRED1" with expiry in the past
When the user applies the code
Then the cart total is unchanged at £100
And an error "This code has expired" is shown
Scenario: Two codes entered in sequence — second replaces first
Given a cart with total £100
And the user has applied "SAVE10"
When the user applies "SAVE20"
Then only "SAVE20" is active
And the discounted total is £80// WHAT INTERVIEWERS LOOK FOR
Recognition that AC are not exhaustive; using scenario outlines for input variation; and pushing back on scenarios that lack assertion clarity.
// COMMON PITFALL
Treating the AC as the complete test plan — they cover what to demo, not what to test.