Learn more Download now Browse your favorite restaurants Shop now Shop now flip flip flip Shop now Learn More Shop now Shop now Shop now Learn more Shop Fire Shop Kindle Learn More Shop now Shop now Learn more

Customer reviews

4.3 out of 5 stars

on 7 November 2011
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.
24 people found this helpful
|11 Comment|Report abuse
on 27 October 2011
This book is great.
While as other reviewers have noted, it does not say anything "new" from a technical perspective, this is a great "glue it together" book, which focuses on bringing together the ideas of continuous integration while developing, and starting with example-based acceptance test driven stories and requirements to drive customer value and success in projects.
This is not a technical book, and reads simply and straightforwardly. To be honest, to such a point, that at the beginning, I was saying to myself "So what? I know all this" - but the great joy of the book is that it leads by example by using examples (case studies) to explain how to go about making the idea of continuously developed specification and test harnesses actually take root and flower within an organisation. As with all great user stories, it gives you the context and the criteria to prove success.
I would recommend reading this book with "Test Driven" (also Manning) and "the RSpec Book" (Pragmatic) to complete out a full, detailed view - and probably also recommend reading it with a decent requirements book (Wiegers), and a decent agile methodology book if you are starting out, as these will help you to flesh out the ideas within (maybe even "the Secret Ninja Cucumber Scrolls" for a Cucumber approach (wink)).
If I have but one criticism, it is that I do not recall an example for my situation - trying to influence multiple development suppliers to take on this approach (i.e. delivering to a central corporate client managing application delivery and support). Maybe the next update will contain this...
If I have but one piece of praise to single out, it is that I used the book just yesterday to talk about using some of the ideas contained within to improve reliability on a legacy system. I think "I use it" is the highest piece of praise you can give to such a book.
4 people found this helpful
|0Comment|Report abuse
on 26 October 2011
The book is very helpful in emphasizing how important it is to understand customer requirements and how to get it implemented so it meets the customer's needs.
The author is very ambitious in defining new terms for terminology already given by others in the field of software development processes. But as the author puts it: Terms are not so important. It's the way how you live the process especially the requirements and testing process. How you name it is secondary and may be 3% of importance.
Good cooperation and open communication are most important part when developing software.
Living documentation is another identified key factor for success of software projects which is described in the book. Documentation is usually out of date as requirements change.
In Specification By Example the author describes the concept of executable specifications which are automated tests that read like documentation.
This kind of documentation is always up to date, because it's run daily against the software to test it.
I personally also love the idea that you should define the scope with the customer. Customers mostly have solutions in mind when they talk to a software company. Finding out what the customer's goals are and maybe even how to save the customer money is a key requirement for software companies these days.
Do not blindly follow customer requirements but consulting them. We have to thank Gojko Adzic
for putting together the experience made by over 50 companies around the globe when developing
software and writing it down in this well-organized book.
6 people found this helpful
|0Comment|Report abuse
on 19 October 2011
This is a great book, very readable and, with a wide range of case studies, illuminates how by making the specification and testing of a system a collaborative responsibility which extends beyond the development team to the whole business can lead to a more productive environment. While hopefully nothing in the book should be completely new to most developers (TDD, BDD, AATDD) the focus is not on the mechanics of writing tests in a particular language or framework but rather how various people interactions can be leveraged to ensure that desired behaviour, appearance, performance and general scope can be delivered, matching or exceeding the expectations of business and customer.

For teams trying to demonstrate that Agile is a viable methodology for their company reading this book is a must!
One person found this helpful
|0Comment|Report abuse
on 18 October 2011
This book builds on the themes started in "Bridging the Communications Gap" and it too remains largely non-technical, focusing on the principles and practices rather than tools (other than a whiteboard!). Whilst Specification by Example has emerged primarily from agile roots, this book sensibly focuses on the value of the technique irrespective of the overall process you employ to build software. As a result it will be useful to all practitioners regardless of their knowledge of agile.

I thoroughly recommend this book to anyone striving to build valuable software solutions for their customers.
2 people found this helpful
|0Comment|Report abuse
on 10 October 2011
What I like most about this book is that it is drawn from real-life experiences. Over fifty real-life experiences - not a couple but fifty plus. That's a lot of experience and war stories to be drawn upon and actual experiences rather than dry theory or made up examples is invaluable.

Gojko does a great job in putting all these stories and experiences together to make a coherent framework for others to use.
One person found this helpful
|0Comment|Report abuse
on 4 October 2011
When I am asked what's the next big thing in the Agile space, I introduce Gojko's work on Specification by Example. One of the statements in the Agile Manifesto from 2001 was that we prefer "Working Software over Comprehensive Documentation". Traditionally, people have created a myth out of that, that Agile is "no documentation".
In my view, with this book, Gojko has gone the extra mile (or perhaps 100 miles) and shares lots of great insight backed by plenty of experience (including his own) from all over the world which reinforces that that myth couldn't be any more wrong and creates a wonderful convergence between Software, Documentation and Testing.
This book addresses the problem that several projects out there have with their automated tests that become un-maintainable over time, or very expensive to maintain. I have heard the term "death by test automation" used in the past by Gojko himself. :-)
To people learning about Agile and wanting to learn it 'the right way', I used to always recommend Gojko's previous book (Bridging the Communication Gap). I have now added Specification by Example to my list.
2 people found this helpful
|22 Comments|Report abuse
on 30 September 2011
The thing you most need to understand about this book and which compels you to buy it is that no matter what types of agile techniques or diciplines you are doing, or want to do. This explains all of the common connectors that make them successful.
For example, you can have user stories or specifications or requirements or gather information in any number of ways but the key to gaining the most value from your automated tests is to automate them literaly. This and many other key things are defined and explained within. There are so many a'ha moments contained within just waiting for you to read it. I have had this book within reach since it arrived and it has paid for itself many times over. I cannot recommend it highly enough. If you contribute to making software in any form, you will benefit from reading this book.
|0Comment|Report abuse