Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Successfully Implementing BDD in an Agile World


Published on

Presentation by Bria Grangard at STPCon 2019

Published in: Software
  • Be the first to comment

  • Be the first to like this

Successfully Implementing BDD in an Agile World

  1. 1. Successfully Implementing BDD in an Agile World
  2. 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. 3 The World of BDD Shift Left The BDD Process: People. Process, Tools Question & Answer Agenda @Bria_Grangard
  4. 4. 4 Shift Left Overview @Bria_Grangard
  5. 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. 6 WaterfallAgile Design Build Test Implement DevOps Week1 Week2 Week3 Week4 @Bria_Grangard The promise of the new software delivery cycle
  7. 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. 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. 9 Why the hype around Shift Left? Testing Early, Testing Often Speed Quality Cost Cheaper to fixFewer defects = Shorter cycles @Bria_Grangard
  10. 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. 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
  12. 12. 12 Software Development is Hard
  13. 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
  14. 14. 14 BDD AI Machine Learning DevOps Shift Left Agile Automation TDD Service Virtualization @Bria_Grangard
  15. 15. 15 How can teams Shift Left? • Agile / DevOps Practices • Virtualization • API Testing • Microservices • CI/CD Processes • BDD Workflows @Bria_Grangard
  16. 16. 16 Sometimes… Agile can fall short • Transient User Stories • Ad-hoc Acceptance Criteria • Limited Discovery • No Overarching Tests
  17. 17. 17 How can teams shift Left? • Agile / DevOps Practices • Virtualization • API Testing • Microservices • CI/CD Processes • BDD Workflows @Bria_Grangard
  18. 18. 18 BDD Overview @Bria_Grangard
  19. 19. 19 @Bria_Grangard
  20. 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. 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. 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. 23 Discovery Formulation Automation BDD in Practice @Bria_Grangard
  24. 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. 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. 26 In order to succeed you need to take a holistic approach People Processes Tools @Bria_Grangard
  27. 27. 2727 Let’s start with people… … it’s all about collaboration @Bria_Grangard
  28. 28. 28 Roles @Bria_Grangard
  29. 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
  30. 30. 3030 Process @Bria_Grangard
  31. 31. 31 The BDD Process @Bria_Grangard
  32. 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. 33 Who should be involved in Deliberate Discovery? • Product Owners • Business Analysts • Domain Experts • Users • Developers • UX Designers • Testers @Bria_Grangard
  34. 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. 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. 36 Record the Results @Bria_Grangard • Use Gherkin Syntax • Create Executable Specification without code
  37. 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. 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. 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. 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. 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. 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. 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. 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. 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_Grangard
  46. 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. 47 Benefits of Living Documentation @Bria_Grangard Faster Updates Improved Support Better Workflow
  48. 48. 4848 Tools @Bria_Grangard
  49. 49. 49 Resources & Tools • Introducing BDD: • Step-by-Step BDD process: • BDD hub: • Discover Workshops: • BDD & CI: • Living Documentation: is-important-in-bdd/
  50. 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. 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. 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. 53. 5353 We need to avoid building the wrong swing. @Bria_Grangard
  54. 54. Appendix
  55. 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. 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