Better Software - November 2007 - (Page 16)

Test Connection HowTestersThink by Michael Bolton People think in models and metaphors; we seem to be hard-wired for them. Metaphors help us make sense of the world and deal with new things. Throughout the years, people have applied various metaphors to software development, including the notion of software development as an engineering discipline. Traditionally, engineering involved tangible, physical things, but software has enough in common with machines and development has enough in common with construction that the metaphor has served us well. When thinking of how to improve our products and our processes, we ask “What would engineers do?” Metaphors are heuristics—fallible methods for solving problems and for learning. The engineering metaphor has become so pervasive that we’re beginning to take it literally rather than metaphorically. We still have things to learn from engineering, but there are other fields from which we can take useful approaches, too. This idea struck me as I began reading Dr. Jerome Groopman’s How Doctors Think and recognized that many of the issues doctors face in diagnosing diseases are similar to those we face as software testers. Doctors work under conditions of extreme time pressure; they must adapt their choices to their clients and contexts, which may change at any time. They must identify and investigate symptoms of trouble while recognizing that they cannot know everything there is to know about the system. Moreover, doctors are beginning to recognize that complex systems—namely human patients—are resistant to discrete, linear, decision-making processes. Instead, doctors often make decisions based on rapid observation, instant analysis, and incomplete information—that is, by heuristic processes. In addition, medicine is a pursuit in which technical aspects are often overemphasized at the expense of human values. 16 On several occasions in Groopman’s book, a doctor is presented with a difficult diagnostic problem. In one case, a woman in her early twenties, complaining of intense pain to the point of vomiting after meals, presents herself to doctors. They diagnose her with anorexia and bulimia and later suggest irritable bowel syndrome. None of the treatments offered by the doctors provides long-term relief. After fifteen years of steadily deteriorating health and weight loss, she is referred to a doctor with a reputation for solving tough problems. He asks her to tell her story, in her own words, from beginning to end. He listens calmly and sympathetically with an open mind, observes keenly, waits for the patient to finish her story, and then asks her a lot of questions. After performing tests and collecting more data, he recognizes something the other doctors had missed—that the patient might have a physical ailment in addition to a psychological one—and diagnoses celiac disease, an autoimmune disorder. Subsequent tests and a rapidly recovering patient confirm that the diagnosis was correct. Asked how he did it, the doctor replied that he continually asks himself two questions: “What else could this be?” and “Is this the worst problem this patient could have?” Several years ago, I worked on a prodwww.StickyMinds.com uct that was closely tied to an operating system. One of our test systems had been cobbled together from spare parts around the test lab, and this particular machine wouldn’t boot properly when our product was present. One of our best developers (let’s call him Ron) thought about the problem on and off for three weeks. He became convinced that it was just a flaky machine—there was some incompatibility between its components that our software exposed, which didn’t represent an underlying problem that our code could address. Our testers were convinced there was more to the story. Another developer (and expert tester), Pat, was willing to believe the testers and thought through what happened at boot time. He modeled the system into a set of components and the boot process into a series of tasks, noting the interactions between our software and the other elements of the system. He theorized that the hard drive controller might be involved in the problem, set up the machine under the debugger, and ran some tests. In a few minutes, he found that when our software was present, the drive controller didn’t initialize properly under a certain set of easily reproducible conditions. When the testers tried our product on a computer that had been in use on another project—a machine that had the same BETTER SOFTWARE NOVEMBER 2007 ISTOCKPHOTO 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.