The document discusses Behavior Driven Development (BDD) as a collaborative approach that improves communication between business owners, analysts, developers, and testers. BDD emphasizes creating user-friendly scenarios to define requirements, automate acceptance criteria, and foster a shared understanding of project goals. It also outlines common pitfalls in BDD adoption and offers tips for testers to enhance collaboration and test quality.

1. Behaviour Driven Development
“It’s Testing, Jim, but not as we know it!”

2. John Ferguson Smart
Consultant
Trainer
Mentor
Author
Speaker
Coder
WelcomeWelcome
John Ferguson Smart
Consultant
Trainer
Mentor
Author
Speaker
Coder

3. Behaviour Driven Development
You keep using that term
I do not think it means what you think it means

4. You may have heard of it
A test automation tool?
Behaviour Driven Development

5. You may have heard of it
A different way to write user stories?
Behaviour Driven Development
Feature: Search by keyword
In order for buyers to find what they are looking for more efficiently
As a seller
I want buyers to be able to search for articles by keywords
Scenario: Search for articles by keyword
Given I want to buy a wool scarf
When I search for 'wool'
Then I should see only articles related to 'wool'
Scenario: Search by shop name
Given I want to see articles from a particular shop
When I search by shop for 'docksmith'
Then I should find 1 shop called 'docksmith'

6. You may have heard of it
Behaviour Driven Development
A way to collaborate better?

7. You may have heard of it
Behaviour Driven Development
a shared understanding
software that matters
Using examples

8. You may have heard of it
Behaviour Driven Development
Hunting out value
Automated Acceptance
Criteria
API and code design
boration
Building the software right
Building the right software
Living Documentation
BDD

9. The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell

10. The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
BDD in a nutshellBDD in a nutshellBDD in a nutshell

11. The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
• Specifications are elaborated collaboratively
• Specifications use a common language
• Executable specifications provide fast
BDD in a nutshellBDD in a nutshell

12. BDD in a nutshellBDD is about collaboration
“Having
the
conversa/on
is
more
important
than
recording
the
conversa/on
is
more
important
than
automa/ng
the
conversa/on”
-­‐
Liz
Keogh

13. BDD in a nutshellBDD is about collaboration
Story
bug reports
Working
code boring
manual
testing
WASTE
BA
Developer
Tester
Many teams build features like this…

14. BDD in a nutshellBDD is about collaboration
Working code
and
Working Automated
Acceptance Tests
Exploratory testing,
usability testing...
Shared
understanding
Story
Examples
Automated
acceptance
criteria
BDD teams focus on building a shared understanding

15. BDD in a nutshellBDD is about collaboration
BDD teams focus on building a shared understanding

16. BDD in a nutshellA typical BDD workflow

17. BDD in a nutshellA typical BDD workflow
Frequent Flyer Application
Goal: Encourage travellers to fly with Flying High airlines more often by allowing them to cumulate
Frequent Flyer points that they can spend on cheaper flights.
Goals
Earning points
from flights
Capabilities
Earning points
from spending
with partners
Viewing points
earned
Spending
points on
bookings
FeaturesViewing current points balance
View points needed to achieve
the next status level
Calculating points needed for
a given destination

18. BDD in a nutshellA typical BDD workflow
Calculating points needed for a given destination
As a traveller
I want to know how many points I need to go to a given destination
So that I can plan my next trip with Flying High Airlines
Feature
Acceptance Criteria
- Need 2 points per km
- Members can calculate points needed on their account home page
Acceptance
Criteria
Automated
Acceptance
Criteria

19. BDD in a nutshellA typical BDD workflow
Automated
Acceptance
Criteria
Automated
Acceptance
Tests

20. BDD in a nutshellA typical BDD workflow
Automated
Acceptance
Tests
Application Code
Low level specifications

21. BDD in a nutshellBDD Living Documentation
Meaningful feedback on what requirements
have (and have not) been delivered
What about the reports?

22. BDD in a nutshellBDD Living Documentation
Descriptions of each feature with an example
of how it behaves
What about the reports?

23. BDD in a nutshellBDD Living Documentation
What about the reports?
…complete with illustrations

24. BDD in a nutshellBDD Living Documentation
What about the reports?
Verify how each feature was tested

25. BDD in a nutshellBDD Living Documentation
What about the reports?
… and document releases

26. BDD Adoption Challenges
“There might be more to this than we thought”

27. BDD in a nutshell5 BDD Adoption Gotchas
1
2
3
4
The business analyst writes the scenarios and
then gives them to the other team members.
1) “I did it my way”

28. BDD in a nutshell5 BDD Adoption Gotchas
1
2
3
4
The tester writes the scenarios at the end to
implement an automated test suite.
2) “The Tester’s Tool”

29. BDD in a nutshell5 BDD Adoption Gotchas
1
2
3
4
5
The “Three Amigos” sessions don’t result in
usable scenarios, so the developer invents them
3) “The 3 amigos coffee club”

30. BDD in a nutshell5 BDD Adoption Gotchas
1
2
3
4
5
The scenarios are too UI-centric or detail-focused,
and neglect to express the core business value.
4) “The forest and the trees”

31. BDD in a nutshell5 BDD Adoption Gotchas
5) “The BDD Test Scribe”
1
2
3
4
The automated tester does not collaborate with the
developers, resulting in slow and fragile acceptance tests

32. BDD in a nutshell5 BDD Tips for Testers
1) Team up with the developers

33. BDD in a nutshell5 BDD Tips for Testers
Business Rules
Business Flow
Page/Component
interactions
Page/Component
details
2) Use layers

34. BDD in a nutshell5 BDD Tips for Testers
3)Prefer non-UI tests where possible

35. BDD in a nutshell5 BDD Tips for Testers
4) Treat your test code like production code

36. BDD in a nutshell5 BDD Tips for Testers
5) Know when not to automate
This slide is left intentionally blank

37. 3 BDD Tester Wins
Deeper participation in feature delivery

38. 3 BDD Tester Wins
Higher quality automated tests

39. 3 BDD Tester Wins
More time for high-quality manual testing

40. Any questions?
“It’s Testing, Jim, but not as we know it!”

41. John Ferguson Smart
Consultant
Trainer
Mentor
Author
Speaker
Coder
WelcomeWelcome
John Ferguson Smart
Consultant
Trainer
Mentor
Author
Speaker
Coder