- 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