Behaviour-Driven Development (BDD)

Status: Complete
Category: Testing
Default enforcement: Advisory
Author: PushBackLog team

Tags

• Topic: testing, quality
• Methodology: BDD
• Skillset: any
• Technology: generic
• Stage: refinement, execution

Summary

Behaviour-Driven Development extends TDD by framing tests in terms of the desired behaviour of a system from a user or business perspective. Scenarios are expressed in a human-readable format (Given/When/Then) that bridges the gap between technical implementation and business requirements.

Behaviour-Driven Development (BDD)

Status: Complete
Category: Testing
Default enforcement: Advisory
Author: PushBackLog team

Tags

• Topic: testing, quality
• Methodology: BDD
• Skillset: any
• Technology: generic
• Stage: refinement, execution

Summary

Behaviour-Driven Development extends TDD by framing tests in terms of the desired behaviour of a system from a user or business perspective. Scenarios are expressed in a human-readable format (Given/When/Then) that bridges the gap between technical implementation and business requirements.

Rationale

The gap BDD was built to close

TDD improves code quality from the inside out: it encourages testable design, reduces defects, and builds a safety net. But TDD tests are typically written by and for engineers. They verify that the code does what the engineer intended — not necessarily what the business needed. Dan North introduced BDD in 2003 specifically to close this gap: by framing tests as observable behaviour from the outside, and writing them in a language that non-engineers can read and challenge.

Shared language, shared understanding

BDD’s most significant benefit is not the test format — it is the conversation that produces the scenarios. When a product manager, developer, and tester collaboratively write Given/When/Then scenarios for a story before development starts, they are forced to surface assumptions, edge cases, and disagreements about what the feature is supposed to do. This is the “three amigos” practice: the same three-way conversation that produces good Acceptance Criteria.

BDD as living documentation

BDD scenarios that are also executable tests form living documentation: a specification of the system’s behaviour that is always current because it runs on every CI build. Passing scenarios describe what the system does; failing scenarios describe what it does not yet do. This is far more accurate than a wiki that is rarely updated.

Connection to PushBackLog

Acceptance criteria written in Given/When/Then format are directly portable to BDD scenarios — they can become automated tests with minimal transformation. Teams that write high-quality AC with GWT format are already halfway to BDD; the test code completes the loop.

Guidance

The Given/When/Then structure

Writing scenarios, not tests

Scenarios should be written from the outside — what a user sees and does — not from the inside (no implementation references). Good BDD uses the language of the domain, not the language of the code:

• Good: Given a customer with a loyalty tier of Gold
• Bad: Given the UserRecord has loyaltyTier set to 'gold' in the database

The three amigos

For BDD to work, scenarios must be produced collaboratively:

1. Product manager / BA: defines the what and why; owns the business intent
2. Developer: challenges feasibility; spots missing states and edge cases
3. Tester: probes the boundaries; adds failure scenarios and edge cases

The meeting happens before development starts, during refinement. Scenarios produced after implementation are documentation, not specification.

Tooling

Common BDD frameworks:

Examples

Subscription upgrade

Feature: Subscription management

  Scenario: Upgrading from Free to Pro plan
    Given a user is on the Free plan
    And they have been a member for more than 30 days
    When they select the Pro plan and confirm payment
    Then their plan is updated to Pro
    And they receive an upgrade confirmation email
    And their feature limits are updated immediately

  Scenario: Attempting to upgrade with an expired card
    Given a user is on the Free plan
    And their saved payment card is expired
    When they select the Pro plan and confirm payment
    Then they see an error: "Your payment method has expired"
    And their plan remains Free
    And they receive no confirmation email

Mapping to AC

Compare this BDD scenario to a GWT acceptance criterion:

AC: When a user upgrades from Free to Pro with a valid payment,
    their plan is updated immediately and a confirmation email is sent.

BDD Scenario: directly executable version of that same criterion.

Good AC writes itself into BDD — the only gap is the automation layer.

Anti-patterns

1. Developers writing scenarios alone after the fact

Scenarios written post-implementation confirm what was built, not what was needed. BDD produces value in the conversation, not just the artefact.

2. Implementation language in scenarios

Referencing database state, class names, API endpoints, or internal flags in Given/When/Then destroys the readability for non-engineers and couples the spec to the implementation.

3. Scenario bloat

A single scenario with 20 steps is not a BDD scenario — it’s an integration test disguised as documentation. Each scenario should cover one specific behaviour. Use Background for shared setup.

4. One scenario per story

A story almost always has multiple behaviours: the happy path, edge cases, and failure states. Each should be a separate scenario. A story with one scenario is an incomplete specification.

5. BDD as a QA-only activity

When only the test team writes BDD scenarios, the product and development voices are missing. The shared language degrades into test scripts in a different format.

Related practices

• Test-Driven Development (TDD)
• Acceptance Criteria Quality
• Definition of Done

Part of the PushBackLog Best Practices Library. Suggest improvements →