Specification by Example: How Successful Teams Deliver the Right Software

Specification by Example is Gojko's third book on this subject. The first book, Fitness.net, was very technical and tool oriented. The second book, Bridging the Communication Gap, was a lot more coordination oriented. Now his third book, this one, he describes practices that teams he studied have used. From that perspective, this book is the follow-up of Bridging and might go a little fast if you are totally unfamiliar with the subject.The book is divided in three parts. The first part is mainly introduction where Gojko describes the benefits and the key practices that will be described in this book. The second part is the actual description of the key practices and the third part are different case studies about different teams in different companies that have adopted specification by example.The key practices that are introduced in part one and described in part 2 are:- Deriving scope from goals- Specifying collaboratively- Illustrating using example- Refining the specification- Automating without changing the specification- Validating frequently- Evolving a documentation systemDeriving scope from goals discusses how customers main concert is not the software but solving a problem and developers shouldn't just expect to get the requirements from the customer but work together with them to help them to solve their problem in the best way. Specifying collaboratively covers how the customer and the teams will cooperatively define the specifications that the team will be implementing later. Illustrating using examples explains how these specifications can be described best by moving from abstract requirements to concrete examples. Refining the specification then takes the essence out of the requirements and describes them in the clearest possible way. After that, the specification can be automated without changing the specification and this chapter gives tips on how to do that. When the specifications are automated, you want to run them frequently which is described in the validate frequently chapter. Evolving a documentation system describes how the specifications become the documentation of what the system does. They stay in-sync with the system because they are continuously executed.The third part described a couple of case studies of companies that implemented specification by example. I really loved these case studies and they were written very well.I've read both of Gojko's earlier books and had high expectations for this book. I was not disappointed, it is an excellent follow-up and will be my standard book reference on Specification by Example (or A-TDD as it is also called). The book is not perfect though. As times I felt there was too much focus on documentation and too little on collaboration. Still, I'd rate this book five stars and recommend everyone in an Agile development team to read this and practice specification by example.

The heart of the practice Specification by Example is the unification of specifications and tests. This unification guides development teams to avoid several of the common anti-patterns in software development; like testing bolted on at the end, and documentation getting out of sync with the implemented functionality.The book Specification by Example is the result of drawing experiences from how a number of actual project teams work with the practice Specification by Example. This makes the book particularly valuable, since its advice in not solely based on theories or opinions on how develop software, but it distills experiences of what has actually worked in different situations and in different domains.The ideas of the practice Specification by Example have been in use for some time now, under different names like Acceptance Test-Driven Development, Agile Acceptance Testing and Behavior-Driven Development. The author chooses in my mind a sensible terminology for the practice itself and its different parts, or process patterns to use the authors term.The book has two main parts, the description of the process patterns of Specification by Example, and a set of case studies of project that uses Specification by Example. In addition the book contains an introduction to the practice of Specification by Example and guidelines on how to introduce the practice in organizations.These process patterns of Specification by Examples are described together with tips about "does" and "don'ts". The case studies part of the book contains six case studies covering a diverse set of domains.As a software developer that was "test infected" 10 years ago, a think that the practice Specification by Example, essential for successful and efficient software development. I think this book is the best book on the market today, for learning and adopting the practice Specification by Example.

This book describes one kind of a “holy grail” for software requirements, test automation and documentation: Stakeholders and developers in collaboration derive requirements from business goals, specify them through examples and automate their validation thus creating a living documentation of the system.A must read for everyone building non-trivial systems with long life spans! Some downsides (I’d given 5 stars without these):- Although the case studies were very interesting, their reporting in the book was a bit shallow. I would liked to have seen more details and in-depth analysis of each case.- As it says in the book, one of the best ways to learn to write good specifications is to study good examples, I expected to see more examples of specifications and wanted to see what the specs the teams in the case studies were creating look like.- Although this book isn’t about tools, I would liked to have seen some kind of sketches or diagrams of the development / test / build / documentation environments the teams build in the case studies. I also think that the hierarchy or structure of the specs (e.g. epic-feature-story) would be one important topic to discuss about.

This book is a tragically missed opportunity to sell Specification by Example into organisations.Whilst brimming with "good ideas", Specification by Example ironically seems to lack the very thing that would make it more useful i.e. examples. Instead, the author, Gojko Adzic, relies on a series of quotes and opinions from interviews with research subjects in organisations that he identifies have adopted these practices. This is fine if you already "get" what the practices are about, but it doesn't really teach you how to go about doing it. Consequently, it's not a particularly engaging read.One of the things that niggled at me throughout the book was the assertion that the primary goal is to automate your acceptance tests. He then goes on to suggest (from his research anecdotes) that this is actually very hard to do in a maintainable way. From personal experience, I would agree with this. So why set your readers up to feel they've failed?My own experience has lead me believe that you don't have to automate your acceptance tests to get value from Specification by Example. Simply having requirements that stand up to the scrutiny of testing adds significant value and is something I have explored successfully with a number of teams. This has lead these teams to automate certain tests where appropriate and leave others to the domain of manual or exploratory testing.The supporting practices explored in this book (including TDD and automated testing) are a hard sell in most organisations as there is a perception that they slow down delivery. Whilst this is an obvious over-simplification, the counter argument needs to be presented in more management-friendly language than is used here. A series of simple case studies would be more compelling than the quotes and vox-pops favoured by the author.

This must be the best software development book without any code I've ever read in my entire career. It's a great guide on how to deliver the RIGHT software since that is different from delivering the software right - one is a solution the customer actually needs, the other one a polished solution which nobody needs and doesn't solve the underlying problem.

This is a great book to help to specifying requirements to small and huge software

This is THE book on BDD. Gojko explains how to form great habits and shares experiences from lots of teams and different perspectives.

Very easy to read, helps you change perspective on how to run effective Backlog refinement with Spec by example workshops