An introduction to BDD talk delivered at CSI, Goa Chapter convention on Feb 23, 2013

1. Behavior Driven Development
Ajay Danait
Global Agile Strategist
Stixis Technologies, Bangalore

2. Co-Learning (Collaborative Learning)
 Cross Functional Behavior (10 mins)
 Evolution of Software Development Process (15 mins)
 Behavior Driven Development (BDD) Concept (10 mins)
 Behavior Driven Development (BDD) Semantics (15 mins)
 Q & A (10 mins)

3. Quick Survey
While doing software
development, who do you think
like ...
Like a …
Plumber, Carpenter, Sculptor, Artist,
Blacksmith, Hairdresser, Firefighter,
Scientist, Archaeologist, Author, Typist

4. Not Designations … But Roles
Switch Caps Not Wear Crowns
• Architect
• Artist
• Craftsman
• Planner
• Team Player
• Critic
• Engineer

5. Team Organization and Governance
Traditional Team Hierarchy (Crowns) vs. Cross-Functional Roles (Caps)
Project Leadership
System
Architecture
Tech Architect Test Architect
Test Business
Creation Analysis
Data
Tech Lead Test Lead
Architect
Facilitator
Leader
Designer Test Analyst Guide
Test Coach Project
Automation Management
Automation Tester
Developer
Build &
Application
Business Release
Development
Analyst Management
Crowns Caps
 Creates and widens gap between people  Swapped depending on situations
 Restricts knowledge sharing  Increase sense of collective ownership
 Builds up power distance  Rotation of responsibilities improves knowledge sharing
 Steep learning curve for increase in maturity  Open culture within the team

6. Quick Opinion
When do you say a software project has
"failed" ?

7. Failure symptoms / Failure causes
Software delivered very late
... costed way more
... does the wrong thing
... unstable in production, crashes a lot
... code change breaks functionality
... new version cannot be released very often

8. Traditional Software Delivery Process
Why Do We Do This ?

9. Inheriting Management Style from Traditional Industries
 Fredrick Taylor  Edwards Deming / Taiichi Ohno
 Taylorism (Scientific Management)  Deming Cycle / Lean Thinking
(Work Management separation) (PDCA-Plan-Do-Check(Study)-Act)
 Top Down
 People need to be “managed”,  Bottom Up
“controlled”, “monitored”.  People want to do a good job and take
 Work needs to be made simple for pride in creativity.
them or they will make mistakes. The  People respond well to an encouraging
people downstream are increasingly environment of freedom and trust and
dumb, pluggable / replaced. So, all the hence produce better results.
“smartness” needed is loaded upfront
in the form of “well-documented  People stress a lot on gaining
artifacts” – requirements, designs, knowledge in the long term and improve
user acceptance tests. their skills based on collaboration and
apprenticeship.
 Hence, there should be a proper
knowledge transfer “handover”
mechanism to make sure no data is
lost in translation.
 Also to “verify” based on documented
evidence whether there are mistakes
in the work that they do.

10. Cost Of Change

11. Cost of Change from Traditional Industries
 Lack of trust downstream
 So we hedge
 Detailed functional requirements
 Big Design Up Front
 Detailed UAT
 Detailed Project Plan using Work Breakdown Structure until Task
level
 Discovering a defect / unexpected behavior
 Causes increase in change and hence cost
 To prevent this, we hedge with the phased process
 We hedged so much to prevent high cost of change
that we added steps that increase cost of change.

12. Cause-Effect Cause

13. Software Practices Inherited
• V-Model Development Process
• Upfront Detailed Planning
• Fixed Scope Requirements (No changes)
• Big Design Up Front
• Hard Code (That cannot easily change)
• Late Big Bang Integration
• Limited Testing
• Lots of handovers
• Manual Deployments
• Low Maintainability

14. Software Delivery – Done Differently Vision Level
Vision Statement
V-Model to I-Model Goals
(Changing a “waterfall” verification and validation testing mindset to
spec-driven purpose fulfillment mindset)
System / Product
Level
Executable
Specifications
Acceptance
Feature Level
Domain Driven Design
Architecture
Story Level
Interface Driven
Evolutionary Design
Mocks
Integration
Scenario Level
TDD / Unit
Code-by-example
Implementation

15. Levels of Planning
Who? Executive Mgmt.
Vision
Why? Product Management
What? Product Product Owner
Product Owner,
When? Release
Stakeholders,
Team
How? Iteration Product Owner,
Team
Daily Team

16. What is different ?
• Deliver features instead of modules
• Prioritize often, change often
• Focus on high value features
• Flatten the cost of change
• Adapt to feedback
• Fail fast, fail safe (Learn from failure)
• Better Learning
• Better collaboration than handover

17. Evolution of Software Practices
• Adaptive Planning
• Streamlined, Executable Specifications
• Evolving Design (Just Enough Design)
• Continuous Code Refactoring
• Automated Acceptance Testing
• Continuous Integration
• Continuous Regression Testing
• Continuous Automated Deployments
• Highly Maintainable systems

18. BDD – Behavior Driven Development

19. Concept
• Behavior-Driven Development (BDD) is a
term used to classify a method to build
software by describing the application
behavior from the perspective of and what is
of value to the stakeholders.
• Other terms associated with same concept –
o Agile Acceptance Testing
o Acceptance Test-Driven Development
o Example-Driven Development
o Code By Example
o Story Testing
o Story Test-Driven Development
o Specification By Example

20. Communication Effectiveness
2 people at
white board
2 people
on phone
2 people
on email
Videotape
Audiotape Document
Form of Communication

21. Definition by Dan North (Creator of BDD)
“ Behavior-Driven Development (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. ”

22. Second-Generation
• Derived from TDD, Acceptance Test Driven
Planning, Lean and Domain Driven Design
• Concepts of Neuro-Linguistic Programming
(NLP) and Systems Thinking

23. Outside-In, Multiple-Scope, Vision Level
Vision Statement
Multiple Stakeholders Purpose
Who? System / Product
Vision Level
Why? Goals / Outcomes /
Capabilities
BDD Specifications
What? Product
Feature Level
When? Release Domain Driven Design
Architecture
How? Iteration
Story Level
Interface Driven
Evolutionary Design
Mocks
Daily
Scenario Level
TDD
Code-by-example
Implementation

24. Pull-based
• Just-enough details
• Diminishing returns
• Deliberate Discovery

25. Agile Methodology

26. BDD Principles
• Just Enough
• Deliver stakeholder value
• Behavior only

27. Key Process Patterns

28. User Story Template
As a [role]
I want [feature]
So that [benefit]
Title [title of the story]
In order to [benefit]
A [role]
Wants to [feature]

29. User Story Example
• Title: Register customers for VIP program
In order to be able to do direct marketing of products to
existing customers,
a marketing manager
wants customers to register personal details by joining a VIP
program.
• Title: Free delivery for VIP customers
In order to entice existing customers to register for the VIP
program,
a marketing manager
wants the system to offer free delivery on certain items to VIP
customers.

30. Scenario Template
Title [title of the scenario]
Given [some initial context / system State]
And [more context / system State]
When [an event occurs / user Action occurs]
Then [ensure outcome / system Reaction]
And [some outcomes / system Reactions]

31. Scenario Template
• Title: Register customers for VIP program
Given the customer registered for VIP program
When the customer adds 5 books in the cart
Then the customer gets free delivery
• Title: Register customers for VIP program
Given the customer registered for VIP program
When the customer adds 4 books in the cart
Then the customer does not get free delivery
And the customer gets standard delivery
• Title: Register customers for VIP program
Given the customer registered for VIP program
When the customer adds 5 washing machines in the cart
Then the customer does not get free delivery
And the customer gets standard delivery

32. User Story & Scenario Example
• Title: Customer withdraws cash
In order to not want to wait in line at the bank,
a customer
wants to withdraw cash from the bank ATM
• Title: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer request for cash withdrawal
Then ensure the account is debited
And ensure the cash is dispensed
And ensure the card is returned

33. User Story & Scenario Example
• Title: Customer withdraws cash
In order to not want to wait in line at the bank,
a customer
wants to withdraw cash from the bank ATM
• Title: Account is overdrawn past the overdraft limit
Given the account is overdrawn
And the card is valid
When the customer request for cash withdrawal
Then ensure a rejection message is displayed
And ensure the cash is not dispensed
And ensure the card is returned

34. BDD Characteristics
• Ubiquitous Language
• Iterative Decomposition Process
• Plain text description using Story and
Scenarios templates
• Automated Acceptance Testing with Mapping
Rules
• Readable Behavior Oriented Specification &
code
• Behavior Driven at different levels

35. BDD Conceptual Model
- A Study of the Characteristics of Behavior Driven Development
- by Carlos Solís & Xiaofeng Wang

36. Building The Right Product

37. Just-Enough Living Documentation

38. BDD Mind Map
- by Dan North

39. BDD Tools
• JBehave, NBehave
• RSpec, MSpec
• StoryQ, Cucumber, SpecFlow

40. BDD Anti-Patterns
• BDD is a framework with keywords & flavors
• BDD is for defining system behavior and TDD
for lower level components
• BDD is for business applications and TDD is
for API libraries
• BDD is too explicit, verbose.
• BDD is for higher level, TDD is for lower level
• BDD is for integration testing, TDD is for unit
testing
• BDD is outside-in, TDD is inside-out.

41. BDD comparison with Finite State Machine (FSM)
• Sequence Pattern • Parallel Split Pattern

42. BDD comparison with Finite State Machine (FSM)
• Synchronization Pattern

43. BDD comparison with Finite State Machine (FSM)
• Exclusive Choice Pattern

44. BDD comparison with Finite State Machine (FSM)
• Simple Merge Pattern

45. BDD comparison with Finite State Machine (FSM)
• Multiple Choice Pattern

46. BDD comparison with Finite State Machine (FSM)
• Synchronization Merge Pattern

47. BDD comparison with Finite State Machine (FSM)
• Multiple Merge Pattern

48. Thank You
Ajay Danait
Global Agile Strategist
Stixis Technologies, Bangalore