BDD - Collaboration & Hands-on practices
•Download as PPTX, PDF•
0 likes•598 views
This document discusses Behavior-Driven Development (BDD) and how it can help deliver valuable software quickly by focusing on business value and user behavior through techniques like ubiquitous language, living documentation, and specifying examples. It provides tips for implementing BDD, including defining requirements and acceptance criteria, writing scenarios, test automation approaches, and ensuring business involvement. The document emphasizes that BDD is not restricted to any one layer or framework, and can be applied to both user interfaces and APIs.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to BDD - Collaboration & Hands-on practices
Similar to BDD - Collaboration & Hands-on practices (20)
More from MagenTys
More from MagenTys (8)
Recently uploaded
Recently uploaded (20)
BDD - Collaboration & Hands-on practices
- 1. BDD – Collaboration & Hands-on practices Kostas Mamalis Principal Engineer – MagenTys
- 2. “The most important problem that we face as software professionals is this: If somebody thinks of a good idea, how do we deliver it to users as quickly as possible?” - “Continuous Delivery” book
- 3. ➜ Ubiquitous Language ➜ Focus on business value ➜ Living Documentation ➜ Specifying By Example How does BDD come to the picture?
- 4. ➜ Because we have to deliver ‘software that matters’ – Agile Manifesto Why do we need to focus on software behaviour
- 6. “Here’s the water you’ve asked for, sir!”
- 9. The Power of the 3 voices The Voice of the Solution The Voice of Quality The Client’s Voice
- 10. It’s all about:… And Scenarios of course!
- 11. Who writes the Scenarios and When?
- 13. A few tips & ideas
- 14. Definition of Ready & Definition of Done - Definition of Ready - Definition of Done - 2 parallel boards
- 15. Acceptance Criteria & Example Mapping - Acceptance Criteria – how are they related to Scenarios? - Example Mapping - How about Non Functional Requirements/Criteria? - Automation is not always the outcome of a Specification session - Team Rotation?
- 16. Roles - Do we need Developers in Test? - We are all developers - Testers you are still needed!!!
- 17. • What happens when business are not as involved into your processes? • Product Owner/Business Analysts are a catalyst to the BDD process • Unit & Integration Tests, then Acceptance Business Involvement + Test-First Maturity
- 18. Test Pyramid (no Ice-Cream cones please!)
- 19. - BDD describes behaviour - BDD doesn’t need UI - BDD doesn’t restrict on one layer of your system - You can do BDD with xUnit frameworks - Unit + Service tests with Test Doubles - Drive majority of tests from API - How about SPAs? I’m a full-stack developer, can I do BDD?
- 20. “Given, Given, And, Then, When, Then…” How about Fluent APIs then? What if Gherkin language gets in the way?
- 21. MISSION PATTERN A pattern for Fluent APIs: http://magentys.io/blogs Place your screenshot here https://dzone.com/articles/mission-pattern-a-means-to-modularise-automation-c
- 23. Thanks! You can find me at: @mamalisk http://kostasmamalis.com http://magentys.io/blogs/
Editor's Notes
- By Jez Humble and David Farley
- At the end of the day we want to deliver exactly what the customer needs. I can bring you water that can quench your thirst, but delivering the water this poor man needs to face the calamity which stroke upon him… well that’s a different matter altogether. How can we avoid these sort of misunderstandings, how can we bridge the communication gap. The prevailing answer that BDD actually advocates is:
- At the end of the day we want to deliver exactly what the customer needs. I can bring you water that can quench your thirst, but delivering the water this poor man needs to face the calamity which stroke upon him… well that’s a different matter altogether. How can we avoid these sort of misunderstandings, how can we bridge the communication gap. The prevailing answer that BDD actually advocates is: