Behaviour Driven Development is an increasingly popular Agile practice that turns testing on its head, and involves a major shift in the role testers play in a project. Although popularly associated with automated acceptance testing and tools like Cucumber, BDD actually has much broader applications. In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to tangibly contribute much more to the successful outcomes of the project. We will see how collaboratively discussing and defining acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are well understood, testable, and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance criteria, that free testers to do more productive testing tasks such as exploratory testing. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress, product documentation and release preparation reporting.
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
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
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