Wednesday Book Review: Lessons Learned in Software Testing

It's funny, I've had this book on my short list for a long time, but for some reason never got around to reading it. It was always one of those "yeah, I need to get that one and read it" but other books came and went, and I kept putting this one on the back burner. I think part of the reason is that, when I got involved with the Association for Software Testing and participated in their classes, both as a student and as an instructor, I felt it would better to get some distance from this book until I got my bearings in the class. Of course, my concern was that I wouldn't be able to give a fully objective review after knowing I was effectively teaching the very structure and mission of this book whenever I help teach the Black Box Software Testing Foundations class (or at least that particular component of it). Nevertheless, I will be impartial, honest and fair-headed about giving a truly un-biased review.

 I LOVE THIS BOOK!!! …and Cem Kaner, James Bach and Brett Pettichord did not pay me anything to say that.

 OK, with that out of the way…

 If there was ever a book that could lay the claim to being the "Software Testing Bathroom Reader", this is most definitely it. The book is organized into various chapters and each chapter has a number of individual lessons related to the topic chapter. Each item is meant to be looked at as a standalone area to ponder, and not rush through as though simply reading each chapter. What I like best about this book is the fact that the reader can skip around to whatever section they want to ponder on, and there are likely several lessons that directly impact what they might need to consider.

 This is not a "How-To" book per se. Rather, it is a collection of ideas that the authors have personally gone through and used. Many of the titles of the chapters and many of the ideas and lessons focus on the idea of context in testing. One lesson can counter-act and discredit another, simply because different situations require different approaches.
Each chapter has nuggets of wisdom relevant to its scope. Some of the lessons are brief, and some are more in-depth. The book's sibtitle is "A Context-Driven Approach" and that particular testing philosophy in seen on every page. For some, the lack of "absolutes" will be possibly frustrating, but again, I like the combination of well thought out commentary and personal experience and the recognition and understanding that, yes, in some cases you will need to do B instead of A. What's more, there are lessons where the footnotes will showcase contradictory views, proving the point that many of the methods described may work but they just as likely in some cases not. Som may find that hypocritical and double-speaking. I call that reality and accept that, at times, that is exactly what happens in testing projects.
Below is the list of chapters included:


Chapter 1. The Role of the Tester
Chapter 2. Thinking Like a Tester
Chapter 3. Testing Techniques
Chapter 4. Bug Advocacy
Chapter 5. Automating Testing
Chapter 6. Documenting Testing
Chapter 7. Interacting with Programmers
Chapter 8. Managing the Testing Project
Chapter 9. Managing the Testing Group
Chapter 10. Your Career in Software Testing
Chapter 11. Planning the Testing Strategy
[Appendix] The Context-Driven Approach to Software Testing 


In addition, there is an extensive bibliography at the end of the book, and several of the lessons include the relevant reading areas right along with the text. The bibliography alone, as far as the possible jumping off that can be accomplished and new subjects explored, is worth checking the book out of the library for. Actually reading through and "pondering" each of the topics, however, will yield the true value of this book. Some may find this comparison strange, but I think it's very apropos; "Lessons Learned" is like Scripture (put down the pitchforks, people, I'm not saying it *is* Scripture). How can I make that comparison? Just like Scriptural texts, they can be read multiple times and a different lesson is learned each time, even when you are reading the same words. Does the book morph and change? No, but your own experiences do, and at different stages of a project, or a career, or an initiative, certain lessons are going to be directly relevant and others are not. Reading "Lessons Learned" like a linear book will be of limited use, but find yourself in a situation where you are looking at a specific issue and have specific questions, it's a good bet you'll find a method or an approach somewhere in the nearly 300 lessons listed in the book.


Bottom Line:
I'm already a fan boy of the authors of this book. I consider myself an advocate for the context-driven school of testing, and actually spend my time learning and teaching others many of the ideas espoused in this book. On that basis alone, I find it tremendously valuable, but even if I didn't, I would still recommend it for the fact that it is filled with practical wisdom and little to no sales pitch. It's also nice to see just how relevant the areas in this book are almost ten years after it was published. While some new techniques have been developed and have moved onto the center stage, many of the ideas in this book remain today as excellent strategies to test and improve one's testing methods. Not everything will be relevant immediately, and the reader may have to choose which areas and which lessons are relevant for that immediate point in time. For those looking for the "one true way", this isn't the title for you. For those who realize there is no such thing as "one true way" in software testing, but lots of potentially good ways depending on what the project and process needs, you'll find a good friend in this book. Like Testing Computer Software, I can see myself turning to this book ten years from now for fresh insights, and I'm willing to bet I will get them then as well.