Downloaded 28 times
![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 ..](https://image.slidesharecdn.com/bdd-intro-140124042206-phpapp01/85/BDD-Short-Introduction-13-320.jpg)
Uploaded byAndreas Enbohm
BDD Short Introduction
Behavior-driven development (BDD) combines techniques from test-driven development (TDD) and domain-driven design to help developers build the right software by providing clear requirements. It uses examples in the form of scenarios and stories written in a common language to describe features from the perspective of stakeholders. This improves communication between business and technical teams and allows for automated acceptance testing. When done well, BDD can help deliver higher quality, better tested software that meets real business needs.
More Related Content
Similar to BDD Short Introduction
BDD Short Introduction
- 1. Behavior-Driven Development As aDeveloper 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. Buildthe software right 2. Build the right software
- 3.
- 4. State of SuccesfulIT-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 SuccesfulIT-Projects Scott Ambler’s annual survey on IT Project success rates found a 30%-50% failure rate depending on the methodologies used.
- 6.
- 7. The Consequences ofNot 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 ofNot Building It Right Product nobody wants, wrong built.
- 9. BDD Behavior-driven development combines techniquesand 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 featurethat 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 describesTDD 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 – ValueDriven • 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 – WhatDoes 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 – Betterunderstanding • 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 – CommonLanguage • Common Language - communication often the biggest overhead - even bigger if you allow different dialects of terminology - takes time but gains significant advantage
- 16.
- 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: Returnsgo 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? "Maybeit 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.
- 22.
- 23.
- 24. Wrap-up • Pros - increasesthe 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.