Behavior Driven Development (BDD)
5 likes4,733 views
This document discusses Behavior Driven Development (BDD), which is an agile software development methodology that focuses on defining and testing business requirements through executable specifications and acceptance criteria. The document covers the key concepts of BDD, including outside-in development, pull-based planning, and defining behavior through user stories and scenarios. It also discusses how BDD compares to other techniques like test-driven development and finite state machines. The overall goal of BDD is to facilitate collaboration between developers and business stakeholders to build the right product through living documentation of desired behaviors.
![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]](https://image.slidesharecdn.com/behaviordrivendevelopmentbdd-130226082404-phpapp02/85/Behavior-Driven-Development-BDD-28-320.jpg)
![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]](https://image.slidesharecdn.com/behaviordrivendevelopmentbdd-130226082404-phpapp02/85/Behavior-Driven-Development-BDD-30-320.jpg)
Behavior Driven Development (BDD)
- 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.
- 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
- 26. BDD Principles • Just Enough • Deliver stakeholder value • Behavior only
- 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
- 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