Re: testability definition

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"?

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, nowhere does this definition say "There is a finite
> cost-effective process to enumerate all valid inputs." like Alex
> seems to think it says.

You need to re-read the thread more carefully. The enumeration problem
was not with the original definition. It is related to the discussion
of the definition proposed by Kirill Gavrylyuk. The original
definition does not have the enumeration problem. It has a problem of
marking all behavioral specs non-testable (assuming a what I would
consider "expected by an average person" interpretation of the word
"check" in the context in question).

> I believe this definition was actually thought out carefully.

Perhaps. I can only say that the resulting wording did not come out
right. Your message tells me that it looks like we need to define
"check the requirement" to avoid the above tricks. Hmm... The
definition I proposed does not use the word "check", but I am not
certain whether it still leaves opportunities for similar word games.

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Sunday, 8 September 2002 00:37:51 UTC