W3C home > Mailing lists > Public > www-qa-wg@w3.org > February 2004

Re: Question on Developing Test Assertions

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Wed, 04 Feb 2004 11:32:11 -0500
Message-Id: <>
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.

Received on Wednesday, 4 February 2004 11:33:16 UTC

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