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

Re: Quick Tips volunteers -- an offer

From: Patrick Curran <Patrick.Curran@sun.com>
Date: Mon, 17 Feb 2003 10:58:23 -0800
Message-ID: <3E5130CF.2010008@sun.com>
To: Karl Dubost <karl@w3.org>
CC: www-qa-wg@w3.org

I'd like to see an explicit reference to the identification of 
assertions in the spec. In my experience, this is what really helps to 
ensure that the spec is unambiguous and testable...

It might also be useful to explain in the overview the importance of 
constantly viewing and reviewing the spec from the perspective of 
"testability".

Karl Dubost wrote:

>
> At 8:14 -0700 2003-02-11, Lofton Henderson wrote:
>
>> OpsGL:  Peter, Kirill, Dom, Lynne, Andrew, Olivier (optional)
>> SpecGL:  Dimitris, Karl, Peter, Lofton, Lynne, Andrew, Olivier 
>> (optional)
>
>
> SpecGL: Plan Conformance requirements for your specification.
>
> The meaning of that is to organize and specify clearly what needs to 
> be done for the Conformance. It doesn't mean that you will be able to 
> define everything the first day of the WG, but that people can have a 
> kind of Roadmap or todo list for the Conformance.
>
> How-to organize your conformance plan.
>
> 1. Identify someone to take care of the Conformance requirements.
>     Often it will be the QA person. This person will be in charge to 
> write the materials for the editors of the spec or to push people in 
> achieving their requirements.
>
> 2. Identify all classes of product:
>     Write down in an email all products that your spec will address 
> and send it to the WG mailing-list. Often if you have written a 
> requirement doc for the technology, you will have the class of products.
>
> 3. For each product define the conformance requirements
>     In the  list you have made you can write down the list of 
> requirements for each product. See Ruby Spec
>
> 4. Be consistent in the vocabulary
>     It will be easier if you define a clear vocabulary in your spec 
> and you stick to it. try to use the QA Glossary
>
> 5. Define minimum functionality
>     After drafting your requirequements for each product, you define 
> what's absolutely necessary to pretend to have a basic implementation.
>
> 6. Deprecated feature
>     Read the old version of the spec and identify if something has 
> changed. How the new classes of product should deal with this new 
> features. Discuss that with the WG.
>
> 7. Conformance section
>     The conformance section MUST appear in the table of contents, so 
> organize that with the editor of the Spec.
>
> 8. Define Branding
>     In fact, It's how people will be able to make a claim that they 
> are conformant implementing the spec in one way or the other, 
> authoring content or tools implementing the spec, etc... It's why it's 
> important to define the class of products.
>
> 9. Give an ICS
>     It will help the user of the spec to claim how he has done the thing.
>
Received on Monday, 17 February 2003 13:59:04 GMT

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