View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
Behavior Driven Development Ajay Danait Global Agile Strategist Stixis Technologies, Bangalore
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)
Quick SurveyWhile doing softwaredevelopment, who do you thinklike ...Like a …Plumber, Carpenter, Sculptor, Artist,Blacksmith, Hairdresser, Firefighter,Scientist, Archaeologist, Author, Typist
Not Designations … But Roles Switch Caps Not Wear Crowns• Architect• Artist• Craftsman• Planner• Team Player• Critic• Engineer
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
Quick Opinion When do you say a software project has "failed" ?
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
Traditional Software Delivery Process Why Do We Do This ?
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.
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.
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
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
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
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
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
Communication Effectiveness 2 people at white board 2 people on phone 2 people on email Videotape Audiotape Document Form of Communication
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. ”
Second-Generation• Derived from TDD, Acceptance Test Driven Planning, Lean and Domain Driven Design• Concepts of Neuro-Linguistic Programming (NLP) and Systems Thinking
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]
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.
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]
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
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
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
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
BDD Conceptual Model - A Study of the Characteristics of Behavior Driven Development - by Carlos Solís & Xiaofeng Wang
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.
BDD comparison with Finite State Machine (FSM)• Sequence Pattern • Parallel Split Pattern
BDD comparison with Finite State Machine (FSM)• Synchronization Pattern
BDD comparison with Finite State Machine (FSM)• Exclusive Choice Pattern
BDD comparison with Finite State Machine (FSM)• Simple Merge Pattern
BDD comparison with Finite State Machine (FSM)• Multiple Choice Pattern
BDD comparison with Finite State Machine (FSM)• Synchronization Merge Pattern
BDD comparison with Finite State Machine (FSM)• Multiple Merge Pattern
Thank You Ajay Danait Global Agile StrategistStixis Technologies, Bangalore