BDD & Gherkin: Writing Tests That Everyone Understands

What is BDD?

Behaviour Driven Development (BDD) is a software development process focused on clearly identifying the desired behaviour of a feature from the very beginning. It is written in a ubiquitous language — one that both business and technical members understand — to improve communication and reduce ambiguity.

BDD is a three-step iterative cycle:

Take a small upcoming change — a user story — and talk about concrete examples of the new functionality
Document those examples in a way that can be automated, and check for agreement
Implement the behaviour described by each example, starting with an automated test

The key insight: each change should be small, and the team should iterate rapidly — moving back up a level whenever more information is needed.

Advantages of BDD

Advantage	What it means
Inclusion	Non-technical stakeholders can read and validate scenarios
Clarity	Shared understanding reduces rework from misunderstood requirements
Traceability	Tests are directly linked to acceptance criteria and user stories
Shift-Left	Defects are caught at the requirements stage
Automation	Scenarios are executable — they drive test implementation
Reusability	Step definitions are shared across scenarios
Parametrization	Scenario Outlines allow data-driven testing without duplication

BDD refines your agile process and makes customer experience paramount.

Gherkin

Gherkin is the DSL (Domain-Specific Language) used to write BDD scenarios. It supports 70+ languages, requires no coding skills to write, and directly drives test automation frameworks like Cucumber.

Structure

Feature: <Business requirement being tested>

  Scenario: <Specific behaviour being verified>
    Given <precondition — the initial state>
    When  <action — what the user or system does>
    Then  <assertion — the expected outcome>
    And   <additional assertion or action>
    But   <exception or negative case>

All steps may be parameterized. Scenario Outlines run the same scenario with multiple data sets.

User Story → Scenarios

User Story:

As an analytics user, I am able to sort table data by one column, so I can order metrics by one that is of certain importance.

Acceptance Criteria:

By default, data is not sorted by any column
A first click on a column sorts rows descending
A second click on the same column sorts rows ascending

Gherkin Scenarios:

Scenario: Table data is unsorted by default
  Given the analytics user has the table visible on screen
  When the user takes no action
  Then the data is not sorted by any column

Scenario: First click sorts a column in descending order
  Given the analytics user has the table visible on screen
  When the user clicks on a column name
  Then the rows are sorted in descending order for that column

Scenario: Second click on a sorted column reverses the order
  Given the analytics user has the table visible on screen
  And the rows are sorted in descending order for a column
  When the user clicks on the same column name
  Then the rows are sorted in ascending order for that column

Best Practices

One scenario, one behaviour

Each scenario should verify exactly one behaviour. Combining multiple assertions in a single scenario hides failures and makes debugging harder.

Third-person perspective

Write steps from the perspective of the user or system, not the tester.

❌ When I change the address
✅ When the user changes the address of the customer

No conjunctive steps

A When step should contain a single action.

❌ When the user changes the address and status
✅ Two separate When steps in two separate scenarios

Descriptive scenario titles

The title should describe the scenario and its objective clearly — not just name the action.

❌ Scenario: Modify address
✅ Scenario: Modify the address of an existing customer and verify the change is persisted

Parametrize with Scenario Outline

When the same behaviour applies across multiple data values, use Scenario Outline with an Examples table — not duplicate scenarios.

Scenario Outline: Modify the address of an existing customer to <address>
  Given there is a customer
  When the user changes the address of the customer to <address>
  Then the address of the customer is changed to <address>

  Examples:
    | address  |
    | Madrid   |
    | Arteixo  |

Acceptance Criteria in Practice

Acceptance criteria in BDD are written together with user stories. They are managed via a test management tool (XRay) directly connected to the project. The PO and QA work on them together during pre-refinement and refinement, ensuring they are:

Automatable
Traceable to the user story
Covering all relevant scenarios (happy path, edge cases, error paths)
Part of the regression suite from the moment they are written