What is BDD and

Why ?
What is BDD ?

BDD is a software development process for teams to create

simple scenarios on how an application should behave from
the end user's perspective. The goal of implementing BDD
testing is to improve collaboration between stakeholders,
such as developers, testers, product managers, and business
analysts.
Why BDD ?

● Communication: Software development is not about the software

engineers or developers only: there are Testers, PMs, POs, DevOps, and
other stakeholders.

● High Visibility: BDD is explained using simple language. By using a

simple language understood by all, everyone gets strong visibility into
the project’s progression

● End User Satisfaction: By focusing on the business’ needs, you get

satisfied users, and that implies a happy business.
The need for BDD
The Core of BDD: The Story !!!

Each features is captured as a “Story”, which defines the

scope of the feature along with its acceptance criteria.

BDD “Story” = Narrative (User Story) + Acceptance Criteria (Scenarios)

User Stories

Title of the Story

As a <role>,

I want <want>,

So that <benefit>.
User Stories

Customer withdraws cash

As a customer,

I want to withdraw cash from an ATM,

So that I don’t have to wait in line at the bank.

The acceptance criteria: Scenarios

+ A User Story’s behaviour is its acceptance

criteria.
+ Acceptance criteria define the scope of the
behaviour.
+ Acceptance criteria give us a shared definition
of done.
The acceptance criteria: Scenarios

Scenario title
Given <context>,

When <event>,

Then <outcome>.
The acceptance criteria: Scenarios

Scenario: Account is in credit

Given the account is in credit
and the card is valid

and the dispenser contain cash

When the customer requests cash

Then ensure the account is debited

and ensure cash is dispensed

and ensure the card is returned

The acceptance criteria: Scenarios

Scenario: Account is overdrawn past the overdraft limit

Given the account is overdrawn
and the card is valid

When the customer requests cash

Then ensure a rejection message is displayed

and ensure cash is not dispensed

and ensure the card is returned

The acceptance criteria: Scenarios
The power of scenarios

Scenarios

Test Cases

Acceptance criteria
A good story

1. The title should describe an activity

2. The narrative should include a role, a feature and a benefit
3. The scenario title should say what’s different
4. The scenario should be described in terms of Givens, Events and
Outcomes
5. The Givens should define all of, and no more than, the required
context
6. The Event should describe the feature
 QA steps to lead BDD
- Select scenarios for core product features rather than the latest sprint stories, so that the
code base will be populated with the most basic, useful steps

- Once the automation code reaches a “critical mass” for step reusability, QA can then
proactively classify new test scenarios as automated or manual.

- Automated tests become easier and easier to write, giving QA more time to be exploratory
with manual testing. Ideally, all manual testing would become exploratory

- At this point, all Gherkin steps would be in the automation code only, so set up a tool like
Pickles to expose the steps to all team members as living documentation.

- QA should then schedule Three Amigos meetings with PM and DEV to proactively discuss
user story expectations. In those meetings, QA should start demonstrating how to write
acceptance criteria in Gherkin, which then expedites testing.
QA Lead BDD
QA Lead BDD
QA Lead BDD
Happy BDD !