Top critical review
1.0 out of 5 starsThe difference between a methodologist and a terrorist ...
Reviewed in the United States on August 2, 2020
... is that you can negotiate with a terrorist.
I can pretty much deal with the chummy style of writing, but "keeping it light" doesn't work when I'm digging for information. I found the mindlessly simplistic initial case study to be more of a distraction than aid. When it takes that many pages, false starts, side trips, and retries to add two numbers, whatever point was being made gets lost in the vapid example used to make it. (We can skip the fact that, as the author notes, the number format being used is poorly suited to the nominal problem domain.)
Then, given that the whole book is about software testing I find it odd that there's little to no direct mention of a central question: what makes software testable or not? "Design for testability" has been a topic in the hardware world for a half-century, give or take. But, even with the software world's relatively recent attention to testing and even with dogmatic manifestos like this, I have not found any body of knowledge or practice that addresses the topic systematically.
Machinists talk about what makes an alloy machinable. Farmers know what make land farmable. Woodworkers can specify what makes a wood workable. Seemingly everyone knows what makes their subject material better or worse for their purpose and can tell you in detail. Everyone except software testers, apparently. This book discusses practice without actually saying what it practices on, and leaves me feeling that I heard only half of a conversation.
This is going to the used market as fast as I can fling it.
-- wiredweird
