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 that the client actually needs. In this talk, we will discuss what BDD is about, its benefits, and how it affects teams and processes. We will discuss two case studies where BDD practices have been successfully introduced, including the benefits gained and challenges met. We will see how much benefit was gained when BDD was integrated into the broader development infrastructure, including issue tracking systems, requirements management, and project reporting. We will also see how BDD can be applied to all levels of the development process, from requirements down to low-level coding. We will also look at the principle BDD tools available that can help teams implement executable specifications, BDD-style test automation, and living documentation effectively. Some of the tools discussed will include JBehave, Cucumber, Specflow, Jasmine and Spock. We will also look at two case studies where BDD practices have been successfully integrated into several projects in large government and financial organizations. Teams that adopted BDD effectively benefited from significantly lower defect rates, much earlier discovery of errors and inconsistencies in the requirements, and better overall communication and collaboration within the team. However, practicing BDD does involve a significant change in mind-set compared to more traditional approaches, a different collaboration model between team members, and a high degree of stakeholder by-in and engagement, all of which should not be underestimated. We will discuss how the teams managed these various challenges during their BDD adoption story.

1. John
Ferguson
Smart
BDD In Action
Principles, practices and real-world applications

2. John Ferguson Smart
Consultant
Trainer
Mentor
Author
Speaker
Coder

3. There are only two problems
in software development
1) Building the software wrong
2) Building the wrong software

4. BDD
Feature Injection
Automated Acceptance
Criteria
API and code design
Collaboration
Building the software right
Building the right software
Living Documentation
What
is
Behaviour
Driven
Development

5. Behaviour
Driven
Development
is…
Conversa>on
Focused

6. Story
bug
reports
Working
code boring
manual
tes>ng
WASTE
BA
Developer
Tester
Many teams build features like this…
Conversa>on
Focused

7. …but a little cooperation goes a long way…
Working
code
and
Working
Automated
Acceptance
Tests Exploratory
tes>ng,
usability
tes>ng...
Shared
understanding
Story
Examples
Automated
acceptance
criteria
Conversa>on
Focused

8. We call this “The Three Amigos”
BA
and/or
product
owner
Tester Developer Automatable
Acceptance
Criteria
Shared
understanding
Conversa>on
Focused

9. We call this “The Three Amigos”
Conversa>on
Focused

10. Behaviour
Driven
Development
is…
Example-­‐based

11. Example-­‐based

12. Behaviour
Driven
Development
is…
Value-­‐Driven

13. Behaviour
Driven
Development
is…
Outside-­‐in
Outside
In

14. Behaviour
Driven
Development
is…
Executable
Specifica>ons

15. More value faster
Delivery
Time
Tradi>onal
Using
BDD
31%
faster
delivery
Behaviour
Driven
Development
is…

16. Higher Quality
Defect
Rate
Tradi>onal
Using
BDD
4
>mes
less
defects
Behaviour
Driven
Development
is…

17. Scenario
Step
Defini>ons
Low
level
specifica>ons
(aka
“unit
tests”)
Applica>on
Code
BDD
guides
development

18. Oh, the things you can learn…
BDD
guides
development

19. What
would
we
like
the
API
to
look
like?
BDD
guides
development

20. Then
write
low-­‐level
specifica>ons
for
the
code
BDD
guides
development

21. Then
write
low-­‐level
specifica>ons
for
the
code
BDD
guides
development

22. “Every class is an API for
someone”

23. BDD
in
Ac>on
-­‐
some
real-­‐world
examples

24. Mission
cri;cal
legacy
web
applica;on
Case
1
-­‐
an
e-­‐commerce
web
site
Frequent
small
changes
Business
requires
fast
release
cycle
Background

25. Case
1
-­‐
an
e-­‐commerce
web
site
Approach
“BDD-­‐style”
regression
tests
High
communica;on
value
Designed
for
ease
of
maintenance
Illustrate
key
business
scenarios
Minimum
ini;al
impact
on
team

26. “BDD-­‐style”
regression
tests
Case
1
-­‐
an
e-­‐commerce
web
site
Approach

27. Case
1
-­‐
an
e-­‐commerce
web
site
Outcomes
Living
documenta;on

28. Case
1
-­‐
an
e-­‐commerce
web
site
Outcomes
Living
documenta;on

29. Case
1
-­‐
an
e-­‐commerce
web
site
Outcomes
Living
documenta;on

30. New
large-­‐scale
project
Case
2
-­‐
a
large
financial
ins>tu>on
7
years,
2
Scrum
teams
Conserva;ve
organisa;on
Background
Regulatory
and
traceability

31. Approach
Full
team-­‐wide
BDD
adop;on
Test
automa;on
for
(almost)
all
acceptance
criteria
Tight
integra;on
with
JIRA
for
traceability
“Three-­‐amigos”
sessions
to
refine
acceptance
criteria
High
ini;al
impact
on
team
Case
2
-­‐
a
large
financial
ins>tu>on

32. Approach
Case
2
-­‐
a
large
financial
ins>tu>on
Stories
Features
Capabilities
Goals
Requirements
organised
by
feature
and
capability

33. Approach
Case
2
-­‐
a
large
financial
ins>tu>on
Stories
Features
Capabilities
Goals
Requirements
managed
in
JIRA

34. Approach
Case
2
-­‐
a
large
financial
ins>tu>on
Story
Examples
Automated
acceptance
criteria
“Three
amigos”
sessions
refine
acceptance
criteria

35. Approach
Case
2
-­‐
a
large
financial
ins>tu>on
Acceptance
Criteria
map
back
to
JIRA

36. Approach
Case
2
-­‐
a
large
financial
ins>tu>on
Stories
Features
Capabilities
Goals
Manual
test
cases
managed
in
Zephyr

37. Approach
Case
2
-­‐
a
large
financial
ins>tu>on
Stories
Features
Capabilities
Goals
Automated
and
Manual
Tests
produce
Living
Documenta;on
Acceptance Criteria

38. Approach
Case
2
-­‐
a
large
financial
ins>tu>on
Releases
organised
in
JIRA

39. Outcomes
Case
2
-­‐
a
large
financial
ins>tu>on
Code
coverage
when
from
8%
to
80+%
Very
liZle
rework
to
delivered
features
Well
documented
APIs
Automated
tests
used
to
demonstrate
features
Happy
teams!

40. BDD
involves
a
major
culture
change
BDD
Adop>on
-­‐
Tips
and
Tricks
Don’t
skimp
on
training!
Put
care
into
your
test
automa;on
Need
tester
and
BA
buy-­‐in

41. References
http://jbehave.org
BDD in Java
http://thucydides.info
Living Documentation
Issue tracking and Agile
project management
Manual test case
management in JIRA

42. Thank you!
John Ferguson Smart
john.smart@wakaleo.com
wakaleo
http://www.wakaleo.com