A scenario is a concrete example of how a feature behaves under particular conditions. It gives business stakeholders and the delivery team something specific to discuss: what is true beforehand, what happens, and what outcome should follow. Agreed scenarios can become acceptance criteria, automated tests, and living documentation. section 3.0 section 7.6.1
Make an expectation testable
For a frequent-flyer feature: Given a traveler belongs to the program, when they complete a flight between Paris and Berlin, then they should earn 100 points. The route and expected points make the rule discussable and verifiable. If a stakeholder identifies an exception, write another example rather than leaving the rule implicit. section 7.1 section 6.6.4
In Gherkin, scenarios sit in a feature file. A descriptive Scenario title identifies what is distinctive about each example. Given states the preconditions, When names the action, and Then states the expected result; And and But extend those steps. A Scenario Outline and Examples table can express several similar cases without repeating the whole scenario. section 2.3.5 section 7.2.2
Draft scenarios together before treating them as test scripts. A seemingly clear train-departure example became more precise when discussion exposed an ambiguous direction and the need to show more than one train. That refinement is part of the work: a scenario should reveal gaps in understanding, not merely record a decision already made. section 3.4
Scenario: Search for available hotels by distance
Given the following hotels:
| Hotel Name | Location | Distance from center |
| Ritz | Paris | 3.2 |
| Savoy | Paris | 6.9 |
| Hilton | Paris | 12.5 |
When I search for a hotel within 10 km of Paris
Then I should be presented with the following hotels:
| Hotel Name | Location | Distance from center |
| Ritz | Paris | 3.2 |
| Savoy | Paris | 6.9 |
The hotel-search scenario keeps one business rule visible: which hotels appear within a requested distance. Its setup supplies the relevant hotels, and its result names the expected matches without walking through screen navigation or payment. section 7.6.4 section 7.6.6
Keep the resulting set useful over time:
- Cover simple behavior, alternative paths, and edge cases; start with focused cases before combining concerns. section 7.4.2 section 7.6.4
- Make each scenario runnable independently. A chain in which one scenario prepares the next is fragile when an earlier step fails. section 7.6.8
- Group scenarios by the feature they illustrate, rather than by temporary stories or releases, so the files remain useful as product documentation. section 7.4.1 section 7.4.5
Automation should preserve the business-level wording. Step definitions translate scenario steps into reusable tasks and actions; a lower interaction layer handles details such as page elements or REST endpoints. This separation lets a scenario concentrate on the expected outcome rather than how the application happens to deliver it. section 9.3.1
