Dear Evil Tester: a review

For Christmas, alongside the socks, CDs and puzzle books I usually get, I was also given a copy of "Dear Evil Tester" by Alan Richardson, subtitled "Provocative advice that could change your approach to testing forever". It's a great book, filled with a lot of good advice as well as some interesting (and often tongue in cheek) ideas as well as a lot of humour. Here I've picked out some of the main themes discussed in the book, along with my thoughts:

Testing Mindset

A large proportion of the book is used to discuss various aspects of what makes testers tick. Some of the ideas are familiar, but there are also thought-provoking observations:

"Where the project was in utter disaster mode, the testers were the only ones cracking jokes." 

That struck a chord with me, it's not that we're making fun of the project, I think it's more that we're impervious to the situation as we are happy with risk (although there may also be an element of "I told you so").

"You don't test quality, you test qualities of the product against models made independently of the product"

This is a great observation, and something I have always done but never consciously realised. The model can be built from any available evidence (specs, designs, sketches on the back of napkins, common sense) but the idea of the product is what we are comparing the actual product to. Bugs are the discrepancies between the model and reality.

"You can't test quality into a product"

An old favourite, but no less true for all that. If there are defects in a system, testers find them, they don't introduce them. All the testing in the world will come to nothing unless the defects found get fixed.

"Everyone can test, just not professionally"

I agree with this, although I have trouble enunciating exactly what "professionally" means in this context. I know there's something we do but have trouble expressing what that is - Methodicalness? Organisation gained from years of practice? Tester's eye (whatever that is)? (I may return to this at a future date). In any case, finding a bug is not testing; "having a quick look over the site" is not testing; checking the happy paths is not testing; although each of those activities can form part of testing it's the intent behind what we do that makes the difference. The ideal approach to testing is summed up for me in for me in his pithy statement "Go on. Break it. You know you want to.".

Process

There are lots of good tips on how to improve your testing processes:

On test scripts : "Because we might ask someone off the street to come in and execute that script for us."

In most cases, detailed scripts are neither necessary nor warranted. An efficient test script needs to be pared back to the bone; applying the "just enough" principle is a good maxim, the main aim of a good test script is to provide reproducibility and make clear what is being covered. That's not to say that test scripts are redundant, it's always possible a new tester will need to take over (illness, promotion, higher calling...), so, as with all good writing you need to keep your audience in mind and not just produce a set of personal notes that will be indecipherable to anyone else.

"Automation can waste time; But so can updating test scripts"

Lovely observation. As discussed in To automate or not to automate it's not a war on automation, it's a war on waste; we need to assess which method is the most efficient. Both changes are liable to stem from the same action, e.g. change of functionality, it's just a case of analysing which is going to be the most cost-effective route in the long term which drives the decision on whether to automate.

There are lots of other things to recommend this book for (I've never seen a bibliography reference to Dr Seuss before, for example) but this isn't meant to be a replacement for reading the book, so I'll leave it there with one final quote:

"Not all testers are evil, just the good ones."