RE: testability definition

On Fri, 6 Sep 2002, Kirill Gavrylyuk wrote:

> Why not remove "finite cost-effective" and leave:
>        A specification is testable if there exists some
>        process with which a person or software can check
>        that the requirement has been met."

I would be against that because we should be talking about practical
things and infinite cost-ineffective processes are not. It simply does
not matter if such a process exists in theory because it would never
exist in practice.

Moreover, note that "infinity" does not assume "enumeration ability" -
- you cannot enumerate real numbers, for example. Thus, if a spec
includes an equivalence of a real number as an input, you cannot even
talk about making a process of enumerating valid inputs! I cannot
recall the math term for this phenomenon.

> IMO all we want to say is that a (behavioral) specification is
> testable if one can deduce a (unambiguous) behavior from it for any
> input allowed by the specification's grammar.

I almost agree with that. You need to be able to deduce behavior from
invalid input as well. Also, ambiguous behavior may be allowed by the
specs (e.g., it may be OK for HTTP proxy to cache the page or not to
cache it).

Your proposed definition is much more broad though.

> Then the proposed criteria is:
> The spec is testable as long as you can build the process (not necessarily finite) which:
> -  enumerates all possible inputs (true in case of both HTTP and SOAP)

Not true if inputs are real numbers (at least).


                            | HTTP performance - Web Polygraph benchmark | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Friday, 6 September 2002 19:07:05 UTC