Book Review: Holistic Testing

Target audience

On their Leanpub page it states this book is for the following:

“If you care about quality – no matter what your specialty or role in your organization is – we think you’ll find it helpful. UI/UX designers, product owners, programmers, testers, database experts, business analysts, site reliability and platform engineers and more.”

I agree with this assessment to an extent but would say the following groups (in no particular order) would benefit most from reading this book:

• Anyone working directly with testing/QA (having this as a target focus of their role)
• Engineering Managers and Team Leads
• Tech Leads
• Senior Developers (those with influence in their teams)
• Scrum masters (maybe - I’m not as confident in this one)

Based on my experience, I think the roles above are best-placed to implement the advice and guidelines shared in this book.

My thoughts on the book

The best part of this book is that they are clear about how you can make holistic testing a team activity and how you go about shift testing to the left. Most testers (and others who work in software development I’m sure) are familiar with the fact we should test earlier because it’s cheaper to find bugs sooner rather than later, but I feel like there are very few resources that go into how to do this.

With Crispin’s and Gregory’s Holistic Testing Model, readers now have an understanding of what activities we can do to test and when.

This book then breaks down what exactly it means to do these activities and suggests resources to learn more about how to do this (in depth).

I appreciated the fact there were useful resources referred to in the book including:

• Ashley Hunsberger’s Test Suite Canvas
• Introduction to Example Mapping by Matt Wynne
• RiskStorming by Beren Van Daele
• A Practical Guide to Testing in DevOps by Katrina Clokie

And more.

Another thing I thought was well-thought through was the fact that there was some great input on potential pushback you may get in implementing some of the ideas and then some suggestions on how to handle the pushback. e.g. Visualising Flows.

The reality is there is a very real chance one can get pushback when implementing new ideas (in general, not necessarily from this book) so it’s good to see a resource out there that shows you how you can tackle this for some of their ideas.

My only criticism for this book is that I feel it would’ve benefitted from more sub-headíngs to make it more readable. There were some long paragraphs, followed by more long paragraphs.

There were also some questions in paragraphs that I felt could have benefitted from being in its own line.

This is a small criticism however and is mainly reflective of both my writing style and how I like to easily absorb information.

Overall, I really enjoyed reading this book and it’s given me some ideas to bring back to my company and now I just need to think about which idea I should start with.