What do you think?
Rate this book
Specification by Example: How Successful Teams Deliver the Right Software
Summary
Specification by Example is an emerging practice for creating software based on realistic examples, bridging the communication gap between business stakeholders and the dev teams building the software. In this book, author Gojko Adzic distills interviews with successful teams worldwide, sharing how they specify, develop, and deliver software, without defects, in short iterative delivery cycles.
About the Technology
Specification by Example is a collaborative method for specifying requirements and tests. Seven patterns, fully explored in this book, are key to making the method effective. The method has four main benefits: it produces living, reliable documentation; it defines expectations clearly and makes validation efficient; it reduces rework; and, above all, it assures delivery teams and business stakeholders that the software that's built is right for its purpose.
About the Book
This book distills from the experience of leading teams worldwide effective ways to specify, test, and deliver software in short, iterative delivery cycles. Case studies in this book range from small web startups to large financial institutions, working in many processes including XP, Scrum, and Kanban.
This book is written for developers, testers, analysts, and business people working together to build great software.
Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book.
What's Inside
Common process patterns How to avoid bad practices Fitting SBE in your process 50+ case studies For additional resources go to specificationbyexample.com.
Specification by Example is an emerging practice for creating software based on realistic examples, bridging the communication gap between business stakeholders and the dev teams building the software. In this book, author Gojko Adzic distills interviews with successful teams worldwide, sharing how they specify, develop, and deliver software, without defects, in short iterative delivery cycles.
About the Technology
Specification by Example is a collaborative method for specifying requirements and tests. Seven patterns, fully explored in this book, are key to making the method effective. The method has four main benefits: it produces living, reliable documentation; it defines expectations clearly and makes validation efficient; it reduces rework; and, above all, it assures delivery teams and business stakeholders that the software that's built is right for its purpose.
About the Book
This book distills from the experience of leading teams worldwide effective ways to specify, test, and deliver software in short, iterative delivery cycles. Case studies in this book range from small web startups to large financial institutions, working in many processes including XP, Scrum, and Kanban.
This book is written for developers, testers, analysts, and business people working together to build great software.
Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book.
What's Inside
Common process patterns How to avoid bad practices Fitting SBE in your process 50+ case studies For additional resources go to specificationbyexample.com.
249 pages, Paperback
First published June 1, 2011
About the author
Gojko Adzic
18 books145 followersGojko Adzic is a partner at Neuri Consulting LLP, winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. Gojko's book Specification by Example won the Jolt Award for the best book of 2012, and his blog won the UK Agile Award for the best online publication in 2010.
Gojko is a frequent keynote speaker at leading software development conferences and one of the authors of MindMup and Claudia.js.
As a consultant, Gojko has helped companies around the world improve their software delivery, from some of the largest financial institutions to small innovative startups.
Gojko is a frequent keynote speaker at leading software development conferences and one of the authors of MindMup and Claudia.js.
As a consultant, Gojko has helped companies around the world improve their software delivery, from some of the largest financial institutions to small innovative startups.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 63 reviews
March 11, 2019
The book offers some very good ideas and is an interesting read, but it's too repetitive to me. You keep reading the same arguments and explanations over and over again, without going into concrete examples. It would have helped if the book contained a full blown actual example of the artifacts that are produced by SBE, and not just describing what the process is.
January 15, 2013
The majority of the book is just an expansion of the praise pages typically found in USA books.
Never the book become concrete on HOW to create good test specifications.
Never the book become concrete on HOW to create good test specifications.
September 10, 2019
I agree, that ideas in this book are very repetitive. But I think it is worth to go and collect those ideas. Really recommended to read for those who has less experience in software development process.
September 13, 2017
Awesome!!!
March 8, 2016
Enjoyed this overview of a testing methodology that brings in BDD principles to automated software testing environments. It's a bit too complex for my needs, yet I love the idea of capturing everyone's opinion in specification (business owners, testers, developers, analysts) — as well as the philosophy of living documentation.
Two favorite bits:
1. Functional requirements, specs, and acceptance tests are the same thing.
2. Don't just disable failing tests — either fix the problem or move to a set of low-priority regression tests that don't run as often or alert in the same way.
Hat tip: Alister Scott.
Two favorite bits:
1. Functional requirements, specs, and acceptance tests are the same thing.
2. Don't just disable failing tests — either fix the problem or move to a set of low-priority regression tests that don't run as often or alert in the same way.
Hat tip: Alister Scott.
September 8, 2016
I was about to not finish the book at all because it the introduction was to talkative. But it started be more interesting from the chapter 4. The main message I took is to use behavior-driven development (BDD) e.g. Cucumber but not be focused on tool itself. I would appreciate examples of specification by example, which are not there.
January 2, 2012
I like the concepts in this book about having a living documentation system through testing. There are real-world, high-level case-studies, but I would like to have seen more examples of actual tests and tools.
June 8, 2020
Specification by Example is a book that brings together practices such as BDD, ATDD, etc. into one work. The recurrent theme behind it is how many teams have evolved their testing practices over time to reflect the system specification as living documentation, using tests written in abstract, high level language to that effect.
Gojko Adzic identifies 7 different process patterns that seem to be in common with the teams he interviewed for writing this book: Deriving scope from goals, specifying collaboratively, illustrating using examples, refining the specification, automating validation without changing specifications, validating frequently and lastly evolving a documentation system.
The book is intentionally written to describe this process from a high level point of view, so it doesn't really get into the "how to do it" from a technical perspective. It does comment on technical challenges the various teams he interviewed faced but that's about it.
All in all, even though the book was published almost 10 years ago it still packs a lot of goodness in it as the high level process description is still applicable nowadays. There's an appendix highlighting several tools and this is probably a dated aspect of the book.
Nonetheless, a good starting point. And feel free to skip the case studies at the very last chapter. They were fillers more than anything.
Gojko Adzic identifies 7 different process patterns that seem to be in common with the teams he interviewed for writing this book: Deriving scope from goals, specifying collaboratively, illustrating using examples, refining the specification, automating validation without changing specifications, validating frequently and lastly evolving a documentation system.
The book is intentionally written to describe this process from a high level point of view, so it doesn't really get into the "how to do it" from a technical perspective. It does comment on technical challenges the various teams he interviewed faced but that's about it.
All in all, even though the book was published almost 10 years ago it still packs a lot of goodness in it as the high level process description is still applicable nowadays. There's an appendix highlighting several tools and this is probably a dated aspect of the book.
Nonetheless, a good starting point. And feel free to skip the case studies at the very last chapter. They were fillers more than anything.
December 21, 2016
Some of this book was interesting, some of it was not so much. The first 3 chapters were rough to get through, they seemed to discuss this at such a high level in such vague language that I didn't really get a grasp of where it was all going.
Adzic interviewed a bunch of people from various companies that use Specification by Example and the book basically describes practices that these people used. Not all the companies did Specification by Example the same way, so while you are getting a bunch of different examples of how this could work, which processes you use ultimately will be up to what you want to do or are able to do.
I found process to be vaguely described at times. From the perspective of someone that is being asked to move towards using this process I would prefer some more concrete steps and ideas instead of a lot of lists of things people might do to make Specification by Example work.
That said, there were some interesting ideas in the book that I liked. The discussions about how examples can make functionality clearer, what make good specifications, and how this kind of testing is different than functional testing and unit testing were enlightening.
Adzic interviewed a bunch of people from various companies that use Specification by Example and the book basically describes practices that these people used. Not all the companies did Specification by Example the same way, so while you are getting a bunch of different examples of how this could work, which processes you use ultimately will be up to what you want to do or are able to do.
I found process to be vaguely described at times. From the perspective of someone that is being asked to move towards using this process I would prefer some more concrete steps and ideas instead of a lot of lists of things people might do to make Specification by Example work.
That said, there were some interesting ideas in the book that I liked. The discussions about how examples can make functionality clearer, what make good specifications, and how this kind of testing is different than functional testing and unit testing were enlightening.
September 23, 2022
As being said by many other readers, the book is disappointing for two reasons. First, it does not really speak about the practical aspect about how to write examples or scenarios in different situations. This is the most crucial practical question that arises when people try to implement BDD in practice. The second remark is about this surplus verbosity and repetition of the same thoughts within the narrative of the book. As a practitioner I am not really interested in interviewing other teams. Moreover if the vast majority does not follow the best practices it does not mean that the best practices do not exist. It's just a sign that professionals are in minority in this world, nothing else.
So overall, if you are seeking for a practical guideline how to deal with real-life complex cases when using Specification by Example, this book is not for you. At the same time I cannot deny that gold-seekers will certainly find some good passages and ideas in the book. The problem is that they often contradict to each other. Perhaps, this book might be of a use for some project managers who needs to be persuaded in the need to apply BDD, but I doubt even about that.
So overall, if you are seeking for a practical guideline how to deal with real-life complex cases when using Specification by Example, this book is not for you. At the same time I cannot deny that gold-seekers will certainly find some good passages and ideas in the book. The problem is that they often contradict to each other. Perhaps, this book might be of a use for some project managers who needs to be persuaded in the need to apply BDD, but I doubt even about that.
May 13, 2017
Too many software projects go to waste, exceed budgets and overshoot schedules simply because project teams do not take specific steps to understand the true business need of the client. If you are still not satisfied with your existing methods on how to best understand what your client truly requires and deliver your project to the clients satisfaction then this book gives you specific take aways on how to do it. Highly recommended read for those who manage software development projects, business analysts, testers, programmers or anybody who cares about software that truly adds value to you and your clients.
You can consider this a part 2 of Adzic's first book "Bridging the Communication Gap".
You can consider this a part 2 of Adzic's first book "Bridging the Communication Gap".
August 11, 2021
The topic is interesting and the main idea behind it is definitely helpful and sometimes inspiring. The most useful tips for me were about deriving scope from business goals and involving business people to work on a specification collaboratively.
However I find writing style of the book too talkative, repetitive and dry. I almost gave up on it while reading through the first half but then decided to continue because it still provided good food for thought every now and then.
Author makes it clear that the book is more about the concept rather than specific tools and technical implementation details, and I totally get that, but in my opinion it surprisingly lacks good examples of Specification by Example.
However I find writing style of the book too talkative, repetitive and dry. I almost gave up on it while reading through the first half but then decided to continue because it still provided good food for thought every now and then.
Author makes it clear that the book is more about the concept rather than specific tools and technical implementation details, and I totally get that, but in my opinion it surprisingly lacks good examples of Specification by Example.
January 22, 2023
I read this over a 6-month period after a lead engineer recommended it to me. He was all-in on XP and TDD and presumably saw a lot he liked about SBE.
As a product manager without a direct line of control to most of the recommendations made in the book, I found the book's main sections to be a bit of a slog. The final chapters on case studies were very interesting, though, and in the end I'm glad I took the time to survey these topics so that I can speak about them intelligently with engineers and testers.
Engineers and tech leads should find a lot of value here, and Product players should take note of the author's final admonition to go ahead and get started with living documentation rather than first incurring a bunch of trial and error.
As a product manager without a direct line of control to most of the recommendations made in the book, I found the book's main sections to be a bit of a slog. The final chapters on case studies were very interesting, though, and in the end I'm glad I took the time to survey these topics so that I can speak about them intelligently with engineers and testers.
Engineers and tech leads should find a lot of value here, and Product players should take note of the author's final admonition to go ahead and get started with living documentation rather than first incurring a bunch of trial and error.
June 8, 2017
I have mixed feeling about the book. I almost gave up to read it after first few chapters because it was too abstracted and ambiguous. Then I liked Part 2 of this book, but by the end of this part it started to be too technical for me (probably because I'm business analyst, not auto tester). Nevertheless I got some useful information from the book and do not regret that I've spent some time on it - e.g. now I have an idea what BDD is about and also some advises from this book very useful - e.g. QUPER approach for NFRs, avoiding boomerangs in backlog and others.
February 17, 2021
This is a really good read and starter for the general idea of "Specification by Example". Unlike many other books related to coding it contains not a single line of code and just a few examples how data tables and given/when/then syntax can look like.
The book is packed with real world examples and comments from active practitioners and concludes with a bit more information about the transformation of the mentioned companies.
The book is packed with real world examples and comments from active practitioners and concludes with a bit more information about the transformation of the mentioned companies.
June 23, 2017
Although this book is a bit old, I think the concepts are still valid and software projects can still benefit from Specification by Example.
I never used this approach but I am thinking about it in a future project if I can convince the stakeholders and fellow workers (development, test, business analysis) -- or I just go renegade and implement it all alone.
I never used this approach but I am thinking about it in a future project if I can convince the stakeholders and fellow workers (development, test, business analysis) -- or I just go renegade and implement it all alone.
October 18, 2018
A must-read for ATDD learners. A lot of practical but precious know-hows are introduced. Though this book was written several years ago thus some of the examples seem to be outdated, the value of this book is still high enough.
December 8, 2017
It's good to defend the concept to the development team.
September 17, 2017
Have read few first chapters. Expressed ideas are great by for me it was too abstracted.
November 6, 2017
Some practical, helpful & actionable items in this book. Didn't need to be as long as it was.
November 22, 2017
The book has a long and rather boring start but there are some interesting thoughts. Later chapters are much better.
November 28, 2017
Must-read for everyone interested on modern software development. Sets the ground and basics for every good test practice.
May 2, 2018
The content of the book is great. Covers variety of situations and case studies. The book was very dry though.
December 17, 2018
I think anyone that works in software development should read this book. If you want to understand how to bridge the gap between business requirements and technical development, start here.
June 9, 2019
It’s a great book but sometimes takes a long time repeating about the same thing. It’s a good reference about specification by example and creating user stories
February 8, 2021
One of my first readings many years ago ...
This book and others from this author, are always a good idea to read
This book and others from this author, are always a good idea to read
January 4, 2012
Often I wish I could say about some aspect of software development, literally, "let's do this by the book". Only then do I realise there is no book. It's like realising there is no spoon, except the problem can be solved by an experienced software developer, rather than the saviour of mankind. Until now, the process of capturing, formalising, and validating the high-level specification of software has been one of these inconsistently-documented problems. Gojko Adzic has changed that by structuring many successful TDD/BDD/ATDD/etc practices into a framework - the name of which is the title of the book - and informal pattern language, all phrased in terms of specifying a problem (rather than the usual language of after-the-fact testing).
This book examines the development process beginning at the point of deriving scope from goals, and ending with validating frequently and evolving a (living) documentation system.
It was with great relief that I read "I originally thought about leaving this chapter [on deriving scope from goals] out. I decided to include it for three reasons…". Creating a shared understanding of the overall goal is the most important part of specifying a problem, and one that developers hide away from at their peril. I'll look at the remaining chapters in two parts: the specification process and the automation of specifications.
Adzic recommends specifying collaboratively, and describes practices ranging from all-team workshops (where the team is new to SbE), to pair-writing and informal conversations (for mature teams or those with easy access to domain experts). I learnt from Metaphors We Live By that people think primarily in terms of prototypes, rather than in abstract categories, and so the idea of specifying by example seems inherently congruent to how we model the world. (Indeed, one practice, avoid using abstract classes of equivalence, makes this explicit.) The SbE approach is to create a clear, precise set of examples of a problem, free from technical or automation concerns, which can be easily verified by a domain expert. In TDD terms, this will "get you to red".
One a suitable specification is prepared with its examples, the challenge becomes to automate its validation. Here are more technical practices, such as automate along system boundaries, describe validation processes in the automation layer, and don't treat automation code as second-grade code. This will "get you to green". Note, however, that this is not a beginner's book, nor a technical reference. You'll need some other means to learn how to use specific specification/testing tools (Cucumber, SpecFlow, FitNesse, or whatever), and how to deal with the everyday challenges of automating acceptance testing (which are non-trivial, to say the least). There's also nothing in here about managing the development process itself, for which you'll need to consult the Agile and Lean literature.
Further practices makes it possible to validate frequently, such as find the most annoying thing, fix it, and repeat, set up a dedicated continuous validation environment and separate quick and slow tests. This will, in a sense, "get you to blue", or a well-refactored test system.
There are many reasons why I think this book is important, so I'll try to highlight the key points:
• It's nothing new - an odd form of praise maybe, but this book is a structuring of many well-understood, proven practices
• It defines a meaningful language - out with the irrelevant technical testing terms, in with the goal-driven specification terms
• It provides a framework - there's a broad process to follow, all of which is coherent with proven agile and lean principles
• It's sensitive to context - while not a rigorous pattern language, each practice is clearly described in terms of what problem it solves and where it is applicable
• It's sensitive to inexperienced teams - there is advice on not just the practices, but how to introduce them
My experience working in software is that most companies have either an ad-hoc approach to specification, or a pseudo-formal process which carries administrative demands but does little to help actually build the right thing. My hope is that Specification by Example can be a template to improve this, and reduce one of the biggest sources of routine waste in current software development. No process can be applied blindly, but by writing this, I think Gojko Adzic will open better specification and testing practices to a much wider audience.
This book examines the development process beginning at the point of deriving scope from goals, and ending with validating frequently and evolving a (living) documentation system.
It was with great relief that I read "I originally thought about leaving this chapter [on deriving scope from goals] out. I decided to include it for three reasons…". Creating a shared understanding of the overall goal is the most important part of specifying a problem, and one that developers hide away from at their peril. I'll look at the remaining chapters in two parts: the specification process and the automation of specifications.
Adzic recommends specifying collaboratively, and describes practices ranging from all-team workshops (where the team is new to SbE), to pair-writing and informal conversations (for mature teams or those with easy access to domain experts). I learnt from Metaphors We Live By that people think primarily in terms of prototypes, rather than in abstract categories, and so the idea of specifying by example seems inherently congruent to how we model the world. (Indeed, one practice, avoid using abstract classes of equivalence, makes this explicit.) The SbE approach is to create a clear, precise set of examples of a problem, free from technical or automation concerns, which can be easily verified by a domain expert. In TDD terms, this will "get you to red".
One a suitable specification is prepared with its examples, the challenge becomes to automate its validation. Here are more technical practices, such as automate along system boundaries, describe validation processes in the automation layer, and don't treat automation code as second-grade code. This will "get you to green". Note, however, that this is not a beginner's book, nor a technical reference. You'll need some other means to learn how to use specific specification/testing tools (Cucumber, SpecFlow, FitNesse, or whatever), and how to deal with the everyday challenges of automating acceptance testing (which are non-trivial, to say the least). There's also nothing in here about managing the development process itself, for which you'll need to consult the Agile and Lean literature.
Further practices makes it possible to validate frequently, such as find the most annoying thing, fix it, and repeat, set up a dedicated continuous validation environment and separate quick and slow tests. This will, in a sense, "get you to blue", or a well-refactored test system.
There are many reasons why I think this book is important, so I'll try to highlight the key points:
• It's nothing new - an odd form of praise maybe, but this book is a structuring of many well-understood, proven practices
• It defines a meaningful language - out with the irrelevant technical testing terms, in with the goal-driven specification terms
• It provides a framework - there's a broad process to follow, all of which is coherent with proven agile and lean principles
• It's sensitive to context - while not a rigorous pattern language, each practice is clearly described in terms of what problem it solves and where it is applicable
• It's sensitive to inexperienced teams - there is advice on not just the practices, but how to introduce them
My experience working in software is that most companies have either an ad-hoc approach to specification, or a pseudo-formal process which carries administrative demands but does little to help actually build the right thing. My hope is that Specification by Example can be a template to improve this, and reduce one of the biggest sources of routine waste in current software development. No process can be applied blindly, but by writing this, I think Gojko Adzic will open better specification and testing practices to a much wider audience.
September 9, 2019
Lots of good stuff for teams that haven’t implemented a truly agile process. I like the advocacy for trust between analysts, testers, and dev as well as the combined ownership of quality which leads to a shared understanding.
August 5, 2011
I'm currently trying to better understand the BDD mind set and how it might improve things on my current project so I was really excited when Specification by Example showed up in my Kindle. I was looking forward to finding a whole check list of dos and don'ts to help accelerate me to BDD nirvana. Instead, I learned that implementation of SBE is very contextual -- one size does not fit all. Different teams use different techniques. The author interviewed several teams using SBE and discovered what worked and what didn't work for them. Some teams started fresh on greenfield projects while others added SBE to existing brownfield projects. Some common themes emerge, such as don't specify at the GUI level and implement your living documentation system as soon as possible, but to really dig out the nuggets I would suggest the following. Read the book once cover to cover to get a grasp of what the teams went through. After that, scan the book again looking for the pearls of wisdom that each team offers and create your own list of dos and don'ts. From that you, should be able to get some ideas on what might apply to your current project. I enjoyed the book and feel that it offers valuable insights but readers need to be aware that some work on their part will be required in order to get the full benefit of the book. Potential readers might want to visit the book's web site for a taste of what is inside.
April 6, 2020
Gojko Adzic has taken his real-life work experience gathered over years in several different projects and turned the wisdom into a book. It's a relatively easy read, although it goes into both technical and not so technical details a lot. Together with a bunch of examples from his clients, the book can feel a bit repetitive, but there are still good ideas hidden inside.
The main takeaway for me was how important it is to nourish truly active and living collaboration during the development process between developers, testers and product owners. Make sure to always start with a customer's business goal (together with the whole team) and derive the scope from goals instead of accepting requirements as a solution. Also prepare only "just enough" examples for the user story in advance - stories that seem complete might make the team skip discussions and result in functional gaps in specifications.
Tip: The book can be quite repetitive so it even kind of pushes you to just browse it, read it from here and there and check out the highlighted parts. Each chapter ends with a "Remember" section which brings out the key takeaways.
Audience: Everyone working in a software development team, but in my opinion, it's an especially good read for product owners, QE's and developers. I would especially recommend the chapters 9 and 10 for all QE's.
The main takeaway for me was how important it is to nourish truly active and living collaboration during the development process between developers, testers and product owners. Make sure to always start with a customer's business goal (together with the whole team) and derive the scope from goals instead of accepting requirements as a solution. Also prepare only "just enough" examples for the user story in advance - stories that seem complete might make the team skip discussions and result in functional gaps in specifications.
Tip: The book can be quite repetitive so it even kind of pushes you to just browse it, read it from here and there and check out the highlighted parts. Each chapter ends with a "Remember" section which brings out the key takeaways.
Audience: Everyone working in a software development team, but in my opinion, it's an especially good read for product owners, QE's and developers. I would especially recommend the chapters 9 and 10 for all QE's.
Displaying 1 - 30 of 63 reviews