Making the Move to Behavior Driven Development
Download as PPTX, PDF3 likes1,165 views
The document discusses moving to a behavior-driven development (BDD) approach. It outlines challenges with traditional software development processes, such as requirements getting lost in handoffs. BDD aims to address these by shifting testing to the beginning through acceptance tests written in a "Given-When-Then" format. This allows teams to build testable code, catch issues earlier, and deploy features incrementally. Adopting BDD requires training, champion support, and patience. Metrics should track success, and teams can start small before a full rollout.
Making the Move to Behavior Driven Development
- 1. Making the Move to Behavior- Driven Development Kevin Dunne, VP of Business Development, QASymphony
- 2. AGENDA • Understanding typical software development and testing challenges • Introduce BDD methodologies • Benefits of implementing test-first methodologies • Review the state of test-first methodologies in industry • Investigate keys for successful implementation BDD • Q&A
- 3. Current Problems in Software Dev & Test
- 4. Where We Came From Traditional development cycles often model the Rational Unified Process: Source: http://www.psa-software.com/_img/_knowledge_center/rup.jpg
- 5. The Broken Game of Telephone Running the processes in parallel introduces the risk as the requirements get handed off multiple times and customer expectations change with time: Source: http://lh5.ggpht.com/_g0-GZzIBNms/SloJ3LOGy3I/AAAAAAAAAK0/FvyLacg_Q28/s800/conversations.pngg
- 6. The “Old Way” was the Best Way at the Time We would have obviously chosen a more efficient process, but we were constrained by many limitations, including: Environment Creation Code Merges On-Premise Prevalence Desktop Focus Lack of Collaboration Off-Shore Development
- 7. What’s Changed Many of our prior limitations have been replaced, based on macro trends around technology and industry: Containers have simplified the process dramaticallyEnvironment Creation Git has replaced Subversion as the industry standardCode Merges Cloud adoption is at an all time high, increased securityOn-Premise Prevalence Prevalence of Web, Mobile, Internet of thingsDesktop Focus Increase in teamwork, chat and collaboration technologyLack of Collaboration Shifts towards rural sourcing, onshoring of laborOff-Shore Development
- 8. Why QA Breaks Down in Agile QA kept out of the loop QA are unable to complete tests when needed Dev and QA working on different cadences Lack of visibibility or understanding into when QA is “Done” with testing
- 10. How the Process Has Adapted Now that we have freed ourselves of past limitations, the process has been shifted to one that aligns more with our needs: Traditional Approach Test-First Approach Design Requirements Code Test Deploy Design (Automated) Test Code Refactor Deploy
- 11. TDD vs. ATDD vs. BDD Test-First methodologies were coined “Test Driven Development”. Less technically focused versions called Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD) also emerged: Test Driven Development (TDD) Behavior Driven Development (BDD) Acceptance Test Driven Development (ATDD) Unit Test Driven Development (“Technical TDD”)
- 12. What’s the Difference? ATDD and BDD are similar in that they both try to make TDD more accessible to business users. The major functional difference comes down to how the tests are structured: "I think this definition leaves out a key piece, we are focusing on collaboration and learning. Having worked on a project that was using 'ATDD', in 2005 I think, we had the same goals then as BDD without the Given When Then language.“ — Wes Williams
- 13. Pros and Cons ATDD/BDD offer benefits over more Unit Focused/Technical TDD, but also has its drawbacks: Pros • Increased understanding of tests from business stakeholders • Increased collaboration early in the cycle • More focus on customer and business needs • Higher involvement of business in development and quality Cons • Addition of more tooling in the development/delivery chain • Greater time spent defining tests and specifications • Demands stronger contributors in requirements, dev, test • Often increases the automation needs in an organization
- 14. Typical BDD Planning Hierarchy Sprint 1 Sprint 2 Sprint 3 Sprint 4 Epic: ATM Software Story : Withdraw Cash Story : Check Balance Acceptance Test: Overdraft Epic: Online Banking Portal
- 15. User Stories Define the Discrete Units of Work The user story is the “What” or the high level ask the business has for the development team User Stories often still exist with BDD, as a framework for adding scenarios. Some companies would change User Stories to being called features. Example: As a customer, I want to withdraw cash from an ATM, so that I don’t have to wait in line at the bank. Source: https://dannorth.net/introducing-bdd/
- 16. Non-BDD – Define with Acceptance Criteria Acceptance criteria are used to define the User Story in a detailed manner While acceptance criteria are easy to write, they are often vague or incomplete Additionally, users typically need to write acceptance tests to validate the criteria pass Example: - Cash dispensed in less than 10 seconds - Cash dispensed matches amount requested by customer - American express cards not accepted - Overdrafted accounts rejected for withdrawal
- 17. The BDD Way - Acceptance Tests Verify the work: Acceptance tests evaluate the acceptance criteria using the “Given- When-Then” format. Example: Scenario: Overdrawn accounts cannot withdraw money Given the account is overdrawn And the card is valid When the customer requests cash Then ensure a rejection message is displayed And ensure cash is not dispensed And ensure the card is returned Source: https://dannorth.net/introducing-bdd/
- 19. How Can TDD Help Us? Test Driven Development brings several major benefits to organization, most notably: 1. Move Testing Up Front – prevents having to rush testing at the end of the cycle 2. Bake in Automation from Day 1 – protects against getting behind with test and automation coverage 3. Build More Testable Software – requires developers to think about testability, and create more robust software 4. Push to Customers When Ready – allows you to push software to customers just in time, as it is developed
- 20. Move Testing Up Front Moving Testing Up Front removes the risk of having to make compromises at the end of the cycle on quality or on-time delivery: Traditional Development Timeline Ends on: Day 1 Day 3 Day 14 Day 20 Day 21 Design Requirements Code Test Deploy There is risk in this process that any process, typically Code, will run over and either squeeze development, or push release dates. TDD removes it!
- 21. Defect Costs Increase as Code Matures 0 20 40 60 80 100 120 Design Implementation Testing Maintenance Phase/Stage of the S/W Development in Which the Defect is Found Cost of Resolving Defect
- 22. Bake in Automation Up Front In traditional development, automation is often built after the code is developed, which has significant limitations: Test development is more costly, since we cannot access the code to make it more testable (more details to come) Tests are slower and more brittle, with higher levels of maintenance, if we can only access the UI Test coverage is incomplete, as we must chose strategically where to build out automation coverage Moving to TDD flips the process and forces developers to write code to satisfy tests, increasing automation coverage, speed, and reducing cost
- 23. Build for Testability Source: http://zeroturnaround.com/wp-content/uploads/2015/12/PUZZLE-1-min.png Moving towards BDD will force your developers to build an application that can be tested well at the Unit, Integration, and UI levels:
- 24. UI Tests Integration Tests Unit Tests Building a Complete Testing Strategy Moving towards BDD will also demand a more complete testing strategy focused on more than just UI testing: UI Tests Integration Tests Unit Tests
- 25. Push Features When They Are Complete TDD paired with continuous delivery will allow you to push features as they become ready, if you’d like to: Old Way New Way Code Feature A Code Feature B Code Feature C Test Deploy Wait Wait Code Feature A Code Feature B Code Feature C Write Tests Deploy Deploy Deploy
- 26. State of Test-First in Industry
- 27. State of Test First – Respondent Overview Most respondents are yet to implement TDD, or just getting started
- 28. Learning the Ropes Online Most people are learning about TDD online, due to lack of good in-person content!
- 29. Struggling for Developer Buy-In The biggest stumbling block continues to be getting developers to write tests
- 30. Transition to Agile First, Then TDD Most organizations move to TDD after mastering Scrum/Kanban Agile approach
- 31. How Teams are Doing BDD
- 32. Scope •Define user story Define Tests •Write Acceptance Tests Code Features Build •Build the latest code Run Tests •Execute acceptance tests Tools Our Customers Are Using IF PASSED: Report results back to User Story OR Refactor IF FAILED: Change Code
- 33. Benefits to the Organization Increased team collaboration and morale Expanded test coverage Reduced time to execute or maintain regression Enhanced reusability of testing assets Organization wide interest in quality
- 34. Implementation Models There are different implementation models with different pros and cons: Train the Trainer Phased Rollout Big Bang Dev Dev Dev QA PO Ops SMTeam A Dev Dev Dev QA PO Ops SMTeam A Dev Dev Dev QA PO Ops SMTeam A Dev Dev Dev QA PO Ops SMTeam A Dev Dev Dev QA PO Ops SMTeam A Dev Dev Dev QA PO Ops SMTeam A Increased Risk, Increased Reward
- 35. Keys To Success • Be patient, success will take time • Do a real assessment of talent BEFORE you embark on a journey towards BDD • Identify one or multiple champions with strong personalities and rapport • Define success criteria using metrics that matter to you • Start smaller where risks are minimized • Don’t be afraid to ask for help and seek guidance online or from in person consultants
- 36. Q&A