Re: LC-59

Le ven 09/05/2003 à 03:22, Lofton Henderson a écrit :
> LC-59.1
> =====
> Proposal.  Would it be an acceptable improvement to replace that with:  "QA 
> deliverables include at least the test materials to which the WG has 
> committed (see Checkpoints 1.2, 1.3, and 1.4).  For example, the WG might 
> synchronize the first public release of a test suite (TS) with Candidate 
> Recommendation (CR).  Other examples of QA deliverables might include a TS 
> production schedule synchronized with first published WD, a TS design 
> document and tests enumeration in later WDs, an interoperability 
> matrix/report at beginning of PR, etc.

My problem was/is that I don't know where QA deliverable starts and
ends. You can certainly stretch it to the point of including
implementation reports for instance. Anyway, it feels awkward to me that
we ask to enumerate a list of things pertaining to a class we haven't
defined.

> LC-59.3
> =====
> "commensurate" isn't either (CP 4.2)
> 
> Proposal.  There is the counter-position that commensurate is a good word 
> here.  Discussion or OpsET could give the details so that the combination 
> is both informative and verifiable.  That notwithstanding, change:
> 
> "the Working Group MUST identify a QA task force of size commensurate with 
> the QA commitment level and the agreed QA deliverables."
> 
> to:
> 
> "the Working Group MUST identify and assign a QA task force for the tasks 
> necessary to meet the QA commitment level and the committed QA 
> deliverables, identified in checkpoints 1.1 - 1.5."  And add to the 
> Discussion, "The WG needs to ensure that the size of the task force is 
> adequate to meet the committed QA deliverables and QA level, per the 
> committed milestones."

I like it.

> [Ed note.  commensurate also appears in CP2.2.  No comments?]

Probably needs the same, yes.

> LC-59.5
> =====
> "a quality assessment" is not well defined (CP 7.1)
> 
> Discussion.  "a quality assessment" is used in the statement of the 
> checkpoint.  It does not have to be testable there.  Does Originator still 
> have problems with "perform and record an assessment of the quality of the 
> test materials," in the Conformance Requirements?  If so, what is the 
> nature of the problem?

The problem is that I can easily imagine the difficulty for a WG to do a
quality assessment of a test suite if it doesn't have any clue of what
this means :)

> Any sort of quality assessment is going to necessarily be pretty 
> TM-specific, depending the scope & goals of the TM, the type of TM (think 
> "taxonomy"), etc.  Is some sort of generic list desired, such 
> as:  "including at least correctness, traceability, atomicity, user 
> documentation, maintainer documentation, declaration of scope, completeness 
> (vis a' vis declared scope), harnesses or interfaces for application of the 
> TM, configurability, results assessment, results recording & reporting, 
> automation features, versioning/errata support, declaration of publication 
> licenses,   integrated submission procedures, etc."
> 
> Another thought:  all of this stuff could be in SpecET, in a template or 
> checklist.

You mean TestET ? or OpsET ?

> Proposal.  Originator propose wording that is satisfactory.

I think that listing some of the items above in the discussion part
would be a good solution. And pointing to the TestGL a possible
complement to that.

> LC-59.6
> =====
> "sufficient" is not testable (CP 7.2)
> 
> Discussion.  "sufficient" is used in the statement of the CP, which is its 
> title or label.  The CP statement need not be testable, but rather should 
> indicate in clear language what is the subject of the CP.

My bad.

[FWIW, the resolutions on which I didn't comment looked good to me]

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org