Successfully Implementing BDD in an Agile World
5 likes1,514 views
This document provides an overview of successfully implementing Behavior Driven Development (BDD) in an agile environment. It discusses shifting testing left by involving testers earlier in the development process. The document then covers the key aspects of a BDD process including discovery workshops to understand requirements, writing examples and scenarios in a Given/When/Then format, automating scenarios, and using continuous integration to ensure tests always pass. It emphasizes that adopting BDD requires changes to people, processes, and tools to facilitate collaboration between all teams.
![37
Step 1: Focus on the Value First
• What are the benefits of your feature?
• First step: start with answering “why”
• Why should we develop this feature?
• Why will this feature help my user?
• A feature should have a description that provides context to a need being met
• In order to [get a benefit]
• As a [role]
• I want [a feature]
•Example: HipTest & Slack
• Everyone on team needs a notification?
• Only HipTest users should be able to get notified
@Bria_Grangard](https://image.slidesharecdn.com/stpcon-grangard-bdd-190409141514/85/Successfully-Implementing-BDD-in-an-Agile-World-37-320.jpg)
![38
Step 1: Focus on the Value First
• What are the benefits of your feature?
• First step: start with answering “why”
• Why should we develop this feature?
• Why will this feature help my user?
• A feature should have a description that provides context to a need being met
• In order to [get a benefit]
• As a [role]
• I want [a feature]
•Example: HipTest & Slack
• Everyone on team needs a notification?
• Only HipTest users should be able to get notified
@Bria_Grangard](https://image.slidesharecdn.com/stpcon-grangard-bdd-190409141514/85/Successfully-Implementing-BDD-in-an-Agile-World-38-320.jpg)
![51
Key BDD Takeaways
TheSteps
1. Createafeature
• Inorderto[benefit]
• Asa[role]
• Iwant[feature[
2. Writeascenario
• Given
• When
• Then
3. Automate,ifyou’dlike
• Buildascalabletestautomationframework
• Implementyourfeature
• Repeat
What to Keep in Mind
1. Focus on the benefits of the feature
2. Be declarative when writing test
scenarios
3. Automate when it makes sense
4. Create a shared business terminology
5. Refactor where you can
6. Keep one single source of truth
@Bria_Grangard](https://image.slidesharecdn.com/stpcon-grangard-bdd-190409141514/85/Successfully-Implementing-BDD-in-an-Agile-World-51-320.jpg)
Successfully Implementing BDD in an Agile World
- 1. Successfully Implementing BDD in an Agile World
- 2. 2 Who am I? • SmartBear Software • Automated UI functional testing tools, test management solutions, BDD platforms • Podcast Co-Host • The Good, The Bad, and the Buggy • Education • Dartmouth: AB in Engineering, BE in Biomedical Engineering, MEM with a healthcare focus • What do I love to do? • Run, dance, play board games (Settlers of Catan anyone?) • Stay in Touch! • @Bria_Grangard @Bria_Grangard
- 3. 3 The World of BDD Shift Left The BDD Process: People. Process, Tools Question & Answer Agenda @Bria_Grangard
- 5. Software Has Traditionally Been Linear and Siloed Proprietary & Confidential 5 Plan Design Develop Document Deploy MonitorTest Developers QA OperationsBusiness 1 2 3 4 @Bria_Grangard
- 6. 6 WaterfallAgile Design Build Test Implement DevOps Week1 Week2 Week3 Week4 @Bria_Grangard The promise of the new software delivery cycle
- 7. 7 In the 1950’s, testing happened by the same people that wrote the code, and it happened throughout the project. There were no dedicated testers at the time. The idea of testing earlier isn’t new, but the term, Shift Left has reignited its importance. @Bria_Grangard
- 8. 88 @Bria_Grangard Shift Left: /SHift/ + /left/ an approach to software development where quality is considered and testing is performed earlier in the lifecycle • Testers are involved early • BAs/PMs write requirements in the form of tests • Developers write tests
- 9. 9 Why the hype around Shift Left? Testing Early, Testing Often Speed Quality Cost Cheaper to fixFewer defects = Shorter cycles @Bria_Grangard
- 10. 10 Traditional Software Development Lifecycle IBM Systems Sciences Institute Design Develop Test Operations Current Bug Discovery Costtofixadefect($) Avg Cost of Defect $100 $250 $1500 Design Develop Test DeployPlan Maintain @Bria_Grangard
- 11. 11 Current Bug Discovery Shifting Everything Left IBM Systems Sciences Institute Costtofixadefect($) Design Develop Test Operations Shift Left Discovery Plan Develop Test Maintain @Bria_Grangard
- 13. 13 Shifting Left is Really Happening • Developers create more testable code (less flaky tests) • Bridge the gap between Dev, QA, and Product • Code in sprints, now we can test in the same sprint too • Maintain a single code base – Application and test (unit, API, UI) • Enable true CI/CD • Think about quality in every step @Bria_Grangard
- 15. 15 How can teams Shift Left? • Agile / DevOps Practices • Virtualization • API Testing • Microservices • CI/CD Processes • BDD Workflows @Bria_Grangard
- 16. 16 Sometimes… Agile can fall short • Transient User Stories • Ad-hoc Acceptance Criteria • Limited Discovery • No Overarching Tests
- 17. 17 How can teams shift Left? • Agile / DevOps Practices • Virtualization • API Testing • Microservices • CI/CD Processes • BDD Workflows @Bria_Grangard
- 20. 2020 Behavior Driven Development (BDD): Is a software development process where teams create simple steps on how an application should behave from a user’s perspective. @Bria_Grangard
- 21. 2121 What is BDD? DeveloperTester Business • Discovery, Formulation, and Automation • Create a shared understanding based on examples • Use the examples to drive development • Create and share living documentation The 3 Amigos @Bria_Grangard
- 22. 22 What are the problems BDD helps address? 1. Business needs are not well understood by the people who want the software 2. Business needs are not well understood by people who deliver and test the software 3. The software is low quality with lots of bugs 4. The cost of changes over time increases rapidly @Bria_Grangard
- 23. 23 Discovery Formulation Automation BDD in Practice @Bria_Grangard
- 24. 2424 A quick aside… BDD vs. TDD @Bria_Grangard • What you’re testing • BDD: Test from the end-user’s standpoint • TDD: Focus on testing smaller pieces of functionality in isolation • How you’re testing • BDD: Emphasis on team collaboration (product, devs, QA) • TDD: A single person can complete in isolation (dev often) • How they work together • Need a good TDD base for success with BDD • TDDà ensures code quality • BDDà ensure use-cases work
- 25. 25 Making the Move to BDD Benefits: 1. Better communication and collaboration 2. Deliver value more frequently 3. Find and fix defects early and often 4. Minimize waste 5. Avoid development of features nobody wants Opportunities and Challenges Challenges: 1. Misalignment between various stakeholders on your team (product, dev, QA) 2. Producing products that don’t address your user’s needs 3. No universal language between departments 4. Pressure to release faster without sacrificing quality @Bria_Grangard
- 26. 26 In order to succeed you need to take a holistic approach People Processes Tools @Bria_Grangard
- 27. 2727 Let’s start with people… … it’s all about collaboration @Bria_Grangard
- 29. 29Using a common Language BDD Scenario Business Development Test • Defines requirements in spoken-word scenarios • Obtains feedback in clear, example heavy, and easy to understand language • Making the Scenario “pass” or “work” guides development efforts and provides focus • Scenario is easily translated directly into automated tests • Given / When / Then structure provides simple ways to ask for clarification • Scenarios contain Test definitions (Action, expected result) • Structure allows for easy reporting and traceability @Bria_Grangard
- 32. 32 Deliberate Discovery @Bria_Grangard Have conversations about user stories and acceptance criteria using concrete examples Goal: Try and learn as much as possible before writing any code
- 33. 33 Who should be involved in Deliberate Discovery? • Product Owners • Business Analysts • Domain Experts • Users • Developers • UX Designers • Testers @Bria_Grangard
- 34. 34 Running a Discovery Workshop From Matt Wynne: • Three Amigos Meetings • Keep them short! (25 minutes/user story) • Use Example Mapping • User Story—user stories that were developed in deliberate discovery process • Rules—acceptance criteria for the user story containing agreed-upon constraints • Examples—concrete examples covering each rule (may have more than one per rule) • Questions—unknowns that arise when exploring rules, examples, or assumptions made to move forward @Bria_Grangard
- 35. 35 Example Mapping— Session • Set-Up: • Use a pack of four-color index cards • Remove distractions • Running a Session: 1. Write the story in yellow 2. Write acceptance criteria, or “rule” in blue 3. Write concrete examples on green 4. Capture questions on red 5. Vote to see if the user story is ready for development @Bria_Grangard
- 36. 36 Record the Results @Bria_Grangard • Use Gherkin Syntax • Create Executable Specification without code
- 37. 37 Step 1: Focus on the Value First • What are the benefits of your feature? • First step: start with answering “why” • Why should we develop this feature? • Why will this feature help my user? • A feature should have a description that provides context to a need being met • In order to [get a benefit] • As a [role] • I want [a feature] •Example: HipTest & Slack • Everyone on team needs a notification? • Only HipTest users should be able to get notified @Bria_Grangard
- 38. 38 Step 1: Focus on the Value First • What are the benefits of your feature? • First step: start with answering “why” • Why should we develop this feature? • Why will this feature help my user? • A feature should have a description that provides context to a need being met • In order to [get a benefit] • As a [role] • I want [a feature] •Example: HipTest & Slack • Everyone on team needs a notification? • Only HipTest users should be able to get notified @Bria_Grangard
- 39. 39 Step 2: Be Declarative When Writing Scenarios • Focus on the what? • Two styles of writing your test scenario • Imperative • Long scenarios with low-level steps describing how to navigate the user interface • Declarative • Gherkin syntax • Given is your setup • When is your action • Then is your assertion • Text describes the what not the how @Bria_Grangard
- 40. 40 Step 2: Be Declarative When Writing Scenarios • The Declarative Style of Writing—An Example • Given I am logged in • When I add an item to the cart • And I click on the cart • Then I should see the item I added WhyisthisDeclarative? • Itdoesn’tmatterhowsomeonedidthe loginàusername,password,touchID • Whatdoesmatter:someoneloggedin DeclarativeExampleforHipTest&Slack GivenIhaveactivatedslackinthesettingsofmyHipTestproject WhenIquery/hiptestTestRunIDfromslack ThenIshouldseethebreakdownoftestsbystatusesfortestRunID @Bria_Grangard
- 41. 41 Step 3: Automate (if you’d like) Your BDD Scenarios • Build a test automation framework • Focus on building a framework that will scale • Your first execution will fail--> the feature is not yet implemented • Implement your feature • Run the automated BDD scenarios to show the feature is completed • Repeat @Bria_Grangard
- 42. 42 Continuous Integration @Bria_Grangard • Making small changes to a single code repository that multiple developers may be working on…. and integrating those changes often • Help avoid breakage rather than merging all your changes at once • Benefits: • Quicker identification of bugs • Faster feedback loop • Quicker deployments for customers • Tools: Jenkins, CircleCI, TravisCI, Bamboo, etc.
- 43. 43 Typical CI Pipeline Proprietary & Confidential • Code and tests are committed to the repository • Software is built using CI • Service runs automated tests on the build • Build fails à team is notified • Build succeeds à software automatically deployed * Can use a staging server if prefer to do final QA by hand * Can have a CI server that test new GIT branches against the master branch
- 44. 44 Reduced Risk -Identify and fix defects immediately More Confidence -Reduced risk = increase in confidence Greater Visibility -Everyone can see the project state--> better feedback Benefits of Continuous Integration @Bria_Grangard
- 45. 4545 Living documentation is an up-to-date record of a feature that defines test scenarios through a common language. This way all team members can have current and accurate information of the application in production—as well as an archive of past test runs. @Bria_Grangardhttps://hiptest.com/blog/living-documentation/why-living-documentation-is-important-in-bdd/
- 46. 46 Living Documentation @Bria_Grangard • Your tests already serve as documentation • ”Living” because it’s up-to-date when tests are automated through CI/CD pipeline • An important part of the feedback loop • Instrumental in keeping stakeholders, developers, and users on the same page • Readable by both business and technical team members • Shows exactly what the application is supposed to do… and proves that it can do it
- 47. 47 Benefits of Living Documentation @Bria_Grangard Faster Updates Improved Support Better Workflow
- 49. 49 Resources & Tools • Introducing BDD: https://dannorth.net/introducing-bdd/ • Step-by-Step BDD process: https://hiptest.com/behavior-driven-development/ • BDD hub: https://automationpanda.com/bdd/ • Discover Workshops: https://docs.cucumber.io/guides/bdd-tutorial/ • BDD & CI: https://www.agilealliance.org/glossary/bdd/ • Living Documentation: https://hiptest.com/blog/living-documentation/why-living-documentation- is-important-in-bdd/
- 50. 50 BDD Misconceptions @Bria_Grangard 1. BDD is an automation testing framework 2. BDD takes a long time 3. BDD introduces unnecessary steps 4. BDD is only for developers
- 51. 51 Key BDD Takeaways TheSteps 1. Createafeature • Inorderto[benefit] • Asa[role] • Iwant[feature[ 2. Writeascenario • Given • When • Then 3. Automate,ifyou’dlike • Buildascalabletestautomationframework • Implementyourfeature • Repeat What to Keep in Mind 1. Focus on the benefits of the feature 2. Be declarative when writing test scenarios 3. Automate when it makes sense 4. Create a shared business terminology 5. Refactor where you can 6. Keep one single source of truth @Bria_Grangard
- 52. 52 Final Words of Wisdom Tips & tricks to ensure the health of your code • Create shared business terminology across all scenarios • Keep your terminology consistent when writing scenarios • “I log in” vs. “I sign in” à do they have the exact same intent even though they’re written differently? • This way… it becomes a common language shared by all team members • Autocompletion tools can be helpful for reusing existing steps and terminology rather than creating new steps and duplications • Have the right refactoring capabilities to manage the impacts of changes on your test scenarios • Steps with high reuse are often requiring changes/updates • Find a tool, or method, to go about refactoring changesà example includes updates to environments you’re going to be running your tests on • Keep one single repository of manual and automated test scripts @Bria_Grangard
- 53. 5353 We need to avoid building the wrong swing. @Bria_Grangard
- 54. Appendix
- 55. Behavior-Driven Development: (BDD) a software development process where teams create simple steps on how an application should behave from a user’s perspective Starting with the end in mind. • TDD focuses on the developer’s view on how an software should work • BDD focuses on the users’ view on how the application should behave @Bria_Grangard
- 56. Additional Tips Tips & tricks to ensure the health of your code • Createsharedbusinessterminologyacrossallscenarios • Keepyourterminologyconsistentwhenwritingscenarios • “Ilogin”vs.“Isignin”àdotheyhavetheexactsameintenteventhoughthey’rewrittendifferently? • Thisway…itbecomesacommonlanguagesharedbyallteammembers • Autocompletiontoolscanbehelpfulforreusingexistingstepsandterminologyratherthancreatingnewsteps andduplications • Havetherightrefactoringcapabilitiestomanagetheimpactsofchangesonyourtestscenarios • Stepswithhighreuseareoftenrequiringchanges/updates • Findatool,ormethod,togoaboutrefactoringchangesàexampleincludesupdatestoenvironmentsyou’re goingtoberunningyourtestson • Keeponesinglerepositoryofmanualandautomatedtestscripts *Photo taken from Laurent Py, Hiptest