W3C home > Mailing lists > Public > www-qa@w3.org > October 2003

lack of testability definition

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
Message-ID: <Pine.BSF.4.53.0310271527470.62133@measurement-factory.com>

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

	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
AI-20031022-7 is due October 29.

Thank you,

Received on Monday, 27 October 2003 18:23:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:22 UTC