Critical Testing Processes: A Book Review
Author: Rex Black
Publisher: Addison-Wesley
Published: 2003
This is a book I bought and started reading years ago. I put it aside, but recently picked it up again. The reason I wanted to read it: I had been asked by a customer to review a test strategy document.
Working through that document, I found many similarities with the processes described in this book.
TL;DR:
- The book is heavy on processes (unsurprisingly, given the title)
- Lots of useful advice when running a separate testing organization / department
- Not very useful for teams working in an Agile environment
- Too long-winded for the content it provides
I recommend this book for anyone interested in how separate testing departments and agencies work.
Thoughts and Opinions
Agile or not?
The book is written from the perspective of a separate testing organization. At the same time the fictional case study illustrated throughout the book pictures a separate testing department for an "Agile" development team.
"Agile" in quotation marks: Work is done in iterations and the software built incrementally, but ...
- All requirements are gathered upfront
- The team is not cross-functional
- The project is managed in a traditional way
- ...
I don't, per se, have a problem with the setup in the case study, because you encounter a lot of software projects like that in the real world. However, the processes described in the book do not align well when Agile is done the way it is intended. The agile manifesto spells it out quite clearly:
- Individuals and interactions over processes and tools
- Responding to change over following a plan
While the book pays lip service to changes in the case study, the very nature of the processes described makes it hard to adapt to changes quickly.
IMO, the book is ill-suited for modern software development teams, where cross-functionality and adaptability are key. The author, on multiple occasions, even discourages embedding testers or collaborating closely with developers (even on topics like debugging).
The processes are, though, useful for separate testing organizations, especially when working on more traditional projects using V-Model or Waterfall approaches. It is also a useful resource when compliance with standards like ISO has to be proved, when all testing effort has to be budgeted and accounted for, when rich documentation is demanded.
Length and Depth
The book is quite long: over 500 pages, not counting introduction, glossary, index, appendices, etc.
It could have been shorter.
The writing style is very verbose, and I got the feeling more than once that I was not reading a book, but a homework assignment for a university course, where the student had to fill a certain number of pages.
The writing style is also very dry. Yes, software test management is maybe not the most exciting topic. But a more engaging writing style would have made the book easier to read.
I encourage everyone interested to read "On Writing Well" by William Zinsser. It is a book on non-fiction writing, and it is a joy to read.
What I learned
Chapter 2 describes risk-based test management. We are introduced to FMEA (Failure Mode and Effects Analysis) as a way to identify and prioritize quality risks.
I since used this in a real-world project.
So this chapter in particular gets a huge thumbs up from me.
Unfortunately, that's about it. Maybe I have read too many books on test management already, but I have not learned much from the other chapters.
Who should read this book?
- Test managers working in separate testing organizations on traditional projects will find useful advice and processes in this book.
- Anyone interested in traditional test management
Conclusion
Personally, I did not enjoy reading this book. It is simply too long for what it covers. I do not regret reading it, though, because I made it a personal project of mine to study books on software development from the late 90s and early 2000s.
It embodies much of the early discussion on Agile software development and the struggle between traditional and modern approaches.
If you have read this book, I would be interested in your opinion. Feel free to reach out!
You can find the contact information in the website's footer.
