The Good, the Bad, and the Vague

That last post got me thinking in concrete terms about...ambiguity.

Most of us experience being on the receiving end of ambiguity at an early age. It happens on our birthdays when we ask our parents for a dirt bike or air rifle. Some parents just say "no," but, the truly creative parents make use of the power of ambiguity and say "we'll see." Your parents are practicing intentional ambiguity.

Unintentional ambiguity, however, can be just as powerful, and, in engineering disciplines, can have serious consequences. When you're dealing with a physical medium such as glass or steel, you need to have an unambiguous understanding of the medium's limitations. For example, when you're building a bridge, you need to know exactly how much stress the steel handle. A design specification that states that the steel "might be at least as strong as this type of bridge generally requires" could lead to problems like this:



In the previous post to this blog, I discussed a couple of instances where unclear communications in source code and test reports had unpleasant side effects. How can you avoid situations like this, or problems caused by ambiguous product specification, requirement, or design documents? By including ambiguity reviews into your technical reviews.

I'd like to take credit for the idea of ambiguity reviews, but I can't. A formalized process for ambiguity reviews was defined and documented by Richard Bender here: http://benderrbt.com/Ambiguityprocess.pdf

The way it works is that it converts your technical specification reviews into a 2-phase process; first a review for ambiguity, and once any problems are resolved, your technical review. What sorts of things should you look for in an ambiguity review?

• Adjectives such as: frequent or infrequent, many or few, normal or unusual
• Adverbs such as: in general, not quite, hardly ever (remember the bridge!)
• Verbs such as: maximize, efficiently, seamlessly (these sound like "resume words," don't they ;-)
  

In short, descriptions should be in measurable terms. Just like constants in an equation.

It's common to think of software testing problems in algebraic terms in that when you are writing a test or chasing a bug, you're trying to resolve variables to be able to reach a conclusion. If you can remove ambiguity from the information on which you base your tests, you can reduce the number of those variables. But, don't stop there! You should subject your own test plans to same ambiguity reviews so that your tests are just as precise as the product definition.

References:

http://benderrbt.com

(Special thanks to Mike for inspiring this!)