Browse the Knowledge Hub211 resources
Specification by Example: is it worth reading?
The clearest account of what BDD actually is, built from interviews with fifty teams rather than from theory.
We earn nothing from any link on this page. No affiliate links anywhere in this library.
- published
- 2011
- key ideas
- 3
- reading path
- 1
Specification by Example
How Successful Teams Deliver the Right Software
by Gojko Adzic
- Publisher
- Manning
- Year
- 2011
- ISBN
- 9781617290084
Useful when you are: Practising tester, Senior / lead
Verdict
Should you read it?
Read it if
Your team is adopting BDD, has adopted it and is not getting value, or is about to buy Cucumber and call that BDD.
Skip it if
You want Gherkin syntax instruction or Cucumber mechanics. This book is deliberately not about the tooling.
The argument
What it argues
Adzic interviewed teams that had succeeded with example-based specification and extracted the practices they shared. The result is a description of a process rather than a tool: collaborative specification through concrete examples, refinement of those examples into a precise form, automation so they stay true, and treating the result as living documentation.
The central insight is that people can appear to agree completely on a general statement and diverge immediately on a specific case. Concrete examples expose that divergence while it is still cheap, which is the entire value of the practice and the part teams skip when they adopt the tooling.
It is the book to hand to anyone who thinks BDD means writing Gherkin.
Key ideas
Ideas worth taking from it
- 01
Specification by example
Derive the specification from concrete examples agreed collaboratively, rather than illustrating a written specification with examples afterwards. The ordering is the whole point.
- 02
Living documentation
Documentation that cannot go stale because it executes against the system. The genuine advantage over written specifications, which drift silently from the moment they are signed off.
- 03
The deliberate discovery conversation
The structured conversation before implementation is where the value is. Everything downstream, including the automation, is a mechanism for preserving what that conversation produced.
Criticism
What has dated, and what it gets wrong
The case studies are from 2010 and the tooling landscape has moved. More importantly, the book is optimistic about how readily business stakeholders engage with specification workshops: in practice getting that participation is the hardest part of adoption, and the book treats it as a given rather than as the main obstacle.
Reading paths
On our reading paths
Becoming an automation engineer
Book 5 of 5 · Automation and SDET
Takes automation up a level, to executable specifications agreed with the business, and explains why BDD fails when it becomes a tooling exercise.
Keep reading
What to read next
Reading about quality is cheaper than learning it in production.
QAble runs QA for products in BFSI, gaming, healthcare and SaaS, with engineers who have read these and argued about them. Start with a free QA audit.