Jerome Groopman's book How Doctors Think is about doctors and how they think. It is also about testers and how we think. I find this to be true of most every book I read: regardless of its official intent, I find some relevance to testing. Such is certainly the case here.

I might have titled this book Why Doctors Forget To Think, for I found it to be as much about why doctors get stuck on a certain diagnosis or miss something "obvious" as it is about how they arrive at a diagnosis in the first place. One reason this happens is that doctors - and the rest of us - generally prefer favorable outcomes over less happy ones. We also tend to prefer probable results over less probable results. The moment we spy a bit of evidence which suggests a favorable conclusion we start ignoring evidence which suggests other conclusions. Thus a doctor might decide their patient has acid reflux - simple to treat and a common malady - rather than checking whether they have angina or cancer - each of which requires more complex and more painful treatments. Or a developer might decide to do an easy change which fixes the symptom rather than digging in and finding the underlying problem. Or a tester might decide to log a surface bug rather than poking about to identify the lower-level issue.

One reason we do this is that we satisfice: decide that what we have is good enough. While some amount of satisficing is generally required in order to start the patient's treatment, fix the issue, or log the bug, sometimes we over-satisfice and we stop looking without thinking about what else might be going on.

Another reason we do this is doctors', and developers', and testers', belief that working fast and decisively translates to working effectively and efficiently. The best doctors, developers, and testers know, however, that working slowly and taking time to consider many different options often lets them solve their problem faster than does rushing right in.

Dr. Groopman suggests a set of questions for us to ask our doctor in order to aid their thinking and help them escape from any boxes them might have put themselves into. I believe these questions can help us testers and developers escape any boxes we might have put ourselves into as well:

• Tell the story over again as if for the first time. You may include a detail which you left out last time. Something may jump out as important which you previously missed or ignored as unimportant.
• Repeat the examination and reexamine the results from previous examinations. Forget what you "know" and start afresh. Be on the lookout for biases and assumptions, and remove any you find.
• Ask what else could be causing the problem. (If you can't come up with at least three alternatives you probably aren't thinking hard enough.)
• Ask whether any of the evidence you've gathered doesn't fit. Check whether you are ignoring evidence.
• Ask whether you might be seeing more than one problem. Sometimes defects hide other defects, and sometimes multiple bugs effectively gang up and masquerade as something else.
• Ask what is the worst thing the issue could be.
• Determine what other body parts/application features are near or interact with the symptom.

Answering these questions can help doctors see additional potential diagnoses. Answering these questions can help developers see additional potential fixes. Answering these questions can help testers see additional potential bugs.

Which result of course excites every tester! Because, as one interviewee said, "Finding something may be satisfactory, but not finding everything is suboptimal."

*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great testing and coding skills required.