- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Fri, 31 Oct 2003 09:15:52 -0500
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: www-qa@w3.org
Here is another view of testability - this came from a different NIST
Laboratory - one that focuses on manufacturing.
Testability -- [1] The quality of a specification that enables
meaningful, repeatable, objective assessment of conformity to the
requirements therein. [2] The quality of a system that enables
meaningful, repeatable, objective assessment of conformity to
specified requirements.
--lynne
At 06:23 PM 10/27/2003, Alex Rousskov wrote:
>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 Friday, 31 October 2003 09:16:41 UTC