Better Software - November 2007 - (Page 17)

Test Connection controller but a brand-name system—it crashed on boot. Pat threw in a short routine to special-case this drive controller, he squashed the bug, and we shipped on time. How had Pat solved the problem so quickly when Ron couldn’t? Ron had suffered from several significant, related cognitive errors, all of which have parallels in How Doctors Think. The bias that allowed Ron to ignore the problem was fundamental attribution error—explaining something entirely by a preconception or a stereotype (“She’s anorexic”; “Machines that have been assembled from spare parts are intrinsically unreliable”). He attributed the problem to a single path of causation (“bulimia”; “a flaky controller”) rather than interaction between multiple parts of the system. Anchoring bias—dropping anchor on an idea and not moving from it—allowed him to get stuck. (The doctors were stuck for fifteen years; the developer for three weeks.) Like the successful doctor, Pat used applied epistemology combined with empiricism. “If I believe something,” he told me later, “I ask myself why I believe it, and then I test for it.” He pulled up the intellectual and emotional anchor and tried to abandon preconceptions that would get in the way of solving the problem. He kept his mind open to possibilities; there might be a bug in our code, in the disk controller, or in the interaction between them. He noted that the controller worked with products similar to ours, which allowed him to narrow down the conflict to one of our product’s unique features. As testers, we never know for sure the deep truth about any observation, so excellent testing includes open-mindedness and critical thinking at every stage of the testing process. We think we know something, but it’s only what we know so far. When tests aren’t revealing important new information, we might decide to stop testing, but we also might consider that we’re using insufficient tests or making insufficient observations. Continued questioning is central to good testing. Contrary to much of our profession’s folklore, a good testing question doesn’t necessarily have a definitive, expected result. Tests that are designed to confirm a prevailing theory tend not to reveal new information. Collaboration and consultation tend to be more powerful than working alone—especially when we’re stuck. If you’re in an organization that assigns work to a single tester per feature, consider paired testing sessions with another tester. Note the flow of ideas, your progress—and the bugs you find. People learn from stories. In software testing, we compose, edit, justify, and narrate two kinds of stories. We tell the product story, which is everything that matters about how the product can work, how it has failed in tests, and how it might fail in the field. We also tell the testing story, which is about how we have configured, operated, and observed the product; the things we haven’t tested yet; the things we won’t be able to test at all; and why we believe that what we’ve done is good enough. Medicine is a metaphor, and metaphors get their power from the combination of comparison and contrast. There are a lot of ways in which testers aren’t like doctors—and programs aren’t like patients. For one thing, patients can tell their stories; software has to be run so we can observe it. At a certain level, software can be considerably more deterministic and easier to diagnose than human patients. As testers, we’re rarely under the same kind of time pressure and emotional burden as doctors. Still, learning how doctors think may teach us some important lessons about how testers could think. {end} Michael Bolton lives in Toronto and teaches heuristics and exploratory testing in Canada, the United States, and other countries. He is co-author, with James Bach, of Rapid Software Testing and a regular contributor to Better Software magazine. Contact Michael at mb@developsense.com. From what other professions do you take testing lessons? M Follow the link on the StickyMinds.com homepage to join the conversation. www.StickyMinds.com NOVEMBER 2007 BETTER SOFTWARE 17 http://www.apodora.org http://www.aculis.com http://www.StickyMinds.com http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2007

Better Software - November 2007 Contents MarkYour Calendar Technically Speaking What’s Happening @StickyMinds.com Code Craft Test Connection Management Chronicles The Measure of a Management System Behind the Scenes A Story About User Stories and Test-Driven Development Product Announcements The Last Word Ad Index

Better Software - November 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.