Given-When-Then
A structured format for writing acceptance criteria and test scenarios that specifies context, action, and expected outcome in plain language.
Also known as: GWT, Gherkin Syntax, BDD Scenarios
Category: Techniques
Tags: software-development, testing, agile, requirements, communications
Explanation
Given-When-Then (GWT) is a semi-structured format for writing acceptance criteria, test scenarios, and behavioral specifications. It originates from Behavior-Driven Development (BDD) and the Gherkin language used by tools like Cucumber, SpecFlow, and Behave.
**The structure:**
- **Given**: The precondition or context. What state is the system in before the action?
- **When**: The action or event. What does the user or system do?
- **Then**: The expected outcome. What should happen as a result?
**Example:**
```
Given a registered user is on the login page
When they enter valid credentials and click "Sign In"
Then they are redirected to their dashboard
And a welcome message is displayed
```
**Extended keywords:**
- **And**: Adds additional conditions to Given, When, or Then
- **But**: Adds a negative condition ("But no error message is shown")
- **Background**: Shared preconditions for multiple scenarios
- **Scenario Outline**: Parameterized scenarios with multiple data sets
**Why Given-When-Then works:**
- **Shared language**: Business people, developers, and testers can all read and write GWT scenarios. It bridges the communication gap between technical and non-technical stakeholders
- **Testable by design**: Every GWT scenario is inherently a test case. It specifies what to set up (Given), what to do (When), and what to verify (Then)
- **Forces clarity**: The structure prevents vague requirements. You cannot write a GWT scenario without thinking through the specific context, action, and expected result
- **Living documentation**: When automated, GWT scenarios serve as both tests and documentation that stays current with the codebase
- **Consistent format**: Teams adopt a uniform way of expressing requirements, making backlogs more readable and reducing ambiguity
**Common mistakes:**
- **Too technical**: GWT should use business language, not implementation details ("Given the user table has a row" vs. "Given a registered user exists")
- **Multiple actions in When**: Each scenario should test one behavior. Multiple When clauses suggest the scenario should be split
- **Vague Then clauses**: "Then it works correctly" is useless. Be specific about observable outcomes
- **Testing implementation, not behavior**: Focus on what the system does, not how it does it internally
**GWT beyond software:**
The Given-When-Then pattern is useful beyond software testing. It can structure any expected behavior or process: project plans, operational procedures, decision criteria, and even personal goals. Any time you need to define "when X happens, Y should result, assuming Z conditions," GWT provides a clear template.
Related Concepts
← Back to all concepts