Downloaded 25 times
Uploaded byQASymphony
Kick-Starting BDD for Your Organization
The document provides information about an introduction to behaviour driven development (BDD) workshop presented by MagenTys. It includes an agenda for the workshop that will cover the principles of BDD, the importance of examples and rules, using the Gherkin language to formalize examples, collaborative BDD processes, and automating test scenarios. The document also shares background on why organizations adopt BDD and the BDD lifecycle.
More Related Content
Similar to Kick-Starting BDD for Your Organization
Kick-Starting BDD for Your Organization
- 1. Kick-Starting BDD for YourOrganization
- 2. Our Last Webinar WatchNow at QASymphony.com/resources
- 3. Quality Jam LondonOctober11, 2017 – Details coming soon
- 4. For further information contactMagenTys http://magentys.io Thank you
- 5. Test Management |Exploratory Testing | Test Analytics | BDD and more... QASymphony, The Complete Testing Platform
- 6. MagenTys Based in theUK, our expert consultants and engineers work with small, medium and enterprise organisations to release better quality software, faster. We do this through strategic consultancy and hands-on delivery, helping our clients adopt good practice in quality enablement functions such as Behaviour Driven Development (BDD), Testing, Test Automation and DevOps.
- 7. Mike Scott Introduction toBehaviour Driven Development
- 8. Copyright (c) MagenTys2017 By the end of today you will understand: The fundamental principles of BDD The importance of Rules and Examples How to formalise examples using Gherkin The importance of a ubiquitous language Using Example Mapping Workshops The process of BDD and roles
- 9. Introduction What is BehaviourDriven Development Demo: No Change Parking Discussing the Problem Aligning interests Creating the Specification Behaviour Driven Development Lifecycle Implementing the Solution Automating scenarios Problem Specification Implementation Solution
- 10. Copyright (c) MagenTys2017 Why Do BDD? Source: thisisindexed.com
- 11. BDD Cycle (ATDD cyclemodel developed by James Shore with changes suggested by Grigori Melnick, Brian Marick, and Elisabeth Hendrickson.)
- 12. Copyright (c) MagenTys2017 What’s In A Story? The 3 C’s Card Conversation Confirmation Independent Negotiable Valuable to stakeholders Estimable Sized appropriately Testable Promotion marketplace As a marketing manager I would like a place to show new promotions So that potential customers are aware of our latest offers
- 13.
- 14. Copyright (c) MagenTys2017 The Books
- 15.
- 16. Copyright (c) MagenTys2017 BDD is Collaborative & Story-Centric PO / Customers Developers Testers Briefing Estimate Prioritise Prepare Story Title Description Priority Value Proposition Measures Estimate Sketch Notes Specification Workshop Ready A/C NFRs Key Examples Design Notes Wireframes Assumptions Refine Monitor Evaluate Review Value returned Metrics Bugs New Stories Review Build Explore Review & Demo Done Scenario Definition Scenario Automation Feature Implementation
- 17. Example Mapping With apologiesto Matt Wynne for shamelessly ripping off his blog post https://cucumber.io/blog/2015/12/08/example-mapping-introduction
- 18. Copyright (c) MagenTys2017 Specification by Example Examples Can become Tests Requirements Source: Gojko Adzic – Bridging the Communications Gap Intentions Ground common understanding Reduce ambiguity and handoffs Single source of truth Target for development
- 19. Copyright (c) MagenTys2017 Holding a conversation about a story Example mapping Brings together 3C’s: Card, Conversation & Confirmation Uses cards to structure the conversation Provides concrete examples for confirmation Is quick and low-tech
- 20. Copyright (c) MagenTys2017 How It Works 1. Write the story on a yellow card 2. Write each rule/acceptance criteria on a blue card 3. Write examples on green cards under each rule 4. Write any questions on red cards 5. Keep going until everyone understands the story 6. Stop after 30 mins source: Matt Wynne - https://cucumber.io/blog/2015/12/08/example-mapping-introduction
- 21. Copyright (c) MagenTys2017source: Matt Wynne - https://cucumber.io/blog/2015/12/08/example-mapping-introduction
- 22.
- 23. Copyright (c) MagenTys2017 Refining The Specification Specification Workshops Use example mapping to identify and create examples for key scenarios No need at this stage to elaborate exhaustive list of scenarios Just enough to ensure specification is understood by all Scenario Definition Work through and refine key examples without changing the intention Add additional scenarios to build coverage Add edge cases and exceptions Formalise language using Gherkin
- 24. Copyright (c) MagenTys2017 Business Facing, Scenarios What makes a good Scenario? Self-documenting About business intentions Concise and granular A specification not a script Anyone can understand it Based on testable statements
- 25.
- 26. Copyright (c) MagenTys2017 Example Feature: Driver Can Pay By Credit Card In order to avoid having to use coins in a parking meter As a driver I want to be able pay for my parking by credit card Business Rules: To pay for parking, a Driver must give their Vehicle Registration and Credit Card Number A vehicle is considered not paid for if it is not on the current payments list Once paid, the vehicle is logged on the Payments list Scenario: Once paid, a vehicle appears on the Payments list Given The following payments list | Vehicle | | Car6 | | Car7 | When We get a new call from driver 'Dave’ And He pays to park 'Green Polo' with a valid credit card Then the payment should be accepted And the payments list should show | Vehicle | | Car6 | | Car7 | | Red Polo |
- 27.
Editor's Notes
- #11 Traditionally reqts take something quite specific and abstract to general rules – problem with doing this is that all rules have both exceptions and assumptions built in. Need to keep stories well formed and SMART (see also IEEE stds) INVEST = Bill Wake, 2003 blog. 3 C’s = Ron Jeffries Card = physical medium (not the whole story) Conversation = therefore conversation is critical (spec workshop) Confirmation = tests that prove the acceptance
- #13 Traditionally reqts take something quite specific and abstract to general rules – problem with doing this is that all rules have both exceptions and assumptions built in. Need to keep stories well formed and SMART (see also IEEE stds) INVEST = Bill Wake, 2003 blog. 3 C’s = Ron Jeffries Card = physical medium (not the whole story) Conversation = therefore conversation is critical (spec workshop) Confirmation = tests that prove the acceptance
- #17 We look at implementation from the perspective of a given unit of change, e.g. user story, because we drive each unit to done. Applying agile testing and TDD principles we go from initial conversations through specification workshops to flush out enough details of