Behaviour Driven Development, like any other dogma in software development, is a complicated beast. It's proselytized by the zealots, and abdicated by the trolls. The practical reality is somewhere in between. And the best we can do is arm ourselves with understanding.
This workshop will attempt to cut through to the core of BDD. We will learn the history and theory behind it, show the outputs of its evolving practice, and explore how to incorporate it into our current work.
BDD finds itself at the intersection of a lot of different disciplines. This is ultimately what makes it so effective, fruitful and exciting. After all, building the right software is just as important as (if not more than) building the software right.
A set of modules.
Which are covered, and in what depth, depends on disposition of participants.
Each module consists of:
- a leading question which the group will answer in a collaborative mindmap, according to their current understandings and practices; this will set the stage as well as contextualize the topic to each participant
- a look at the theory and history of the topic
- a set of examples of how it's being used in practice
-
Introduction, Overview (30m)
What is BDD, and why is it so effective?- The goal: better product, faster
- The means: communication, collaboration, automation
- The end: ownership, precision, minimal baggage
-
Feedback Loops
What does the software development pipeline look like in your organization? What are the points of feedback? How much does each point cost? How much of this cost or output is waste? Which of these parts can BDD help with, and how?- XP feedback loops
- lean flow
-
X Driven Development
Why is TDD not enough? What does TDD do really well, and where does BDD fill the gaps?- TDD
- requirements are behaviour
- tests are for behaviour
- outside in versus inside out
- outer loop versus inner loop
-
Remember Agile?
Each of the agile tenants had reasoning behind it. What were those desires, and how does BDD try to reinforce them? How do the traditional scrum roles (PO/BA, dev, test, design, PM) contribute and benefit from BDD?- cross functional teams
- collaborative process
- specifications as shared artifacts
-
The Familiar Agile Rituals
What mechanisms from agile are core contributors to the BDD practice?- user Stories
- user Acceptance Tests
- scenarios
-
Specifications
What's so significant about a specification, anyway?- given, when, then
- gherkin
-
Domain Driven Design
DDD has had significant insights into delivering software. Which concepts have proven most useful, and how do they actually look?- domain modelling
- ubiquitous language
- domain specific language
-
Design
Design is a crucial part of delivering effective software. How can formal design roles like IA, visual, and UX contribute to the shared artifacts of BDD?- information architecture
- semantic structure
- components
- mocks as specifications
-
Automation
The magic behind specifications are that they are automagically executable. How does this magic happen, and where be the dragons?- executable specifications
- imperative vs declarative styles
- pageobject pattern
- the tooling landscape: a whirlwind look at 20 tools and how they fit in the big picture
- the selenium API as a DSL
-
Documentation and Frequent Feedback
BDD documentation is not dry and boring. Rather, it's the primary source of sustenance for the whole business. What does it look like, and how is it best used?- canonical documentation
- living documentation
- single source of truth
- agile story mapping
- test execution reports
-
Agile Testing
BDD is sometimes called a tester's nirvana. Why is this so? And how does BDD embrace traditional QA functions?- test case management
- testing pyramid
- testing quadrants
- testing vs checking
- non-functional requirements as specifications
-
Process and Org Hacks
Given its breadth, BDD is often a difficult pill to swallow. What are some effective starting points? How can I shoehorn, sneak, or bulldoze BDD into an organization?- easy wins
- gateway drugs