- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Wed, 04 Feb 2004 11:32:11 -0500
- To: Mark Skall <mark.skall@nist.gov>, Patrick Curran <Patrick.Curran@Sun.COM>, Andrew Thackrah <andrew@opengroup.org>
- Cc: www-qa-wg@w3.org
Given Mark's point - > The test assertions may be in more detail and need to be read only by > the test developer. The test assertions should make it precisely clear > what the test will be and may be quite long. Additionally, Andrew (or > perhaps someone else) introduced the idea that the assertions are > statement of fact about the implementation rather than requirements > imposed (e.g., the spec contains rather than the spec MUST or the > implementation produces a file that . . .. rather than the implementation > MUST). This may be a subtle distinction but one that really makes a lot > of sense (at least to me). I'm concerned about the goal of developing the TAs as a requirement in SpecGL. Mark's comments talks about TAs to enable testing and implementations. SpecGL targets writing the specification, not developing tests. TAs are very useful as a technique for thoroughly reviewing a specification to make sure that it is written clearly and is testable, unambiguous, etc. But, it isn't the only way to do this thorough review. If TAs are created with the spec, they definitely aid in traceability of tests as well as development of tests. However, common practice has shown that test developers often create their own TAs and that TAs take various forms (written or represented to different degrees of exactness, sometimes in english, math notation, table form, etc). I'm not against the development of TAs and their association with a spec. I'm concerned with (1) our goal in requiring TAs - what are we trying to do and (2) is this the only way to accomplish this goal? I want to make sure that the answers to these questions is clear. --lynne
Received on Wednesday, 4 February 2004 11:33:16 UTC