- From: Patrick Curran <Patrick.Curran@sun.com>
- Date: Wed, 26 Feb 2003 08:16:03 -0800
- To: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- CC: www-qa-wg@w3.org
I like it - thanks... Lynne Rosenthal wrote: > > 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:17:15 UTC