Implementing BDD at scale for agile and DevOps teams
Download as PPTX, PDF2 likes1,169 views
The document discusses the successful implementation of a large ticketing system for the city of Helsinki using behavior-driven development (BDD). It outlines the project's key practices, adoption steps, and the benefits of BDD in enhancing collaboration among teams and ensuring customer value. The results indicate a reduction in bugs and timely delivery while adapting to changes effectively.
Implementing BDD at scale for agile and DevOps teams
- 1. Delivering successfully a huge ticketing system using Behavior Driven Development Test Expo UK - 2016
- 3. PRESENTATION AGENDA A huge ticketing system What’s and Why BDD ? BDD adoption step by step Key practices Key takeaways 3
- 5. A HUGE TICKETING SYSTEM Customer : The city of Helsinki • Prime contractor : Tieto • Many partners as Parkeon • Teams distributed over 6 countries 5 1.5 M 50% inhabitants •trips made using public transport 360 M commuters a year
- 6. A HUGE TICKETING SYSTEM 6 CONFIGURATION AND MONITORING (backoffice node JS) x 50 Modules SALES POINTS & SERVICES POINTS (web services) x 300 ONBOARD & ON STREET DEVICES (Android) x 6000 THE SYSTEM
- 7. A HUGE TICKETING SYSTEM 7
- 8. A HUGE TICKETING SYSTEM 8
- 10. « BDD in a tweet : Using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters » - Dan North Create a shared understanding of the system using examples Based on a common business terminology A definition of stop Once automated, these examples become the living specification BEHAVIOR DRIVEN DEVELOPMENT IN A NUTSHELL 10
- 11. 11 STORY WHAT WILL BE REALLY DONE TO MEET THE NEED
- 12. 12 STORY : ONCE AUTOMATED LIVING SPECIFICATION
- 13. WHY BDD ? 13
- 16. 16 BUILD PYRAMIDS 1. DEFINING MODULES’ BEHAVIORS AND INITIALIZING BUSINESS TERMINOLOGY UNIT FONCTIONAL SCENARIOS ARE CREATED TESTS STEPS ARE AUTOMATED 2. ASSEMBLING THE MODULES, 2 BY 2, TO INTEGRATE THE SYSTEM INTEGRATION TESTS ARE CREATED USING UNIT FONCTIONAL STEPS SOME NEW TESTS STEPS ARE CREATED, AUTOMATED 3. BUILDING THE SYSTEM WITH ALL MODULES END TO END, TESTS ARE CREATED USING INTEGRATION STEPS INTEGRATE THE HARDWARE
- 17. Limiting the number of steps to ease automation and limit maintenance Controlling the wording to standardize the test plans Writing stateless tests to ensure reusability Always keep in mind the volume of the system in production to focus on the real condition of use Keeping requirement’s links from Unit Functional Tests to ensure traceability TAKE CARE OF 17
- 18. COMMON OBJECTIVE Building tests library and an automation tool to validate the system together. BDD offered the keys and the framework that bound them The principals were well accepted by most of the teams BDD has the advantage of focusing the teams on the customer value HOW IT WAS PERCEIVED 18
- 19. ●For a team that works independently on a sub-system Test and requirement coverage is impressive Very strong fit with BDD approach Quite no bug in production ! HOW IT WAS PERCEIVED 19
- 20. ●For teams that have to work together and synchronize Some difficulties to sync parallel works, but it’s quite ok Strong fit with BDD approach HOW IT WAS PERCEIVED 20
- 21. ●For teams that work on a product used in multiple projects «It is complicated»Maintaining the roadmap was a challenge HOW IT WAS PERCEIVED 21
- 22. 2 - Refine wih examples1 - Jira to manage stories 3 - Implement the stories 5 – Create builds and run tests4 – Execute tests Results TOOL STACK 22
- 23. KEY PRACTICES 23
- 24. 我希望我可以 混合颜色 function(c1, c2) { if (c1==c2) { return c1; } else { … } }; Given the color red and the color green when you mix the colors then you obtain yellow Business user Developer Tester DEFINE A COMMON BUSINESS TERMINOLOGY 24
- 25. Given : a context When : I do an action Then : I can check an impact GHERKIN SYNTAX 25
- 26. Autocomplete USE A CONSISTENT BUSINESS TERMINOLOGY 26
- 27. Identify duplication and create a single point of maintenance Identify duplication and create a single point of maintenance REFACTOR SCENARIOS CONTINUOUSLY 27
- 28. Impact hundreds of tests automatically when changing a step REFACTOR SCENARIOS CONTINUOUSLY 28
- 29. OUTCOMES 29
- 30. 200 End to end tests 475 990 1635 Systems test Module integration tests Functional unit tests Business terminology: 1690 steps A FEW FIGURES 30
- 31. No more than a week of delay on the deliverables 20% of the features (among 800) have been changed without impact on the planning agile! ON TIME 31
- 32. 32 ON BUDGET 21% Project management 16% Devices 30% Backoffice 30% Sales server 16% Test
- 33. 33 HAPPY CUSTOMER 61% Development tasks 11% Integration issues 20% Validation issues 3% Customer issues 5% Development issues
- 34. ANY QUESTIONS ?