BDD - Collaboration for Continuous Delivery
•Download as PPTX, PDF•
1 like•257 views
This document discusses Behavior-Driven Development (BDD) and how it can help deliver working, tested software quickly through collaboration. BDD focuses on specifying software behavior through scenarios written in a ubiquitous language. It emphasizes delivering features with business value. The document provides tips on how to implement BDD, including defining requirements and acceptance criteria, assigning roles, involving business stakeholders, and testing at multiple levels from units to APIs. It also addresses how to apply BDD when not using Gherkin through patterns like fluent APIs. The overall message is that BDD, through collaboration and specification-driven development, can help continuously deliver high quality software that matters to customers.
Recommended
More Related Content
What's hot
What's hot (17)
Similar to BDD - Collaboration for Continuous Delivery
Similar to BDD - Collaboration for Continuous Delivery (20)
Recently uploaded
Recently uploaded (20)
BDD - Collaboration for Continuous Delivery
- 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. ➜ Because we have to deliver ‘software that matters’ – Agile Manifesto ➜Because BDD “describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters”. Why do we need to focus on software behaviour
- 4. ➜ Ubiquitous Language or DSL ➜ Focus on business value ➜ Living Documentation ➜ Specifying By Example How does BDD come to the picture?
- 5. In order to _________ As a __________ I want ___________
- 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. BDD Dashboard MagenTys toolset for Less boilerplate code, More meaningful reporting
- 24. - Collaboration, Collaboration, Collaboration - Drive your tests using Specifications, don’t automate after - Use Cucumber/Jbehave etc. when it’s meaningful for your project. - Fluent APIs can help you apply BDD - It’s all about continuous quality-focused delivery of software that matters The message is…
- 25. Thanks! You can find me at: @mamalisk http://kostasmamalis.com http://magentys.io/blogs/
Editor's Notes
- By Jez Humble and David Farley. Agile Delivery.
- Every domain comes with its own jargon. And let’s be honest. When we first arrive in a new company with a completely new for us domain, banking, e-commerce retail, we hear all these terms floating around, we try to find glossaries to give us humble developers an insight with regards to what people mean when they say this or that, and quite often we realise that some terms are convoluted and overloaded or misused. It’s quite important to establish a Ubiquitous Language tailored to our Domain, so a DSL.
- And we arrive at User Stories. How many people have been involved in writing user stories. I’ve seen this sort of structure but it misses one important element. When something happens, I want this to happen, so I can to that, buy something with a discount etc. etc. (When, What and Why). It also focuses too much on the test case rather than the business value. In order to deliver this value, this feature which is pretty cool and useful to the end user, As a particular user, or role (frequent user etc.) I want this. One
- 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:
- Agile teams have to be the loudest teams on the floor. Do you agree with this statement? Nothing replaces face to face, immediate direct human interactions. If it’s not possible, alright skype them, instance messaging, use slack. Constant collaboration. Actually this is the prevailing message of BDD. Collaborate as much as you can so that you can be 100% sure that you delivery the right software the right way. As opposed to Automation, Automation, Automation. Automation is a by-product of this process. Collaboration is the pivotal concept here. How often should we collaborate then?