This question came up the other day in a public forum, as it does every now and again: “Should you test against ambiguous/incomplete requirements?”
My answer is Yes, you should. In fact, you must, because all requirements documents are to some degree ambiguous or incomplete. And in fact, all requirements are to some degree ambiguous and incomplete.
And that is an important reason why we test: to help discover how the product is inconsistent with people’s current requirements, even though it might be consistent with requirements that they may have specified—ambiguously or incompletely—at some point in the past.
In other words: we test not only to compare the product to documented requirements, but to discover and help refine requirements that may otherwise be ambiguous, unclear, inconsistent, out of date, unrecognized, or emergent.
*slow clap*
Michael replies: Terrific example.
A gradual building of applause, usually starting with one person clapping slowly, and ending with an enthusiastic standing ovation. Generally shows approval for an underdog in a come from behind victory or after losing with pride intact.
http://www.urbandictionary.com/define.php?term=slow clap
Slow Clap or Golf Clap[9] is a sarcastic type of applause that is used to heckle a speaker or performer.
http://knowyourmeme.com/memes/slow-clap
[…] Very Short Blog Posts (31): Ambiguous or Incomplete Requirements Written by: Michael Bolton […]