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.
5. Test Management | Exploratory Testing | Test Analytics | BDD and more...
QASymphony, The Complete Testing Platform
6. MagenTys
Based in the UK, 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.
8. Copyright (c) MagenTys 2017
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 Behaviour Driven 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
11. BDD Cycle
(ATDD cycle model developed by James Shore with changes suggested by Grigori Melnick, Brian Marick, and Elisabeth Hendrickson.)
12. Copyright (c) MagenTys 2017
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
16. Copyright (c) MagenTys 2017
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 apologies to Matt Wynne for shamelessly ripping off
his blog post
https://cucumber.io/blog/2015/12/08/example-mapping-introduction
18. Copyright (c) MagenTys 2017
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) MagenTys 2017
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) MagenTys 2017
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) MagenTys 2017source: Matt Wynne - https://cucumber.io/blog/2015/12/08/example-mapping-introduction
23. Copyright (c) MagenTys 2017
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) MagenTys 2017
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
26. Copyright (c) MagenTys 2017
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 |
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
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
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