A brief intro to Behavior-Driven Development

1. Behavior-Driven Development
As a Developer
I want clear requirements
So I can build the right stuff
Andreas Enbohm
@enbohm
(screenshot from http://www.thucydides.info/ and http://www.wakaleo.com/ )

2. Succesful IT-Projects
1. Build the software right
2. Build the right software

3. Succesful IT-Projects

4. State of Succesful IT-Projects
The 2011 edition of Standish Group’s annual CHAOS Report
found that 42% of IT projects were either delivered late, ran
over budget, or failed to deliver all of the requested features,
and 21% of projects were cancelled entirely.

5. State of Succesful IT-Projects
Scott Ambler’s annual survey on IT Project success rates
found a 30%-50% failure rate depending on the
methodologies used.

6. Used Functionality

7. The Consequences of Not Building It Right
In December 2007, the Queensland Health department* kicked off work on a new payroll system
for its 85,000 employees. The initial budget for the project was around $6 million, with a delivery
date scheduled for August 2008. When the solution was rolled out in 2010, some 18 months late, it
was a disaster.
Tens of thousands of public servants were underpaid, overpaid, or even not paid at all.
Since the go-live date, over 1000 payroll staff are required to carry out some 200,000
manual processes each fortnight to ensure that staff salaries are paid. In 2012, an
independent review found that the project had cost the state over $416 million since going
into production, and would cost an additional $837 million dollars to fix. This colossal sum
included $220 million just to fix the immediate software issues that were preventing the
system from delivering its core capability of paying Queensland Health staff what they are
owed each month.
* see http://en.wikipedia.org/wiki/Queensland_Health#Payroll_problems

8. The Consequences of Not Building It Right
Product
nobody
wants, wrong
built.

9. BDD
Behavior-driven development combines
techniques and principles of TDD with ideas
from domain-driven design and object-oriented
analysis and design, with the aim of delivering
"software that matters".

10. Benefits
•
•
•
•
•
•
Only build feature that add real value
Less waste (and hence, reduced cost)
Better communication
Higher quality, better tested product
Traceability, ’Live Documentation’
Enables a way to automatic test the
requirements

11. BDD
• BDD describes TDD done well
- removes word ’test’
- replace it with behaviour, examples,
scenarios etc.
• Good habits;
1. Working outside-in
2. Using examples to clarify requirements
(scenarios)
3. Using a common (ubiquitous) language

12. BDD – Value Driven
• A good goal should add value to business
- increase revenue
- reduce cost
- avoid future cost
- protect revenue
”Increase revenue by allowing
customers to…”
”Prevent current customers
switching to competing product
by …”

13. BDD – What Does the Customer Need?
• Good teams push back!
- users tend to express requirements as implementations
- we need to find the business need!
We need caching
So that the page
loads fast
So that the
customer will buy
stuff on our site and
doesn’t leave page
Why?
Why?
Ok, so to increase the chance a customer
will buy [stuff] it need to be ’fast’. Caching
might be one way to achive this, but
compressing images might be more
effective. Or another way might be loaders,
or ..

14. BDD – Better understanding
• Working outside-in
- if you need to explain to a computer how to check the
requirement, you’ll need to be damn sure understand it
yourself
• Business black-box testing is often done manually!
- BDD enables automated acceptance testing
• Mininum effort /code to fulfull requirement

15. BDD – Common Language
• Common Language
- communication often the biggest overhead
- even bigger if you allow different dialects of terminology
- takes time but gains significant advantage

16. BDD

17. User Stories
“a concise, written description of a piece of
functionality that will be valuable to a user (or
owner) of the software. It captures the 'who',
'what' and 'why' of a requirement in a simple,
concise way.”

18. User Stories
Story: Returns go to stock
Goal come first
Narrative:
In order to keep track of stock
As a store owner
I want to add items back to stock when they're returned
Stakeholder is
secondary
The feature must be
required to achieve this
goal

19. Scenarios
• The ’perfect’ bridge between the businessfacing and technology-facing sides of a team
Common language which is
reflected all way down in the
code
Scenario 1: Refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock

20. Why User Stories?
"Maybe it is easier to get users to write down what
they need on a card in a few paragraphs than it is to get
them to see the difference between uses and extends"
- Anonymous

21. Implementation

22. http://www.thucydides.info/

23. http://www.thucydides.info/

24. Wrap-up
• Pros
- increases the quality of the product
- change with confidence
- live documention (great for maintenance)
- less waste, building ”software that matters”
• Cons
- high need of business engagemang (clear
requirements)
- BDD works best in Agile context
- easy to write fragile tests (high maintenence
cost)

25. Thank You!