Taking Testing Seriously by James Bach and Michael Bolton

Estimated reading time is 5-6 minutes.

Draft

This post is a draft. Please come back in a week or two and it will be updated.

I try to write at least one blog post every month. For months where I fail to meet even that very low bar, I publish whatever I have at the end of the month. I do my best to finish the post as soon as possible. Usually in the next few days, or weeks.

Introduction

I have been reading James Bach’s blog for years, if not decades. The same is true for Michael Bolton’s blog. (I met Michael Bolton, not once, but twice! The first time in 2018, the second time in 2025.) In late 2025 James Back published a blog post 55 Months, 1 Day, announcing his new book. The book is a collaboration with Michael Bolton. (I could not find a blog post announcing the book on Michael Bolton’s blog. The only thing I found is Taking Testing Seriously: The Rapid Software Testing Approach.)

I was very excited to read the book. I think I bought it on the very day it was published. I have been reading it almost every day for about thirty minutes. I might be one of the first people that have read the book.

The book

The book has four parts, twenty two chapters and four appendices.

The first eight chapters are written mostly by James Bach. From chapter nine until the end of the book, each chapter is written by a different author or authors.

Chapters seventeen and eighteen are transcripts of interviews Michael Bolton had with a couple of people.

Appendices are unattributed, so I assume they are written by the main authors, Bach and Bolton.

It’s a very strange book format. I don’t think I’ve read a book that combines so many different styles and authors. Maybe Bach and Bolton submitted the first eight chapters (and appendices) to the publisher and they told them the book is too short. So, they added more chapters written by other people. Maybe they wanted this format.

Book Clubs

I have started not one, but two book clubs about the book. One for Testival (see Testival Meetup #78), one at work. Each club has met once so far. Both clubs plan to meet at least one more time.

I love book club meetings. I had great discussions in both clubs.

Quotes

When I exported my Kindle highlights to a pdf file, it was twenty file pages. That’s above the average for me. The average is five to fifteen pages. I’ll comment on a few interesting quotes.

The first full book on a human-centered approach to testing was Cem Kaner’s Testing Computer Software. (Page 13.)

I have read it in 2022.

But we suggest that pessimism is a good heuristic for testers. Let everyone else on the team be optimistic. (Page 70.)

Pessimism is my superpower.

p. 233339362199739. (Page 73.)

I’m one of those people that (sometimes) carefully reads footnotes. This surely looks like an impossible page number.

Bug reporting is central to testing. (Page 118.) … the quality of your reports is probably the single most important factor in determining your credibility as a tester. (Page 118.)

There’s craft in writing a good bug report. As short as possible, while still containing all relevant data.

No one can deny that automation tool sales demos are impressive. (Page 217.)

That’s the main complaint I have when I see a demo of yet another test automation tool. Sure, it’s impressive for a simple example. But what happens in a few months, or years, when there’s a lot of code?

…the costs of automation are not just in the initial creation of it. (Page 232.)

In my experience, the vast majority of the cost is maintenance.

There are also large tooling opportunities; automation frameworks and such. But keep in mind, there is a certain danger with those projects: they tend to pull the toolsmiths into their own world. Pretty soon, the testers are wondering what those guys do for a living. (Page 237.)

I do test automation for a living. For the last couple of decades. At least once, a tester asked me what in the world I actually do.

Considerations for GUI-level Automation. Let’s say you are thinking about embarking on automation that will drive the product on a GUI level. Okay. Generally speaking, you ought to be scared of this. (Page 243.) Having said that, it’s not always a bad idea. (Page 243.)

If you’re not scared of GUI test automation, you should be.

So-called self-healing automation is very limited in its scope. Don’t believe the hype. (Page 245.)

I am yet to see this work. As usual, I’ll be glad to be proven wrong.

There’s always a problem, and the problem is always people. (Page 428)

If you think projects fail for technical reasons, you might be wrong.

Of all the things I’ve learned over the years, I see now that learning how to learn has been the most valuable lesson. (Page 433.)

I wish learning how to learn is something you do in school. I had to learn it myself.

Popular Highlights

The book has more than five hundred pages. All of the popular highlights are in the first fifty pages. Either most of the people that highlight have only read the first ten percent of the book, or the first ten percent of the book are the best part.

I’ll have to double check, but it looks like popular highlights are not the same (for the same book) on my Kindle device and in my Kindle macOS app. Shrug.

Why Testing?

Testing is the opposite of faith in the product. Testing begins with faith in the existence of trouble. (Page 8, 20+ highlighters)

The Meaning of Testing

Testing is the process of evaluating a product by learning about it through experiencing, exploring, and experimenting with it. (Page 17, 30+ highlighters)

Even if you do run a bunch of very good automation, when it fails, you must investigate it. That’s a learning process. And when it doesn’t fail, you ought to be wondering what bugs you could be missing. You should be proactively looking for holes in that testing. That’s a learning process. Real testing is always learning. (Page 18, 10~ highlighters)

A test is an encounter with a product that constitutes an episode of testing. (Page 20, 20~ highlighters)

Good deep testing means testing that maximizes the chance of finding every elusive bug, of some particular kind, that matters. Good shallow testing means testing that has some chance of finding every easy bug of some particular kind. (Page 21, 20+ highlighters)

Foundational Ideas

For testing purposes, we are concerned with dynamic systems— wherein changing the meaningful relationships causes change to the entire system. (Page 34, 20+ highlighters)

A model allows you to explore a system; exploring a system allows you to model it better. (Page 34, 20+ highlighters)

Testers do not control, assure, or ensure quality. Releasing the product is a business decision, not a testing decision. (Page 38, 20+ highlighters)

Methodology is what you think should happen; process is what actually happens. (Page 43, 20+ highlighters)

Without tacit knowledge, you can’t solve hard problems; without explicit knowledge, you can’t talk about them. (Page 48, 10+ highlighters)

Feedback

Thank you for reading. If you want to stay in touch please use the feed or send me an email.