Behaviour Driven Development is an increasingly popular Agile development practice that turns testing on its head. It turns automated acceptance testing from a verification activity, done once the development work is done, to a specification activity, with tester involvement starting from the word go.
In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to contribute much more to the successful outcomes of the project. We will see how collaboratively written acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are both well understood and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance tests. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress and release preparation reporting.
19. @wakaleo#bddinactionuk
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
20. @wakaleo#bddinactionuk
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
21. @wakaleo#bddinactionuk
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
22. @wakaleo#bddinactionuk
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
23. @wakaleo#bddinactionuk
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
24. @wakaleo#bddinactionuk
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
25. @wakaleo#bddinactionuk
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
26. @wakaleo#bddinactionuk
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
27. @wakaleo#bddinactionuk
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
28. @wakaleo#bddinactionuk
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
29. @wakaleo#bddinactionuk
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
30. @wakaleo#bddinactionuk
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
31. @wakaleo#bddinactionuk
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
32. @wakaleo#bddinactionuk
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
33. @wakaleo#bddinactionuk
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
34. @wakaleo#bddinactionuk
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
35. @wakaleo#bddinactionuk
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
36. @wakaleo#bddinactionuk
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
•Specifica8ons
are
elaborated
collabora8vely
•Specifica8ons
use
a
common
language
•Executable
specifica8ons
provide
fast
feedback
38. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Solves the wrong
problem well
39. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Solves the wrong
problem well
Solves the right
problem poorly
40. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Solves the wrong
problem well
Solves the right
problem poorly
41. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Slow to
change
Solves the wrong
problem well
Solves the right
problem poorly
42. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Hard to
maintain
Slow to
change
Solves the wrong
problem well
Solves the right
problem poorly
43. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
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
46. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
We
start
with
a
business
goal
“Increase
*cket
sales
by
5%
over
the
next
year
by
encouraging
travelers
to
fly
with
Flying
High
rather
than
with
a
rival
company.”
48. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
What
features
will
enable
us
to
deliver
this
goal?
FeaturesFeaturesFeatures
Earn
Frequent
Flyer
points
from
flights
49. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
What
features
will
enable
us
to
deliver
this
goal?
FeaturesFeaturesFeatures
Earn
Frequent
Flyer
points
from
flights
Earn
Frequent
Flyer
points
from
purchases
50. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
What
features
will
enable
us
to
deliver
this
goal?
FeaturesFeaturesFeatures
Earn
Frequent
Flyer
points
from
flights
Earn
Frequent
Flyer
points
from
purchases
View
Frequent
Flyer
account
balance
online
51. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal FeaturesFeaturesFeatures
We
use
conversa8ons
around
examples
to
build
up
our
understanding
of
these
features
FeaturesFeaturesExamples
52. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal FeaturesFeaturesFeatures
We
use
conversa8ons
around
examples
to
build
up
our
understanding
of
these
features
FeaturesFeaturesExamples
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
53. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal FeaturesFeaturesFeatures
We
use
conversa8ons
around
examples
to
build
up
our
understanding
of
these
features
FeaturesFeaturesExamples
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
“If
she
earns
300
points,
she
becomes
a
Silver
Frequent
Flyer
member”
54. @wakaleo#bddinactionuk
Increase ticket sales
revenue by 5%
Frequent Flyer
members
Call centre staff
Buy more tickets
Encourage
friends to join
Spend less time
on phone sales
Purchase flights with
redeemed miles
Purchase other goods
with redeemed miles
Facebook and Twitter
integration
Online sales
Why Who How What
Building software that matters
Techniques
like
Impact
Mapping
can
help
us
discuss
what
features
are
worth
building
56. @wakaleo#bddinactionuk
BDD - you don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
57. @wakaleo#bddinactionuk
BDD - you don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
58. @wakaleo#bddinactionuk
BDD - 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
60. @wakaleo#bddinactionuk
BDD - building a shared understanding
“Having
the
conversa/on
is
more
important
than
recording
the
conversa/on
is
more
important
than
automa/ng
the
conversa/on”
-‐
Liz
Keogh
62. @wakaleo#bddinactionuk
BDD - building a shared understanding
Story
bug
reports
Working
code boring
manual
tes*ng
WASTE
BA
Developer
TesterMany
teams
build
features
like
this
69. @wakaleo#bddinactionuk
BDD - building a shared understanding
A
liKle
collabora8on
goes
a
long
way
Shared
understanding
Story
Examples
Automated
acceptance
criteria
70. @wakaleo#bddinactionuk
BDD - building a shared understanding
A
liKle
collabora8on
goes
a
long
way
Working
code
and
Working
Automated
Acceptance
Tests
Shared
understanding
Story
Examples
Automated
acceptance
criteria
71. @wakaleo#bddinactionuk
BDD - building a shared understanding
A
liKle
collabora8on
goes
a
long
way
Working
code
and
Working
Automated
Acceptance
Tests
Exploratory
tes*ng,
usability
tes*ng...
Shared
understanding
Story
Examples
Automated
acceptance
criteria
72. @wakaleo#bddinactionuk
BDD - building a shared understanding
BA
and/or
product
owner
Tester Developer Automatable
Acceptance
Criteria
Shared
understanding
73. @wakaleo#bddinactionuk
BDD - building a shared understanding
BA
and/or
product
owner
Tester Developer Automatable
Acceptance
Criteria
Shared
understanding
“The
Three
Amigos”
83. @wakaleo#bddinactionuk
Discovering requirements through 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
”
84. @wakaleo#bddinactionuk
Discovering requirements through 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
107. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
A
star*ng
point
for
manual
tests
Illustrates
delivered
features
Func*onal
and
technical
documenta*on
Progress
repor*ng
130. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
do
we
plan
to
deliver?
What
has
been
done? What
is
in
progress
What
hasn’t
been
started
yet
131. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
do
we
plan
to
deliver?
What
has
been
done? What
is
in
progress
What
hasn’t
been
started
yet
How
many
automated
and
manual
tests
were
performed
134. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
stories
are
defined
for
this
feature?
How
many
stories
have
automated
acceptance
criteria?
135. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
stories
are
defined
for
this
feature?
How
many
stories
have
automated
acceptance
criteria?
What
acceptance
criteria
have
been
automated?