Good software is not only error-free software, but more importantly software that does what the customer needs. This seems obvious, but in reality, the communication gap between business professionals and software development teams still causes a loss of time, money and good will.
Behaviour Driven Development (BDD) tries to bridge the gap between the different stakeholders.
At UCLL, we started a research project to promote this methodology with Belgian companies. We are strong believers and try to find out why BDD it is not more widely used. The goal is to develop an ‘implementation model’, a set of best practices, do’s and don’ts, helping companies to successfully distill high-quality specifications that can guide the development and testing process from the start of a project.
We would love to share our experiences, talk about the problems we come across, and discuss the way we handle them.
3. Project details - FirstTimeRight
• Funded by the Flemish government
• Co-funded by steering committee members
• Duration: 2 years (2018-2020)
Elke Steegmans
Project manager
Mieke Kemme
Quality manager
Wannes Fransen
Developer
Nicolas Lauwereys
Developer
Frederik Thielemans
Functional Analyst
David Vandenbroeck
Functional Analyst
5. Project details - FirstTimeRight
Problem
Existence of a communication gap between the technical and the
nontechnical, due to ambiguities and misunderstandings that exist within
the team and between the customer.
Solution
Behaviour-Driven Development
9. The core of BDD
• Communication!
• Ubiquitous language
• Closing the communication gap
▪ So that technical experts can communicate with domain experts and vice versa
10. Solution
Bridging the communication gap between business and IT with
Behaviour-Driven Development.
Core benefits of Behaviour-Driven Development:
#1 Enabling communication
#2 Enabling collaboration
#3 Creating a shared understanding
11. #1 Enabling communication
Between technical and nontechnical project members
• Exemplifying expected behaviour in a domain specific language
▪ Example mapping
▪ Feature mapping
13. #2 Enabling collaboration
Between technical and nontechnical project members
• Coincides with communication
• Documenting in a ubiquitous language
▪ Gherkin
• Feedback
14. HOW? – Phase 2: Formulation
• Writing scenario’s in Gherkin (GWT) by Tester + Developer
• Review by PO/client
#2 Enabling collaboration
Given some context
When some action is carried out
Then a particular set of observable
consequences should obtain
15. #3 Creating a shared understanding
Between technical and nontechnical project members
16. #3 Creating a shared understanding
Between technical and nontechnical project members
23. Beware of misconceptions!
Source: https://blog.rapid7.com/2017/06/19/what-is-bdd-testing-practical-examples-of-behavior-driven-development-testing/
24. Beware of misconceptions!
Source: https://blog.rapid7.com/2017/06/19/what-is-bdd-testing-practical-examples-of-behavior-driven-development-testing/
TDD
TEST
27. Beware of misconceptions!
Source: https://enginiety.com/knowledge/behaviour-driven-development-in-automated-tests
1 - users can search
2 - users can add to cart
3 - description is displayed (UI)
4 - Price is calculated
28. Beware of misconceptions!
Source: https://enginiety.com/knowledge/behaviour-driven-development-in-automated-tests
Given David has added Paris as a destination
When he adds the destination to his shopping cart
Then Paris should be added to his shopping cart
30. Good examples?
Agile Alliance
• https://www.agilealliance.org/glossary/bdd
INVIQA
• The beginner's guide to BDD (behaviour-driven development)
• https://inviqa.com/blog/bdd-guide
Tweakers
• BDD op Tweakers (Dutch) – Hoe Tweakers Behat integreerde
• https://tweakers.net/reviews/6936/bdd-op-tweakers-hoe-tweakers-
behat-integreerde.html
31. Barriers
What barriers do we need to overcome for a successful adoption of
BDD?
• Learning curve
▪ Correct understanding is essential
▪ Avoid alienating team members from BDD!
• Dedicated team members
▪ Tester + Developer + Product owner
• Time
• Resources
• Business client’s support
33. BDD-DNA Matrix
Why the BDD-DNA matrix?
• BDD is not just an
all-or-nothing
solution
• In practice, adopting
BDD as intended is
incredibly difficult
• Identify how you use
BDD and how you
can improve your
workflow in order to
maximise your ROI
34. Three phases of
BDD
#1 Discovery
#2 Formulation
#3 Automation
Always in a consecutive order!
Each of these phases have their own
challenges, making it very difficult to
master them all at once.
Which is why we propose a custom
approach to adopting BDD, based on
three different levels of maturity.
PHASE 1
Discovering the
unknown
PHASE 2
Validating the
shared
understanding
PHASE 3
Creating a living
documentation
35. The ideal BDD workflow ★★★
#1 Discovery
• Involve at least the 3 amigos
• Use example mapping sessions
#2 Formulation
• Write decent scenario titles
• Use DSL
• Write in pair
• Have the scenarios reviewed
#3 Automation
• Full stack automation
• Create living documentation
DSL = domain-specific language
36. The undercover BDD workflow ★★
#1 Discovery
• Regular (informal) team meetings
• Ask “what if?”-questions based on
your own pre-defined examples
• without mentioning BDD
#2 Formulation
• Write decent scenario titles
• Use DSL
• Write scenarios on your own or in
pair
#3 Automation
• Automate scenarios in E2E-tests
• Documentation
DSL = domain-specific language
37. The DIY BDD workflow ★
#1 Discovery
• Prepare and list all rules
• Clarify your rules with examples
• On your own..
#2 Formulation
• Write decent scenario titles
• Use DSL
#3 Automation
• Manual testing only
• Documentation
DSL = domain-specific language
38. Three levels of maturity
The lower the level of maturity is for the
Discovery phase, the lower the effort in the
Formulation phase should be
39. Three levels of maturity
The lower the level of maturity is for the
Formulation phase, the lower the effort in
the Automation phase should be
40. Three levels of maturity
In order to advance to a
next phase, at least a
minimal amount of effort
(=lowest maturity) must
be reached.
DO NOT SKIP A PHASE!
43. The custom BDD-DNA matrix:
• Allows for a smoother transition towards BDD
• Guards following a correct workflow
• Creates awareness of what BDD actually is
• Shows that BDD is not just an all-or-nothing solution
▪ The BDD matrix defines and highlights important processes
▪ Choose what fits your team
• Maximises benefits with a minimal amount of effort
Outcome
45. Solution
But… How do I convince the entire team of the value of BDD???
• Sometimes it’s just all about the ROI
• BDD changes the way we work
• But, if BDD has been adopted correctly, it will:
▪ reduce context switching and rework
▪ increase productivity (by all project members)
▪ Removes the need for translating and explaining code
▪ Provide reliable living documentation
▪ Automated tests
▪ Regression tests that focus on behaviours
48. Solution
Bridging the communication gap between business and IT with
Behaviour-Driven Development.
Goal of Behaviour-Driven Development:
#1 Enabling communication
#2 Enabling collaboration
#3 Creating a shared understanding