Gojko Adzic

I just ordered the final print proof copy of my new book, Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (ISBN: 978-0-9556836-1-9), which means that the paperback will start shipping in a week or so. PDFs are immediately available.

The book is about improving communication between customers, business analysts, developers and testers on software projects, especially by using specification by example and agile acceptance testing. It is primarily intended for product owners, business analysts, software developers and testers who want to learn about agile acceptance testing and implement it. It should also prove to be interesting to project managers working on software projects, both within the implementation team and on the customer side. It is intended both for people already working with agile processes and for people who wish to migrate to them.

I’m really enthusiastic about this book because I think that it fills an important void in the market today, helping different roles look at specification by example and agile acceptance testing from their perspective and figure out how to cooperate better as a team. The book is intentionally not very technical so that business people can read and understand it. It got some really nice reviews, so I encourage you to have a look at it by downloading the sample chapters and checking out the table of contents.

The book is (again) published by my company using a print-on-demand system. It should soon appear on all major online bookshops and will hopefully be picked up by traditional bookstores as well. It is immediately available online from my new acceptance testing info portal. You can order the paperback (they will start shipping on Jan 5th) or download the PDF immediately.

One of the key things missing from a lot of places where people try to implement agile acceptance testing is working collaboratively on examples. Although this sounds as a minor issue, in fact it is one of the core practices. If it is missing, there is no way to get the full benefits of acceptance testing and teams often get disillusioned with the whole idea. Ian Cooper recently wrote about his experiences before and after introducing the workshop, concluding that “this seems to have removed a lot of the pain”. Continue Reading »

In order to get requirements, business analysts often work through a number of realistic examples with the customers, such as existing report forms or examining existing work processes. These examples are then translated to abstract requirements in the first step of the Telephone game. Developers extract knowledge from that and translate it into executable code, which is handed over to testers. Testers then take the specifications, extract knowledge from them and translate it into verification scripts, which are then applied to the code that was handed over to them by the developers. In theory, this works just fine and everyone is happy. In practice, this process is essentially flawed and leaves huge communication gaps at every step. Important ideas fall through those gaps and mysteriously disappear. After every translation, information gets distorted and misunderstood, leading to large mistakes once the ideas come through the other end of the pipe. Continue Reading »

I’m getting this question very often from web site readers, and I’ve decided to put the answer online because it deals with a crucial misconception about FitNesse and signals a really bad usage practice. The question appears in different shapes, mostly around templating or simplifying complex scripts. This is the latest version: Continue Reading »

The idea of the example-writing workshop to support acceptance testing seems to cause a lot of confusion and misunderstanding, at least judging from my two most recent talks and the questions during the discussion at the second Alt.NET UK conference. A lot of people seem to somehow contrast that to iterative development and mistake the workshop for big design up-front, expecting that it will increase the feedback loop. To resolve the misunderstanding, here is an example of how the workshop (and acceptance testing) fits into an agile process to shorten the feedback loop and improve iterative development. Continue Reading »