Behavior Driven Development (BDD)

  • 1,075 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,075
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 SurveyWhile doing softwaredevelopment, who do you thinklike ...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 ArchitectureTech 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 causesSoftware 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 ManagementWhat? Product Product Owner Product Owner,When? Release Stakeholders, TeamHow? 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 asecond-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 ofworking, 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 PurposeWho? System / Product Vision LevelWhy? Goals / Outcomes / Capabilities BDD SpecificationsWhat? Product Feature LevelWhen? Release Domain Driven Design ArchitectureHow? 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 TemplateAs 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 TemplateTitle [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 StrategistStixis Technologies, Bangalore