Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Bdd - how to solve communication problems

991 views

Published on

Workshop slides for #EuroTestConf

Published in: Technology
  • Be the first to comment

Bdd - how to solve communication problems

  1. 1. BDD How to Solve Communication Problems Rikke Simonsen - @vanilleDK - rikke@reload.dk
  2. 2. • Introduction - Me and BDD • Exercise 1: Build a Duck • Exercise 2: Pass the Message • Exercise 3: Three Amigos Workshop Workshop Agenda
  3. 3. • Background in Computer Science • Former tester (and still a tester by heart) • Project manager in a small consultancy called Reload specialized in building complex websites based on the CMS called Drupal • Passionate about agile testing and Behavior Driven Development (BDD) • Organizer of the “Copenhagen BDD Meetup” The Professional Side of Me
  4. 4. • From the land of vikings and the inventors of Lego (Denmark) • Have 3 kids with autism and a bunch of other disabilities (What doesn't kill you makes you stronger) • involved in voluntary work and disability policy (Just as passionate about this as with testing) • Town councillor (yes i get scolded a lot) The Private Side of Me
  5. 5. • Bringing the team together to get a shared understanding of the problem domain • Discussing real world examples instead of abstract requirements • Creating a common language to avoid misunderstandings • Fleshing out inconsistencies and functionality gaps BDD is a Communication Tool
  6. 6. • “Given, When, Then” is just a syntax. It’s not BDD. • The value lies primarily in the conversations, not the automated tests. • The written specifications from a BDD workshop can be automated giving you automated regression tests and living documentation, but it’s just a pleasant side effect. It should not be the main purpose. BDD is not a Tool for Automation
  7. 7. Having conversations is more important than capturing conversations is more important than automating conversations – Liz Keogh, @lunivore
  8. 8. Gherkin Gherkin is a Business Readable, Domain Specific Language that lets you describe software's behaviour without detailing how that behaviour is implemented Feature: [title] In order to [achieve some goal] As a [user] I need to [make an impact] Scenario: [title] Given [some initial context] When [some action occur] Then [some observable consequence]
  9. 9. Bad Example
  10. 10. Better Example
  11. 11. Build a duck using these 6 bricks. You have 40 seconds ! Exercise 1: Build a Duck
  12. 12. • Why did you not build the same? • Does it matter that you came to different outcomes? • What determines whether the different ducks are acceptable or not? • Who should decide? • What could be done to align the understanding of the specification? Discuss these Questions
  13. 13. • Even a simple specification can be interpreted in many different ways • Our perception is influenced by our backgrounds, experiences and personal characteristics • Whether the different outcomes matter or not depends on the goal we should achieve • It’s the business stakeholders who decide if the business goal are met or not • Knowing why to build something and not only what to build - helps meeting the goal
  14. 14. It’s not complicated to build something that works. It’s much harder to build something that works as intended and that delivers the desired business value.
  15. 15. To ensure we meet the right business goal we need to understand the business domain and what the desired outcome is rather than what feature to build. Only when everyone on the team are aligned, we can all pull in the right direction.
  16. 16. 1) Stand up and form 2 lines. 2) The first person in each line gets a secret message and whispers it to the next person in line. 3) The message gets passed from person to person down the line. 4) The last person in the line says the message out loud when asked. Rule: • The message can not be repeated and can only be whispered Exercise 2: Pass the Message
  17. 17. • Why did the message change? • How could the message be stabilized? Discuss these Questions
  18. 18. • The message changed because it wasn’t allowed to repeat the message or speak it out loud. • It wasn’t possible for the receiver to ask questions to the sender about words that was not understood. • The message could be stabilized by shortening the chain from the first person to the last person. • The message could be stabilized by sharing the information with everybody at the same time and allowing them to discuss it.
  19. 19. 3 Amigos
  20. 20. Discussing examples helps exploring the domain and identifying edge cases. The discussion leads to new user stories, rules and examples and flesh out gaps and inconsistencies that has to be addressed.
  21. 21. Exercise 3: Three Amigos Workshop
  22. 22. Exercise 3: Three Amigos Workshop
  23. 23. Exercise 3: Three Amigos Workshop • Yellow notes for user stories • Blue notes for acceptance criteria • Green notes for examples • Red notes for open questions
  24. 24. Use real life examples as much as possible. Examples beats a list of instructions every single time.
  25. 25. Books: by John Ferguson Smart by Gojko Adzic
  26. 26. Thank you! Get in touch: @vanilleDK or rikke@reload.dk

×