BDD can help save Agile by facilitating three main outcomes: shared understanding, business readable specifications, and living documentation. BDD involves discovering business needs through workshops, formulating examples and scenarios in a business-readable way, and automating tests to create living documentation that ensures everything continues to work as intended. Practicing BDD improves collaboration, delivers working software based on business needs, and guides development with up-to-date documentation.
2. Laurent Py @py_laurent
VP of Products - SmartBear
Seb Rose @sebrose
BDD Advocate - Smartbear
Presented by
3. Agenda
Shared understanding
What is BDD?
Business readable specifications
Living Documentation
Proprietary & Confidential
3
Does Agile really need saving?
16. Shared understanding
Proprietary & Confidential
16
Shared understanding matters because
ignorance is the bottleneck.
Shared understanding matters because software is made by people.
18. Shared understanding is a team sport because
everyone has a unique perspective.
Shared understanding
Proprietary & Confidential
18
Shared understanding matters because ignorance is the bottleneck.
Shared understanding matters because software is made by people.
21. Business readable specifications
Proprietary & Confidential
21
Business readable specifications are rooted in the
problem domain.
Business readable specifications make sense to everyone.
23. Business readable specifications
Proprietary & Confidential
23
Business readable specifications ensure that we’re
all talking the same language.
Business readable specifications are rooted in the problem domain.
Business readable specifications make sense to everyone.
24. Business readable specifications
Proprietary & Confidential
24
Business readable specifications provide a
shared source of truth.
Business readable specifications ensure that we’re all talking the same language.
Business readable specifications are rooted in the problem domain.
Business readable specifications make sense to everyone.
26. Living Documentation is your guiding
light.
Living Documentation
Proprietary & Confidential
26
27. Living Documentation is your guiding light.
Living Documentation
Proprietary & Confidential
27
Living Documentation provides a shared view of
what has been delivered.
28. Living Documentation is your guiding light.
Living Documentation
Proprietary & Confidential
28
Living Documentation provides a shared view of what has been delivered.
Living Documentation always tells you when
it’s out of date.
29. But you will fail unless you respond to what
your living documentation is telling you.
Proprietary & Confidential
29
Laurent will start.
Views about success and failures of agile
Now you might well be sitting there thinking: “that’s a pretty… confident talk title”
AINO
Modern agile; XP; SAFe etc.
Let’s stick with the most common agile “methodology”
Laurent will tell a story about Zephyr over the next 3 slides.
This is what Scrum promises …
But this is what you need to succeed
Seb takes over.
Same as ATDD & Spec By Example
Not a process, not a methodology, definitely NOT A TOOL
- a collection of tried and tested techniques that support individuals and interactions
3Iterative. One story at a time.
Try to start with Discovery and work your way down.
You will get value from Discovery on its own. Teams often run into problems if they pursue automation on its own.
Seb will tell a story about a bank that thought that BDD was synonymous with automated end-to-end testing.
This is what each practice delivers
Seb continues
We often *think* we understand what we’ve been told, but we always have to check
Slow feedback. Context switching. Rework!
By banishing misunderstandings, concrete examples help us deliver more reliably
3 Amigos. Example mapping.
Note SMALLER STORIES
Seb tells his “version” story from an insurance company.
Seb to lead
Laurent will have story to share – Seb will ask him to tell it.
DDD
Ubiquitous language
Example of a commonly misunderstood term? e.g. Exception or Customer or Account
Story …
the team where the scenarios were only written & read by testers (or BAs or PO)
Laurent will take over here…
You don’t NEED to do this to succeed at BDD!
Technical discipline:
let the failing specification guide the development team
more automation != good automation
fast feedback, so banish slow test runs
have confidence in your software (BDD & TDD)
Publish your living documentation where everyone can read it & see which specifications are passing.
Publish your living documentation where everyone can read it & see which specifications are passing.
Listening to tests:
If they fail, fix the documentation or the code. If they flicker, don’t ignore them – flickering tests are worse than no tests
If the business (PO/BA/Customer) aren’t reading them & giving the team feedback, then they’re not delivering value. Collaborate to ensure the living document is acting as a valuable artefact (for today & tomorrow).
It takes time to get good at anything. Short cuts inevitably lead to costly rework later – in requirements, specification, or test automation.
Collaboration is essential to capture requirements/specs so that they are useful to everybody (both during initial development & future maintenance)
Technical discipline is essential to write maintainable code – production & test automation
Examples of tools used by Smartbear teams when doing BDD.