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

Revised outreach presentation outline

From: Patrick Curran <Patrick.Curran@sun.com>
Date: Tue, 25 Feb 2003 23:32:29 -0800
Message-ID: <3E5C6D8D.5050502@sun.com>
To: www-qa-wg@w3.org
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 02:33:39 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:12 GMT