- From: Lofton Henderson <lofton@rockynet.com>
- Date: Tue, 18 Feb 2003 07:26:17 -0700
- To: Patrick Curran <Patrick.Curran@sun.com>, W3C QAWG <www-qa-wg@w3.org>
Patrick et al, Good first draft, thanks. Sorry that I don't have time right now for more extensive comments -- let's try to flush some out during the telecon. Particularly, discuss/endorse/change the overall shape. Some quick comments, embedded below... At 12:54 PM 2/17/2003 -0800, Patrick Curran wrote: >For discussion tomorrow. I don't know if I've captured everybody's >thoughts, but at least this is a start... > > > > >* Why QA? > > Development of conformance test suites leads to: > Better, more testable, more implementable specifications > Better quality implementations > More interoperable implementations > > >* Business Justification > > QA activities are expensive > So is development of specifications and implementations > Examples? > Investment in QA activities: > Reduces cost of developing specifications and implementations > Reduces duplication of test-development effort > All implementors need test suites! > Even a small investment pays big dividends > > >* How the QA-WG can help > > We can't do your QA work for you > We don't have the resources nor the domain-specific expertise > We do provide guidance, tools, and processes > We can help avoid duplication of effort > Follow our guidelines, measure against our checkpoints > > >* Guidelines (the Seven Documents) > > Introduction > Roadmap, primer, guide to the other documents > Operational Guidelines > Planning, logistics, operation, and maintenance of WG quality processes > Specification Guidelines > How to write clearer, more implementable, more testable specifications > Test Guidelines > Technologies, tools, methods for writing test materials > > >* Operations Guidelines (think QA) > > Appoint a QA lead > Integrate QA into Working Group activities > Define and allocate resources for QA activities > Synchronize QA activities with the specification milestones > Define the QA process > Plan for development, publication, maintenance of test materials > > >* Spec Guidelines (think Testability) > > Define scope; identify what needs to conform and how > Specify conformance policy > Use profiles, modules, functional levels to subset the technology > Identify testable assertions > Define discretionary items and extension policy > Identify conformance requirements; provide conformance clause > Address how conformance claims & statements are made I like these last two slides -- each one is a 1-slide summary of the essence of the GL document. I think that we might do a little tuning of the wording, as some of it is too close to the terse wording in the GL documents. Huh? Isn't it supposed to be close? What I mean is that it could be slightly more conversational. E.g., instead of "define & allocate resources for QA" I would be more inclined to say, "Estimate requirements and assign staff for...". >* Feedback & Next Steps > > What do you need from us? > What can we do to help? It would be nice if we could develop a handful of sub-bullets, that are suggestive of some possibilities. For example (these are just an illustration, I don't necessarily think these are the right ones)... * Consultation about SpecGL reviews * Forms and tools to help implement OpsGL * A "SpecGL validator" * A TTF (or TWG) of approximately XX (?) people * (...some of the proposed TTF deliverables...) "We are re-chartering in 6 months. Which direction should we move?) (maybe brainstorm this in telecon)... > >* References > > Provide URLs for: > Our home page > The seven docs > The Matrix > What else? The W3C QA Library (.../QA/Library) Regards, -Lofton.
Received on Tuesday, 18 February 2003 09:31:25 UTC