Better Software - July/August 2008 - (Page 21) Test Connection sonably good precision. Then someone brought up the question, “What if we were off by ten milliseconds, and the system took 310 milliseconds to respond? That would be a failure, but would that be a problem?” James realized that he had considered the precise wording of the requirement— a shallow sort of meaning—but neither its deeper meaning nor its significance. He went to the project manager for clarification. It turned out that the previous version of the program had taken upward of seven seconds to acknowledge that it had received input, and customers had found this annoyingly slow. The designers had put the precise timing—300 milliseconds—into the specification because they had thought that you couldn’t use words like “annoyingly slow” with testers. James suggested instead that the developers show the testers the old system so the testers could understand the problem from a visceral perspective. In this case, ambiguity was disguised as precision—and this was no place for stopwatches. So how should we deal with ambiguity in requirements and elsewhere in the project? How do we seek it, and how do we resolve it? Here are some heuristics. The first thing is to recognize that the requirements are not the requirements document; at best, the document is a stand-in for the ideas of one or more real people. Recognize that all statements, whether written or spoken, are potentially ambiguous, but the ambiguity might not represent a problem for the project, so look for ambiguity that matters. A testable requirement is not necessarily one that is painstakingly precise, mathematically falsifiable, or unfailingly unambiguous. A testable requirement is one that helps us ask and answer the question “Is there a problem here?” Conversation is a fast and powerful approach to discovering and resolving ambiguity. Ask plenty of questions and watch for disagreements on the answers from various people; then seek consensus on meaning and significance. There can be several levels to the conversation— one in which we’re talking about something, another in which we ensure that we agree on what we’re talking about, and yet another in which we work out a protocol for resolving our differences. This may seem like extra work but, in fact, people are doing it all the time. The trick is to do it consciously. Make sure that conversations are supplemented by a wide variety of media—whiteboards, tables, scenarios, mind maps, wikis, knowledge-crunching sessions, diagrams—in addition to the more traditional forms of documentation. Be skeptical that any one document will identify all the things you need to know about your project. When you spot ambiguity problems, make the problem clear by pointing out alternative interpretations: “There could be a bunch of testing missions in play here—finding important problems quickly, investigating the problems we’ve found, assessing backward compatibility, identifying new risks. What can we agree on as the primary goal?” Don’t feel obliged to document minute details of every discussion. Documentation may have high cost and low value when consensus is the goal. Some things on a development project are so important that we don’t write them down; instead, they become part of the project culture. (Everyone remember to breathe!) Above all, remember Jerry Weinberg’s definition of a tester—a definition that highlights the significance of ambiguity in our work: “A tester is someone who knows that things can be different.” {end} How do you know what you know? How do you know it? And how do you know that others understand things the same way? Follow the link on the StickyMinds.com homepage to join the conversation. Sticky Notes For more on the following topic go to www.StickyMinds.com/bettersoftware. n Further Reading www.StickyMinds.com JULY/AUGUST 2008 BETTER SOFTWARE 21 http://StickyMinds.com http://www.StickyMinds.com/bettersoftware http://www.rallydev.com/bsm http://www.rallydev.com/bsm 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.