Better Software - July/August 2008 - (Page 20) Test Connection Two Cheers for Ambiguity by Michael Bolton I was sitting at the back of the room, munching on a donut, sipping a coffee, and listening to the presenter talking about the importance of unambiguous requirements. “What does he mean by ‘unambiguous’?” I wondered. He also seemed to be opposed to jargon—yet, jargon, to those who use it, is extremely precise and unambiguous. “Jargon” and “ambiguity” are like “quality” or “purpose”—subjective and context-dependent, not properties of something but rather a relationship between some person and the thing. Ambiguity may be a problem or it may not, depending on its meaning and significance to some person. I was reminded of all this recently when a colleague observed that he avoided using words like “skill,” “diversity,” “problems,” and “mission,” because he found them inherently ambiguous. I replied that I use these words constantly for exactly the same reason. I find them to be not only necessary but also useful as gauges for assessing consensus on a project and how we get to that consensus. Some people are comfortable with ambiguity; others are not. We can spot a member of one group or the other by the answer we get when we ask, “Can we talk about what you mean by ‘skill’ (or ‘diversity’ or ‘test’ or ‘bug’)?” When someone responds, “Well, for example …” or “In this context …” or “There are many possible meanings, but around here we mean …” then we know we’re in good company. We can have an evolving, ongoing conversation that helps us work together and understand one another, and if we discover that we don’t have a consensual understanding of something, we can work it out. On the other hand, when someone responds, “Isn’t that obvious?” or “Why do you keep going meta?” or “Can’t we talk about practical stuff?” then we know that there’s work to be done, because someone is suffering from that terrible disease, Single Model Syndrome. 20 BETTER SOFTWARE JULY/AUGUST 2008 Single Model Syndrome is the silver bullet for ambiguity problems; something is unambiguous when there’s no possibility of a second interpretation of it. On the other hand, Single Model Syndrome can lead to frightful misunderstanding, especially when two people suffering from it—and using different models—show up at the same meeting. The battle against ambiguity has to do with the problem of closure. Psychologically, some people are comforted by closure and require it; others don’t require it and, in fact, may be leery of it. Developers and project managers tend to value closure because it gives them a finish line, a clear goal that can be met. Good testers are aware of the risk of closure, especially when it’s premature. Suspending conclusions helps us to see more alternatives and to adapt to change, both in problems and in solutions. Seizing certainty at the requirements stage cuts us off from alternative approaches and new information. One common manifestation of this problem is an excessively detailed test plan—one that doesn’t match the product that is eventually delivered. For testers in particular, recognizing ambiguity is useful. Recognizing ambiguity is naturally important because ambiguity is a way in which misunderstanding may provide homes for bugs in the product. Yet ambiguity, which www.StickyMinds.com implies more than one possibility, might also be a blessing in disguise. An ambiguous sentence might trigger a discussion about what we perceive, what we agree upon, and what we don’t yet understand. An ambiguous word might have several open-ended meanings that help reduce tunnel vision. An ambiguous problem statement might remind us that there are often several alternative approaches to solving a problem. The precise expression of a requirement might make testers’ lives easier, but perhaps the meaning and the significance of the requirement are more important, even though they may be imprecise. James Bach tells a wonderful story that illustrates the distinction. On a project several years ago, a junior tester asked James to help interpret a line in the requirements document that said, “When the user presses the touchscreen, the system shall respond within 300 milliseconds.” Holding a stopwatch in one hand and using the system with the other seemed impractical, and automation seemed to have a high development cost, so James decided to train the testers to recognize 300 milliseconds. He bought an inexpensive stopwatch for each of the testers. They went to lunch and practiced turning their stopwatches on and off until they could estimate 250 milliseconds, plus or minus fifty, with rea- dReaMSTIMe http://www.StickyMinds.com
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.