Re: testability definition

Quoting Alex Rousskov <>:

> On Sat, 7 Sep 2002, Mark Skall wrote:
> > 3)  which a person or software can check  that the requirement has been
> met
> >
> > Software (perhaps combined with human judgement) does "check" that
> > the requirement has been met.  It may not "prove" that the
> > requirement has been met, but it certainly checks.  In fact, if done
> > correctly, it "checks" with a high degree of probability that the
> > checking is correct.
> Nice trick! Can you come up with any example (real or imaginable) of a
> spec that will not be testable according to your interpretation of the
> phrase "check the requirement"?

No, this is not a trick.  Just like in testing, one can only test exactly what 
the spec says.  Likewise, we are only allowed to analyze what our spec says - 
ceratinly not what you think it says.  Again, what it says is "check".

Of course, thee are many specs that are not testable with the "check" phrase.  
The whole point is that requirements can't be "checked" if they are not 
precisely defined and what we are encouraging with this wording is the exact 
wording of requirements. If a requirement is ambiguous, contradictory, or just 
plain vague it can't be checked.
> I can "check" anything if the "process of checking" implies nothing. I
> can say that I "checked" a requirement if I simply read it! What is
> the point of introducing a definition if practically all specs satisfy
> it?

Again, read the above response.  A requirement can't be "checked" unless it is 
precisely defined.


Received on Sunday, 8 September 2002 22:14:25 UTC