- From: Jack Morrison <Jack.Morrison@Sun.COM>
- Date: Fri, 24 May 2002 13:24:56 -0400 (EDT)
- To: www-qa@w3.org
- Cc: rousskov@measurement-factory.com, david_marston@us.ibm.com, mbrady@nist.gov
To Those Who have Been Working On This MUCH Longer Then I,
Before I give an opinion here, I would like to make sure I understand the
relationships between some of the terms we are defining.
What is the order of things? I thought the current definition implied Atomic
Test, Test Case, Test Purpose, Test Assertion(s). However, I am not sure any
longer. Maybe I am oversimplifying things, but I assumed a Test Assertion
related to something (a requirement or rule ?) in a specification that needed to
be validated or proved correct. In our case it might be a particular Checkpoint.
If it is meant to point to more than one thing or premise, why ?
I further assumed that a "series" of Test Cases made up how you would test a
Test Assertion, corresponding to validation of a requirement/rule. I agree that
a Test Case may be valid for more than one Test Assertion, and that in some
cases you might only need one Test Case, but the normal goal to to prove AN
assertion.
I further assumed that an Atomic Test was the individual test (smallest
component) that made up a Test Case, and that if I were automating a test this
is the level I would start development or planning at. "Is the value positive?",
something simple like that.
As for Test Purpose, I am not sure if it defines why you are developing the test
assertions, or if it is why you are developing a particular set of test cases.
Please HELP!
Jack
http://www.w3c.org/QA/glossary
Atomic Test
A test case that tests a single rule from the specification and maps back
to exactly one assertion. This is in contrast to some test cases that may test a
combination of rules.
Test Case
An individual test that corresponds to a test purpose, which in turn maps
back to the assertion(s), and finally the spec.
Test Purpose
An explanation of why the test was written, and must map directly to one or
more test assertions.
Test Assertion/Requirement
A set of premises that are known to be true by definition in the spec.
I also found another W3C document, written by Lofton, that implies (I think, and
correct me if I am wrong) that a Test Case implements one or more Test Purposes,
which in turn verifies one or more Test Requirements/Assertions. Pretty similar.
http://www.w3.org/2001/01/qa-ws/pp/lofton-glossary.htm
Test Requirement/Assertion (TR/TA)
A testable assertion which is extracted from the standard (Recommendation).
Also called Semantic Requirement (SR) or Test Assertion (TA) in some literature.
Example. "Non-positive radius is an error condition."
Test Case (TC)
As used in these project, an executable unit of the material in the test suite
which implements one or more Test Purposes (hence verifies one or more Test
Requirements). Example. An SVG test file which contains an elliptical arc
element with a negative radius. In practice in these projects, the relationship
of TRs to TCs can be many-to-many.
Test Purpose (TP)
A reformulation of a Test Requirement (or, one or more TRs) as a testing
directive. Example. "Verify that radius is positive" would be a Test Purpose
for validating file instances,
and "Verify that interpreter treats non-positive radius as an error condition"
would be a TP for interpreter or viewer testing.
Received on Friday, 24 May 2002 13:25:18 UTC