Book Reviews
Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory
ISBN:
978-0321534460
Publisher:
Addison-Wesley Professional
Pages:
576
The ever increasing focus on software testing may be the single most valuable contribution from the agile community. Development methodologies like Test-Driven Development (TDD) are now mainstream and the quest for further automation goes on. Complete systems are developed, driven by high-level test cases. The resulting applications are delivered with extensive regression test suites. And on the way, the test cases serve as an excellent communication tool. Done right, test automation enables an interesting and efficient way of working. Surprisingly, one of them is that valuable time spent on manual testing may be both more focused and increased. On several occasions I've also experienced how non-trivial features may be implemented rather late in the projects. Unfortunately I've also experienced several pitfalls of both testing practices and test automation. And since I spend a significant amount of my professional (=paid) time on test automation, I've been looking forward to read Agile Testing for a while now. My verdict may come out hard, but I do see serious issues with the book.
Let me start with the writers. There's no doubt that both Lisa and Janet know their subject. The ease with which the different topics are treated and communicated hint at a deep understanding of both test and agile practices. I would welcome the opportunity to work with them. I'm sure I would learn a lot. Both writers have a background in the XP community. And the XP culture permeates virtually every topic. If I were to generate a word cloud from the text, I'd bet that emotions like fear and virtues like courage would gain a significant prominence. In my opinion it weakens the material. Resistance to "new" ideas and contradicting arguments are frequently dismissed as fear. For a typical example, check out page 44. Here, the authors discuss the barriers to successful agile adoption by QA teams. It's an interesting topic, but any constructive discussion is strangled with sentences like "Testers cling to the concept of an independent QA team for many reasons, but the main reason is fear". I do believe that it's attitudes like this that hinder self-improvement and kills every opportunity for constructive discussions. I mean, who could argue once the label of a basic survival mechanism is put on your argument? It's just not helpful.
I do wish I just pulled that sentence out of context because there's is good material in the book. The problem is that the material is a wild blend of practices ranging from innovative and useful to downright contra-productive. Unless the reader is fairly experienced, there's no easy way to sort them out since everything is delivered with conviction and without any data to back up the claims. The book recommends practices that only work in a certain context, like pairing, and others that are littered with psychological traps like planning poker. At best these later practices only waste time. At worst, they serve as a path to demotivation although paved with good intentions.
The book has the occasional nuggets of gold laying around. The chapter on metrics was genuinely useful and several of the discussions around communication are quite good. But I cannot recommend the book. The agile dogma hides the precious advices. Agile in itself doesn't deliver value on time. Skilled individuals with domain knowledge that collaborate efficiently within a context that supports continuous learning do. And there's really no short cut. Agile practices may, and frequently do, facilitate these qualities. But they are no end in themselves.
Reviewed May 2012
