The Demons of Ambiguity


Inquiring Minds
If you work for a team where the testers are brought in late in the cycle to test software that is almost finished, this question asking may seem a strange role for testers. But it is one of the most valuable activities a tester can do. My favorite tester story involves Human Resources at some company asking the requirements team, the development team, and the test team to write a 100-word description of what they did. The first two groups complied with typically boring statements. The testers sent back the following note:

Who is this description intended for? Why do you need this? When do you need this? What language do you want this in? Do you want to include only full-time testers? How about contractors? Why is it important that it be 100 words? Is that a lower limit or an upper limit? How do you want to count the words? Do hyphenated words count as one word or two? What format should this be in?

What a great reply! Rather than merely describe what testers do; it showed testers in action!

How Much Is Enough?
You may argue that some of these questions are too picky and lawyerly. And you may be right. Perhaps we don't care about all the details, but we do care about having enough details so that we understand what we're talking about and don't make too many costly mistakes. As long as the questions are asked, we are aware of the issues even if they get tabled for future discussion.

And you never can tell who will come to your defense in asking seemingly picky questions. At a spec review a few months ago, one tester was drilling down on some functionality when the spec writer said dismissively that such questions were too picky. There was a hush in the room until the developer on the feature spoke up "No, it's not too picky at all. The requirement is ambiguous. I want to know what it means so I don't have to guess and end up rewriting the code several times." It was a great moment—an unambiguous vote for clarity and quality!

Further Reading:

Exploring Requirements by Gerald Weinberg and Donald Gause
In Other Words by Marc Rene and Kathy Walker

About the author

Harry Robinson's picture Harry Robinson

Harry Robinson is a Software Engineer in Test for Google. He coaches teams around the company in test generation techniques. His background includes ten years at AT&T Bell Labs, three years at Hewlett-Packard, and six years at Microsoft before joining Google in 2005. While at Bell Labs, he created a model-based testing system that won the 1995 AT&T Award for Outstanding Achievement in the Area of Quality. At Microsoft, he pioneered the test generation technology behind Test Model Toolkit, which won the Microsoft Best Practice Award in 2001. He holds two patents in software test automation methods, maintains the Web site Model-based Testing, and speaks and writes frequently on software testing and automation issues.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!