Convert this requirement into well-structured Gherkin BDD scenarios:
$ARGUMENTS
Output Format
Generate a complete Gherkin feature file:
gherkin
Feature: [Feature Name]
As a [role]
I want [capability]
So that [benefit]
Background:
Given [common preconditions shared by all scenarios]
@happy-path
Scenario: [Descriptive scenario name - success case]
Given [initial context]
And [additional context if needed]
When [action taken]
And [additional action if needed]
Then [expected outcome]
And [additional verification]
@edge-case
Scenario: [Edge case description]
Given [context]
When [action]
Then [outcome]
@error-handling
Scenario: [Error scenario description]
Given [context that will cause error]
When [action attempted]
Then [error handling behavior]
And [user feedback]
@validation
Scenario Outline: [Parameterized test description]
Given [context with <parameter>]
When [action with <input>]
Then [outcome with <expected>]
Examples:
| parameter | input | expected |
| value1 | val1 | result1 |
| value2 | val2 | result2 |
Guidelines
Scenario Coverage
Include scenarios for:
- •Happy path - Normal successful flow
- •Edge cases - Boundary conditions
- •Error handling - Invalid inputs, failures
- •Permissions - Unauthorized access attempts
- •Data variations - Use Scenario Outline for multiple inputs
Writing Style
- •Use domain language, not technical jargon
- •Keep steps atomic and focused
- •Avoid implementation details in scenarios
- •Use present tense
- •Be specific with test data
Tags
Use tags to categorize:
- •
@happy-path- Success scenarios - •
@edge-case- Boundary conditions - •
@error-handling- Failure scenarios - •
@smoke- Critical path tests - •
@regression- Full test suite
Anti-Patterns to Avoid
- •Don't use "click" or UI-specific language
- •Don't chain multiple actions in one step
- •Don't include technical implementation details
- •Don't make scenarios dependent on each other