Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them
14. BDD
Hunting out value Automated Acceptance
Criteria
Collaboration
Building the right software
So what is this BDD thing?
15. BDD
Hunting out value Automated Acceptance
Criteria
API and code design
Collaboration
Building the right software
So what is this BDD thing?
16. BDD
Hunting out value Automated Acceptance
Criteria
API and code design
Collaboration
Building the software right
Building the right software
So what is this BDD thing?
17. BDD
Hunting out value Automated Acceptance
Criteria
API and code design
Collaboration
Building the software right
Building the right software
Living Documentation
So what is this BDD thing?
18. 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
BDD in a nutshell
A traditional development process
19. 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
BDD in a nutshell
A traditional development process
20. 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
BDD in a nutshell
A traditional development process
21. 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
BDD in a nutshell
A traditional development process
22. 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
BDD in a nutshell
A traditional development process
23. 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
BDD in a nutshell
A traditional development process
24. 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
BDD in a nutshell
A traditional development process
25. 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
BDD in a nutshell
A traditional development process
26. 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
BDD in a nutshell
A traditional development process
27. 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
BDD in a nutshell
A traditional development process
28. 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
BDD in a nutshell
A traditional development process
29. 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"
BDD in a nutshell
A BDD development process
30. 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"
BDD in a nutshell
A BDD development process
31. 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"
BDD in a nutshell
A BDD development process
32. 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"
BDD in a nutshell
A BDD development process
33. 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"
BDD in a nutshell
A BDD development process
34. 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"
BDD in a nutshell
A BDD development process
35. 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"
•Specifica8ons
are
elaborated
collabora8vely
•Specifica8ons
use
a
common
language
•Executable
specifica8ons
provide
fast
feedback
BDD in a nutshell
37. “software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmanship
Solves the wrong
problem well
38. “software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmanship
Solves the wrong
problem well
Solves the right
problem poorly
39. “software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Solves the wrong
problem well
Solves the right
problem poorly
40. “software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Slow to
change
Solves the wrong
problem well
Solves the right
problem poorly
41. “software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Hard to
maintain
Slow to
change
Solves the wrong
problem well
Solves the right
problem poorly
42. “software that matters”
Building the
thing right
Building the
right thingWhat
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Hard to
maintain
Slow to
change
Does what the business needs
Reliable
Easy to maintain
Solves the wrong
problem well
Solves the right
problem poorly
43. You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
44. You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
45. You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
46. You don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
•Our
ignorance
decreases
over
8me
•It
does
not
decrease
at
a
linear
rate
•It
does
not
always
decrease
in
a
predictable
way
55. Business
Goal
Business
Goal
Business
Goal
“software that matters”
We
use
conversa8ons
around
examples
to
build
up
our
understanding
of
these
features
FeaturesFeaturesFeatures FeaturesFeaturesExamples
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
“If
she
earns
300
points,
she
becomes
a
Silver
Frequent
Flyer
member”
58. “Using examples”
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
•Explore
requirements
•Discover
what
we
don’t
know
•Clarify
ambigui8es
•Iden8fy
assump8ons
and
misunderstandings
59. “Using examples”
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
“If
she
earns
300
points,
she
becomes
a
Silver
Frequent
Flyer
member”
•Explore
requirements
•Discover
what
we
don’t
know
•Clarify
ambigui8es
•Iden8fy
assump8ons
and
misunderstandings
60. “Using examples”
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
“If
she
earns
300
points,
she
becomes
a
Silver
Frequent
Flyer
member”
“If
I
ask
for
the
details
about
the
flight
FH-‐102,
I
should
see
that
it
is
a
Sydney
to
Hong
Kong
flight
that
leaves
at
11:55pm
”
•Explore
requirements
•Discover
what
we
don’t
know
•Clarify
ambigui8es
•Iden8fy
assump8ons
and
misunderstandings
69. “Having
the
conversa/on
is
more
important
than
recording
the
conversa/on
is
more
important
than
automa/ng
the
conversa/on”
-‐
Liz
Keogh
“a shared understanding”
73. Story
Working
code boring
manual
tes5ng
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
74. Story
bug
reports
Working
code boring
manual
tes5ng
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
75. Story
bug
reports
Working
code boring
manual
tes5ng
WASTE
BA
Developer
Tester
Many teams build features like this…
“a shared understanding”
76. …but a little cooperation goes a long way…
Story
“a shared understanding”
77. …but a little cooperation goes a long way…
Story
“a shared understanding”
78. …but a little cooperation goes a long way…
Story
“a shared understanding”
79. …but a little cooperation goes a long way…
Story
“a shared understanding”
80. …but a little cooperation goes a long way…
Story
Examples
“a shared understanding”
81. …but a little cooperation goes a long way…
Story
Examples
Automated
acceptance
criteria
“a shared understanding”
82. …but a little cooperation goes a long way…
Shared
understanding
Story
Examples
Automated
acceptance
criteria
“a shared understanding”
83. …but a little cooperation goes a long way…
Working
code
and
Working
Automated
Acceptance
Tests
Shared
understanding
Story
Examples
Automated
acceptance
criteria
“a shared understanding”
84. …but a little cooperation goes a long way…
Working
code
and
Working
Automated
Acceptance
Tests Exploratory
tes5ng,
usability
tes5ng...
Shared
understanding
Story
Examples
Automated
acceptance
criteria
“a shared understanding”
85. We call this “The Three Amigos”
BA
and/or
product
owner
Tester Developer Automatable
Acceptance
Criteria
Shared
understanding
“a shared understanding”
86. We call this “The Three Amigos”
“a shared understanding”
87. We call this “The Three Amigos”
“a shared understanding”
88. We call this “The Three Amigos”
“a shared understanding”
89. We call this “The Three Amigos”
“a shared understanding”
90. We call this “The Three Amigos”
“a shared understanding”
116. Feature Coverage
What
stories
are
defined
for
this
feature?
How
many
stories
have
automated
acceptance
criteria?
What
acceptance
criteria
have
been
automated?
118. Business
Goal
Business
Goal
Business
Goal
We
can
automate
these
examples
in
the
form
of
“executable
specifica8ons”
FeaturesFeaturesFeatures FeaturesFeaturesExamples
Low level
specifications
Low level
specifications
Low level
specifications
Executable
specifications
“building the software right”
119. Business
Goal
Business
Goal
Business
Goal
We
can
automate
these
examples
in
the
form
of
“executable
specifica8ons”
FeaturesFeaturesFeatures FeaturesFeaturesExamples
Low level
specifications
Low level
specifications
Low level
specifications
Executable
specifications
“building the software right”
120. Business
Goal
Business
Goal
Business
Goal
We
can
automate
these
examples
in
the
form
of
“executable
specifica8ons”
FeaturesFeaturesFeatures FeaturesFeaturesExamples
Low level
specifications
Low level
specifications
Low level
specifications
Executable
specifications
“building the software right”
121. Business
Goal
Business
Goal
Business
Goal
We
use
low-‐level
BDD
or
TDD
tools
to
define
the
behavior
of
components,
classes
etc.
FeaturesFeaturesFeatures FeaturesFeaturesExamples
Low level
specifications
Low level
specifications
Low level
specifications
Executable
specifications
“building the software right”
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
122. Business
Goal
Business
Goal
Business
Goal
We
use
low-‐level
BDD
or
TDD
tools
to
define
the
behavior
of
components,
classes
etc.
FeaturesFeaturesFeatures FeaturesFeaturesExamples
Low level
specifications
Low level
specifications
Low level
specifications
Executable
specifications
spock
RSpec
“building the software right”
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
123. Business
Goal
Business
Goal
Business
Goal
We
use
low-‐level
BDD
or
TDD
tools
to
define
the
behavior
of
components,
classes
etc.
FeaturesFeaturesFeatures FeaturesFeaturesExamples
Low level
specifications
Low level
specifications
Low level
specifications
Executable
specifications
spock
RSpec
“building the software right”
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
Low level
specifications
150. BDD
requires
high
business
engagement
and
collabora8on
Adoption challenges
151. BDD
works
best
in
an
Agile
or
Itera8ve
context
Adoption challenges
152. BDD
does
not
work
well
in
a
silo
Adoption challenges
153. Adoption challenges
Skill
and
prac,ce
required:
•Wri,ng
good
scenarios
takes
prac,ce
•Poorly
wri:en
tests
can
lead
to
higher
test-‐maintenance
costs
•Need
to
treat
test
automa,on
code
like
produc,on
code