W3C home > Mailing lists > Public > www-qa@w3.org > May 2002

Re: QA Glossary

From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
Date: Fri, 24 May 2002 14:02:52 -0400
To: www-qa@w3.org
Message-ID: <OFAC92EEA9.E61F50A6-ON85256BC3.00603CA1@lotus.com>

Jack Morrison writes:
>What is the order of things? I thought the current definition implied
>Atomic Test, Test Case, Test Purpose, Test Assertion(s).

Specs (should) contain test assertions. In order to get good ones, the
spec writers should think about test cases. A test document (XML to be
displayed, transformed, transmitted, etc.) may contain enough material
to represent many tests. These tests may be independent of one another,
which we call non-atomic, and which is probably bad. A test document
should embody one test case, and that ought to be an atomic test case,
or at least molecular if atomic is not possible. I could digress about
real-world considerations for the test documents, but I won't (for now).

Jack cites this as a test assertion:
"Non-positive radius is an error condition."
If that is a good example, then you won't have very many atomic tests!
Right away, I see two classes of test cases:
A. Any routine that produces a radius must ensure that it is numeric
   and positive.
B. Any routine that consumes a radius parameter as input must signal
   an error if it is given a non-positive value.
A more complete assertion of type B might be, for example:
"DrawCircle() must raise an error if it is given a radius value that
is numeric but non-positive."
That looks like a reasonable test assertion because one can readily
devise a test to call DrawCircle() with a negative number as its
radius argument. Presumably, all the front matter of the test that
sets up conditions under which DrawCircle can be called would not
detract from the atomic nature of the test.

The problems arise in geometric proportion to the number of "if"
clauses needed to isolate the case being presented in the assertion.
The word "or" can also cause messy situations, or it may just
represent an attempt to economize on words. For example:
"If the content of an attribute node is obtained from more than one
operation that creates text, and if one of the text operations has an
error, the attribute must not be created even if the text operation
has a prescribed means of recovering and returning an empty string."
Each "if" in the above sentence implies that there is another branch
(maybe more than one) that are dealt with in other assertions.
.................David Marston
Received on Friday, 24 May 2002 14:17:18 UTC

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