Workshop slides for #EuroTestConf

1. BDD
How to Solve Communication Problems
Rikke Simonsen - @vanilleDK - rikke@reload.dk

2. • Introduction - Me and BDD
• Exercise 1: Build a Duck
• Exercise 2: Pass the Message
• Exercise 3: Three Amigos Workshop
Workshop Agenda

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. • 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. • 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. • “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. Having conversations
is more important than
capturing conversations
is more important than
automating conversations
– Liz Keogh, @lunivore

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. Bad Example

10. Better Example

11. Build a duck using these 6 bricks.
You have 40 seconds !
Exercise 1: Build a Duck

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. • 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. 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. 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. 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. • Why did the message change?
• How could the message be stabilized?
Discuss these Questions

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. 3 Amigos

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. Exercise 3: Three Amigos Workshop

22. Exercise 3: Three Amigos Workshop

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. Use real life examples as much as
possible. Examples beats a list of
instructions every single time.

25. Books:
by John Ferguson Smart by Gojko Adzic

26. Thank you!
Get in touch: @vanilleDK or rikke@reload.dk