Review By: Mark Cole
09/28/2009Gojko Adzic goes a long way to explain how product owners, business analysts, software developers, and, especially tester roles fit in agile development. Adzic then points out that the fundamental problem in software projects is based on communication, or lack thereof. Adzic says "communication is, in fact, what makes or breaks software products." He sees the technical part of building software being taken care of by agile development and managerial processes. However, "the most important issue now is making sure that we know what we need to build" and "this problem is harder than it sounds." For instance, he brings up the telephone game where a child gets a message to convey and whisper to another child. The message goes down the line of children, and the final child tells what he heard. The message usually turns out to be quite different than the original message. In software terms, business analysts extract knowledge about requirements from customers and hand it over to developers and testers. Developers extract this information and translate it into executable code. The testers then write verification scripts to validate the results. Sometimes there can be huge communication gaps at every stage of this process which results in a big difference between what was originally requested and what actually gets delivered—just like in the telephone game.

So how do we solve these problems? How do we "ensure that requirements … are complete and correct in each iteration?" The answer is specification by example and agile acceptance testing. Specification by example is essentially done by having all roles in the project team represented at a meeting before the project starts. This team then creates user stories—brief descriptions of what "the system does for its users to help them perform their work more easily." The stories should give specific examples of requirements that need to be met and ensures that everyone in the project is speaking the same language.

Agile acceptance testing are black box tests that then use these specifications to verify each iteration showing which requirements are being met. Tools that perform these functions include FIT, Concordian, JBehave, TextTest, and Selenium, but this book is not about tools. Rather, it focuses on the ideas behind the process. It is very important to understand that requirement testing and unit testing are not the same thing at all, even though they sometimes overlap. Unit testing deals with code in a technical way to verify the inputs and outputs of programming units still match. These are written by the developers who write the code.

It is important for non-trivial software projects to have an over-arching plan that is right on the money and is understood by the entire team. Dealing in short iterations may be good from a development perspective. But if we do not know what we are shooting for and how the iterations are helping the project meet its requirements, the possibility of writing something different than what the customer originally communicated is huge. The project will miss the mark and cause huge recessions and layoffs. The chance of success is similar to the success of the kids getting the message right in the telephone game.

As a tester, this book has been quite useful to me. It explains where the roles of other people, besides developers, fit in the agile process. I believe this is an important book and is a must-read for anyone contemplating or performing in agile development.