How BDD can save your agile?
Download as PPTX, PDF0 likes264 views
BDD can help save Agile by facilitating three main outcomes: shared understanding, business readable specifications, and living documentation. BDD involves discovering business needs through workshops, formulating examples and scenarios in a business-readable way, and automating tests to create living documentation that ensures everything continues to work as intended. Practicing BDD improves collaboration, delivers working software based on business needs, and guides development with up-to-date documentation.
How BDD can save your agile?
- 1. How BDD Can Save Your Agile?
- 2. Laurent Py @py_laurent VP of Products - SmartBear Seb Rose @sebrose BDD Advocate - Smartbear Presented by
- 3. Agenda Shared understanding What is BDD? Business readable specifications Living Documentation Proprietary & Confidential 3 Does Agile really need saving?
- 5. Scrum ≠ Agile Proprietary & Confidential 5
- 6. Predictability Does Agile really need saving? Proprietary & Confidential 6 Communication Quality
- 7. Small Pieces Does Agile really need saving? Proprietary & Confidential 7 Collaboration Technical discipline
- 8. What is BDD?
- 9. What is BDD? Proprietary & Confidential 9 Behaviour Driven Development
- 10. What is BDD? Proprietary & Confidential 10 Individuals and Interactions Over Processes and Tools
- 11. BDD is an approach that facilitates interactions between individuals. What is BDD? Proprietary & Confidential 11
- 12. Proprietary & Confidential 12 What is BDD? 3 practices of BDD Discovery FormulationAutomation
- 13. Proprietary & Confidential 13 What is BDD? Shared understanding Business readable specifications Living Documentation 3 outcomes of BDD
- 15. Shared understanding Proprietary & Confidential 15 Shared understanding matters because software is made by people.
- 16. Shared understanding Proprietary & Confidential 16 Shared understanding matters because ignorance is the bottleneck. Shared understanding matters because software is made by people.
- 17. Proprietary & Confidential 17 Shared understanding Discovery Workshop Shared understanding Concrete examples Business rules Stories Smaller stories Questions Example mapping: https://cucumber.io/blog/example-mapping-introduction/
- 18. Shared understanding is a team sport because everyone has a unique perspective. Shared understanding Proprietary & Confidential 18 Shared understanding matters because ignorance is the bottleneck. Shared understanding matters because software is made by people.
- 20. Business readable specifications make sense to everyone. Business readable specifications Proprietary & Confidential 20
- 21. Business readable specifications Proprietary & Confidential 21 Business readable specifications are rooted in the problem domain. Business readable specifications make sense to everyone.
- 22. Business readable specifications Proprietary & Confidential 22 Problem Domain Solution Domain
- 23. Business readable specifications Proprietary & Confidential 23 Business readable specifications ensure that we’re all talking the same language. Business readable specifications are rooted in the problem domain. Business readable specifications make sense to everyone.
- 24. Business readable specifications Proprietary & Confidential 24 Business readable specifications provide a shared source of truth. Business readable specifications ensure that we’re all talking the same language. Business readable specifications are rooted in the problem domain. Business readable specifications make sense to everyone.
- 26. Living Documentation is your guiding light. Living Documentation Proprietary & Confidential 26
- 27. Living Documentation is your guiding light. Living Documentation Proprietary & Confidential 27 Living Documentation provides a shared view of what has been delivered.
- 28. Living Documentation is your guiding light. Living Documentation Proprietary & Confidential 28 Living Documentation provides a shared view of what has been delivered. Living Documentation always tells you when it’s out of date.
- 29. But you will fail unless you respond to what your living documentation is telling you. Proprietary & Confidential 29
- 30. Excellent collaboration Excellent code Proprietary & Confidential 30 No Short Cuts
- 31. BDD at Smartbear Proprietary & Confidential 31 Discover Example Mapping Formulate BDD scenarios Automate Cucumber, Rspec… Test and deploy CI/CD Publish Living Documentation Develop TDD Build 1 2 3 4 5 6 Define in collaboration
- 32. Thank You
Editor's Notes
- #2: Laurent will start. Views about success and failures of agile
- #5: Now you might well be sitting there thinking: “that’s a pretty… confident talk title” AINO Modern agile; XP; SAFe etc.
- #6: Let’s stick with the most common agile “methodology” Laurent will tell a story about Zephyr over the next 3 slides.
- #7: This is what Scrum promises …
- #8: But this is what you need to succeed
- #9: Seb takes over.
- #10: Same as ATDD & Spec By Example
- #11: Not a process, not a methodology, definitely NOT A TOOL
- #12: - a collection of tried and tested techniques that support individuals and interactions
- #13: 3Iterative. One story at a time. Try to start with Discovery and work your way down. You will get value from Discovery on its own. Teams often run into problems if they pursue automation on its own. Seb will tell a story about a bank that thought that BDD was synonymous with automated end-to-end testing.
- #14: This is what each practice delivers
- #15: Seb continues
- #16: We often *think* we understand what we’ve been told, but we always have to check
- #17: Slow feedback. Context switching. Rework! By banishing misunderstandings, concrete examples help us deliver more reliably
- #18: 3 Amigos. Example mapping. Note SMALLER STORIES
- #19: Seb tells his “version” story from an insurance company.
- #20: Seb to lead
- #21: Laurent will have story to share – Seb will ask him to tell it.
- #23: DDD Ubiquitous language Example of a commonly misunderstood term? e.g. Exception or Customer or Account
- #25: Story … the team where the scenarios were only written & read by testers (or BAs or PO)
- #26: Laurent will take over here… You don’t NEED to do this to succeed at BDD!
- #27: Technical discipline: let the failing specification guide the development team more automation != good automation fast feedback, so banish slow test runs have confidence in your software (BDD & TDD)
- #28: Publish your living documentation where everyone can read it & see which specifications are passing.
- #29: Publish your living documentation where everyone can read it & see which specifications are passing.
- #30: Listening to tests: If they fail, fix the documentation or the code. If they flicker, don’t ignore them – flickering tests are worse than no tests If the business (PO/BA/Customer) aren’t reading them & giving the team feedback, then they’re not delivering value. Collaborate to ensure the living document is acting as a valuable artefact (for today & tomorrow).
- #31: It takes time to get good at anything. Short cuts inevitably lead to costly rework later – in requirements, specification, or test automation. Collaboration is essential to capture requirements/specs so that they are useful to everybody (both during initial development & future maintenance) Technical discipline is essential to write maintainable code – production & test automation
- #32: Examples of tools used by Smartbear teams when doing BDD.