Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This talk focuses on answering two questions; What are the ideal conditions when teams should adopt it? How to adopt it the right way ?

1. Copyright © 2015 SolutionsIQ Inc. All rights reserved.
6801 185th Ave NE, Suite 200
Redmond, WA 98052
solutionsiq.com
1.800.235.4091
When to Embrace Behavior Driven
development ?
How to adopt it the right way?
PREPARED BY
Ranjith Tharayil
Agile Coach
SolutionsIQ

2. What the hell is this?
2

3. BDD is a second-generation, outside-in, pull-based,
multiple-stakeholder, multiple-scale, high-automation,
agile methodology. It describes a cycle of interactions with
well-defined outputs, resulting in the delivery of working,
tested software that matters.
“
”
3
Dan North

4. Not again , Stop the crap we have seen this
4

5. The BDD Philosophy : how can we collaborate better ?
5
Product Owner
Developers Quality Assurance
Production Support
Business

6. The BDD school of thought ,Outside in
6
Spec
Test
Code
Outside in

7. The flow
7
N-1 N N+1
» Sprints
Spec
By
example
» Sprint planning
» Pull only those with spec ready» Three Amigo
Meetings
» BA ,PO
» Developers
» QA
» Production Support
» Any one who could
contribute in scenario
identification
• Disciplined delivery
• Working agreements
• DOR
• DOD
• Less risk of failure

8. No Comments :S
8

9. Doing BDD vs Adopting BDD
9
Do BDD
for
1567

10. BDD Myths
10
• Myth 1: BDD requires a framework or tool
• Myth 2 : BDD is about testing
• Myth 3: BDD has to be done top-down

11. • “Step Away from the Tools”
• “BDD isn’t about the tools.”
<Footer Content: Presentation Title, Partner Name, Other> 11
Liz Keogh
Myth 1: BDD requires a framework or tool

12. • #BDD supports collaboration. If u can’t
collaborate please don’t try using Cucumber as
test automation
<Footer Content: Presentation Title, Partner Name, Other> 12
Myth 2 : BDD is about testing
Seb Rose

13. In fact, BDD isn’t even really about testing. It’s just
a way of capturing those conversations which
happens to provide some tests, and lifts some of
the burden on the testers. If you want to run
additional performance tests, exploratory tests, or
even record some tests, it doesn’t have to come
under the BDD banner. It’s perfectly OK to do
BDD and test things as well.
13
Liz Keogh
Myth 2 : BDD is about testing

14. +Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
14
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then check that the account is debited
And check that cash is dispensed
And check that the card is returned
And check that nothing happens that shouldn’t
happen and everything else happens that should
happen for all variations of this scenario and all
possible states of the ATM and all possible states of
the customer’s account and all possible states of
the rest of the database and all possible states of
the system as a whole, and anything happening in
the cloud that should not matter but might matter.
James Bach
Myth 2 : BDD is about testing

15. Test iceberg
15

16. 16
“BDD doesn't come with BRAINS kindly use
yours”

17. The Gap
17

18. Complexity
18

19. <Footer Content: Presentation Title, Partner Name, Other> 19
Lets play a game

20. 10 level tower of cards
20

21. 21

22. BDD Workshop, Society General 22

23. BDD Workshop, Society General 23

24. Complexity
24

25. How to measure complexity
25
Points Complexity Description
1 Just about everyone in the world has done this
2 Lots of people have done this, including someone on our team.
3 Someone in our company has done this, or we have access to expertise
4 Someone in the world did this, but not in our organization (and probably
at a competitor)
5 Nobody in the world has ever done this before
Second Order ignorance
We say second order of ignorance exist if “when I don't know that I
don't know something”.
Liz Keogh

26. Scenario Identification, 3 key pillars
Functional:
-Happy path
-Sad path
-Exceptional
Constraints
Quality
attributes
26

27. Join Coffee Talk
In your town!
In Chennai
on May 28th
Coming Up
Webinar – DevOps
Testing Strategy
www.agilecoffeetalk.com
www.meetup.com/
Agile-Technical-Group/
Agile Technical Group
Bangalore
19th and 20th
August 2016
www.xpconference.com
XP Conference 2016
Bangalore
19th May 2016
www.solutionsiq.in/
leadership-meet-2016/
Agile Leadership
Meet
Questions?
You may be interested
in these events

28. 28
“BDD doesn't come with BRAINS kindly use
yours”

29. 29
Extras

30. BDD for maintenance projects ?
• Lots of legacy code 
• Enhancements
• Defect fix
• Production issues
30

31. Adapting BDD for software maintenance projects
using the “dEep” model.
we can categories the type of work into 4 different types .
31
d , defects
E ,Complex Enhancements
e ,Simple Enhancements
p , urgent production issues

32. E , Complex Enhancements
• follow classical BDD style:
• 3 Amigo meetings , trigger conversations
• Capture Scenarios , specification by example
• pull based
• TDD strategy : inner cycle
• Check if E2E test is required
• working agreements ,DOR ,DOD
• highly disciplined
• Full team participation
32

33. e ,Smaller Enhancements
• Skip 3 Amigo meetings
• cover the module with scenarios based test
• Express new requirements in the form of a scenario
• get the spec reviewed by BA/PO , dev ,QA .
• Highly pragmatic approach ,
• (need basis ) UT or E2E test
• test first approach or TDD
33

34. d, Defects
• d came to existence because there was a hole in your test pyramid
• fix the hole that caused the issue ,may be a test or two , be pragmatic
• fix the code , again test first strategy
34

35. p, urgent production issues
• fix the code first & deploy
• put a card in your back log to fix the hole in the test pyramid which caused
the issues
• Test last strategy 
35

36. 36
BDD in a nut shell
I have shamelessly copied this pic from Rachel's blog

37. Key Question
37
I have shamelessly copied this pic from Naresh Jain PPT

38. The old school of thought , Inside Out
Test
Code
38
Spec
Inside Out