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:
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.