Embed Size (px)
Citation preview
BDDHow to Solve Communication ProblemsRikke Simonsen - @vanilleDK - [email protected]
• Introduction - Me and BDD
• Exercise 1: Build a Duck
• Exercise 2: Pass the Message
• Exercise 3: Three Amigos Workshop
Workshop Agenda
• 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
• 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
• 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
• “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
Having conversations is more important than
capturing conversations is more important than
automating conversations– Liz Keogh, @lunivore
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]
Bad Example
Better Example
Build a duck using these 6 bricks.
You have 40 seconds !
Exercise 1: Build a Duck
• 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
• 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
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.
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.
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
• Why did the message change?
• How could the message be stabilized?
Discuss these Questions
• 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.
3 Amigos
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.
Exercise 3: Three Amigos Workshop
Exercise 3: Three Amigos Workshop
Exercise 3: Three Amigos Workshop
• Yellow notes for user stories
• Blue notes for acceptance criteria
• Green notes for examples
• Red notes for open questions
Use real life examples as much as possible. Examples beats a list of
instructions every single time.
Books:
by John Ferguson Smart by Gojko Adzic
Thank you!Get in touch: @vanilleDK or [email protected]
