- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Wed, 26 Feb 2003 11:02:51 -0500
- To: Patrick Curran <Patrick.Curran@sun.com>, www-qa-wg@w3.org
Suggested changes to the SpecGL slide Scope: define the scope, identifying what needs to conform and how Conformance Clause: specify the conformance policy and requirements Divide and conquer: use profiles, modules, functional levels to subset the technology Extensions: define if extensions are allowed and under what conditions Tag for later use: Identify testable assertions, discretionary items, etc (those things that will be needed in developing tests) Claims: specify how conformance claims and statements are made. lynne At 11:32 PM 2/25/2003 -0800, Patrick Curran wrote: >I'm sorry this is late - I've been overloaded. We only have a few days to >finish this up, so please send feedback asap. > >Thanks... > >Stylistic notations: > >*bold* >@@link@@ (URL) > >==================== > > >* Why QA? > > Investment in QA activies will: > Promote better, more testable, more implementable specifications > Reduce the cost of developing specifications > Increase the quality and interoperability of implementations > Reduce duplication of test-development effort > Even a small investment pays big dividends > Ask us about DOM, SOAP, SVG... > > >NOTES > >Originally we had two slides: why QA?, and business justification. I've >combined them, since the answer to "why?" should provide the business >justification. > >"Ask us about..." is the best we can do for now with test-cases, and >probably sufficient. > >TALKING POINTS > >The ops/spec guidelines will enable you to get the bugs out of your spec >early in the cycle. This will actually save you money due to fewer revision >cycles. Plus, the spec will be of higher quality. > >If you build a test suite, this will be expensive, but: > participating companies will find bugs in their implementations, > which will save them money > it's cheaper to contribute to a 'shared' test suite than for all > implementors to build their own test suites > > >* How the QA-WG can help you > > 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, use our templates, measure against our and > checkpoints > Tell us what else you need > > >TALKING POINTS > >Our framework docs are nearing completion, and we're getting ready to >re-charter - tell us what you want from us. > > >* It's easy to get started/How to work with us > > >NOTES > >During last week's teleconference we talked about a "how to get started" >slide, and how this should provide some very practical examples. I >haven't received any suggestions for this content, and I'm having >trouble distinguishing this slide from the OpsGL slide that we propose >to move to the end of the presentation. > > >* Results > > @@SOAP assertion list@@ > (http://www.w3.org/TR/2002/WD-soap12-testcollection-20020626) > > >NOTES > >We talked about the value of providing some real-world examples of the >successful >application of our guidelines. I haven't received any suggestions for >content. >Does this belong on a separate slide? > > >* Our 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* -- commit to QA goals and scenario > *Staff* -- assess and assign appropriate staffing > *Coordinate* -- synchronize QA and specification deliverables > *Plan* -- for for development, publication, maintenance > *How?* -- use OpsGL's @@charter template@@ and @@process template@@ > (http://www.w3.org/QA/WG/2003/02/OpsET-charter-20030217.html) > (http://www.w3.org/QA/WG/2003/02/OpsET-qapd-20030217.html) > > >NOTES > >Although I like the idea of having a positive, "here's what you can do" >slide towards the end, I'm concerned about what it would do to the structure >if we move this slide to the end. Specifically: > >How is this slide different from the "how do I get started/see how easy >this is" slide that we might want to put up front? > >If we move this to the end, wouldn't it be weird to present SpecGL >before OpsGL? > > >* Spec Guidelines (think Testability) > > *Define* scope; identify what needs to conform, and how > *Specify* conformance policy & requirements; provide conformance clause > *Use* profiles, modules, functional levels to subset the technology > *Define* extension policy > *Identify* testable assertions, discretionary items > *Specify* how conformance claims & statements are made > > >NOTES > >This slide's "chatty style" doesn't quite match OpsGL's. Can anybody >suggest an alternative? > > >* Feedback & Next Steps > > What do you think of: > Our last-call documents? > Our tools and resources (Library, Matrix, Tools, ...)? > Other feedback? > What would you like us to do next? > Review your processes and specs? > Provide consulting services? > Document existing best practices? > Provide templates, tools, and test harnesses? > Other suggestions? > > >* References > > Our home page (and the seven docs) (http://www.w3.org/QA/WG/) > The Matrix (http://www.w3.org/QA/TheMatrix) > QA library (http://www.w3.org/QA/Library/) > What else?
Received on Wednesday, 26 February 2003 11:03:28 UTC