- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Mon, 27 Oct 2003 16:23:49 -0700 (MST)
- To: Patrick Curran <Patrick.Curran@Sun.COM>
- Cc: www-qa@w3.org
I owe Patrick Curran a blob on "lack of testability definition" for
TestGL. Here it is:
QA Framework in general and this document in particular
rely on an an undefined term "testable" when defining and
using key concepts such as test assertions. The lack of a
definition for "testable" is not an oversight. The
discussion and examples below explain why there is
no good definition that is as general as QA Framework
or TestGL scope.
Informally, "boolean condition X is testable" usually means
"there exist a procedure to determine the truthfulness of X".
A more specific (and less general) wording may require the
"procedure" to be "finite" or even "affordable". The problem
with this informal approach is that for most practical
purposes related to computers, it is impossible to determine
truthfulness by following a procedure. The best we can do is to
attain a high level of confidence that X is true. Thus,
the informal definition that most people would agree with
may read "there exist a finite procedure to attain a high
level of confidence that X is true". What level of
confidence is "high enough" is, essentially, up to the
tester to define for a given environment. The cost
of the testing procedure and the cost of a false answer,
among other factors, would affect that environment-specific
definition.
To summarize, our inability to define "testable" lies
in the probabilistic nature of computer-related tests
and the fact that no general definition of "good
probability" or "high enough confidence" can exist.
The nature of the problem makes such definition
very subjective and/or domain-specific.
For example, a "software system MUST accept invalid
input" behavioral requirement can be tested using a black-box
technique with all sorts of invalid inputs and under
different conditions. However, there is no guarantee
that the invalid input that crashes the system was
tried. In most interesting cases the number of
invalid inputs and/or conditions is infinite and not
even countable. Whether, say, 99% confidence level would
be acceptable for concluding conformance in this case
would depend on things like software domain (isolated home PC
versus nuclear plant). Not to mention that there are
many ways to calculate that confidence level.
A less obvious example is a "document syntax conforms to
specification X" formatting requirement. Even if
specification X is written in a formal language, verifying
conformance of large documents would be impractical without
the use of automated validators. Thus, one would essentially
reformulate the above requirement into something like
"a correct document validator states that the
document syntax conforms to specification X". The first
sub-requirement ("the validator is correct") is equivalent
to the behavioral example discussed above.
Please feel free to edit the above text or throw it away, of course.
This submission is meant to complete AI-20031022-7, which is
mis-stated as "come up with the definition for the term testable" at
http://lists.w3.org/Archives/Public/www-qa-wg/2003Oct/0040.html
AI-20031022-7 is due October 29.
Thank you,
Alex.
Received on Monday, 27 October 2003 18:23:51 UTC