The QA Handbook

W3C Working Draft 10 May 2004

This version:
Latest version:
Previous version:
This is the first published version. It supersedes
Lofton Henderson
See Acknowledgments.

1. Introduction & roadmap

1.1. Five simple stories

Here are The following five use cases for The QA Handbook (QAH), told as stories, they show when and how QAH could be helpful. to chairs and staff contacts. They cover five different situations that might typically arise over the life of the WG.

The QA Handbook could be useful to chairs and staff contacts at Charter time...

The Charter-drafting team of a new Working Group, led by staff contacts and co-Chairs, looks through The QA Handbook. Following the Good Practices in the On the advice of the Early-commitment and Planning Good Practice bits module, the team debates how much it can realistically commit to at this early stage. After deciding on some test materials deliverables, milestones, and specification spec synchronization that are considered it considers to be safe commitments, the team it uses the provided Charter Template to write include thisit in the draft Charter.

Or it could be a big help to a chair who is trying to jump-start a test suite project...

An existing Working Group has just finished writing its Requirements and Use Cases documents and has begun to draft its specification. At the same time, it is taking a first look at its test suite (TS) plans. As recommended in the The QA Handbook, the Chair jump starts the TS project by appointing a QA Point of Contact Moderator and part-time Test Suite team TS , whose first output is a quick QA Test Suite Process Document (TSPD) using the provided TSPD template.

Or maybe the chairs and staff contacts are pondering the steps to transfer of a test suite from an external entity...

A Working Group has re-chartered to finish a Second Edition of its specification and to develop the next functional version.2.0. The group did not develop a test suite (TS) during its first charter, but a collaboration of outside organizations and an industry consortium has developed one. The Chair and staff contacts have negotiated an agreement in principle to transfer it the test suite to a stable home in W3C. In The QA Handbook, they find a handy checklist of preliminary steps, requirements, and specific activities for a smooth transfer.

Or maybe they need to take pre-emptive action due to looming possible license-issue hassles...

A Working Group is almost ready to request Candidate Recommendation (CR) and has gotten a comprehensive test suite (TS) together for the CR's trial implementation period. As the Chair starts to arrange for publication of the test suite, TS, she finds the WG split on issues around TS which test suite distribution licenses to use. Consulting The QA Handbook, she finds a discussion of the pros and cons of the W3C licenses (the Software License and the Document License), and advice on resolving devising an optimal licensing strategy.

Or maybe they can borrow the experience of other W3C WGs for various useful and common test suite processes...

A Working Group has built and released a basic test suite (TS) for its specification. A staff contact has been given the Action Item to plan its expansion to a more comprehensive test suite, TS, by leveraging and integrating the large test collections of several early implementors. Rather than figure out the issues and write a Test Contribution & Review process from scratch, he looks at the summary advice in The QA Handbook. QAH points him both to some useful templates and to Wiki topics on testing that more detailed stuff in QA Framework: Test Guidelines [QAF-TEST] significantly shortening his effort to complete completion of his action item.

1.2. Why QAH?

WG Chairs and staff contacts are overworked. They share a lot of the same concerns and pressures as specification editors.

Common problems include: are:

A lot of groups have faced these issues. Moreover, and there is a growing body of experience in W3C about what works and what doesn't. QAH aims to pull this together.

1.3. Audience and purpose

The QA Handbook (QAH) is intended for chairs and staff contacts of W3C Working Groups. These include both the process-savvy and novices. alike.

QAH is a non-normative handbook about the process and operational aspects of applying good practices and quality assurance techniques to WG activities, including developing Recommendations and conformance tests. the quality practices of WG life -- mostly test suite stuff, but also some specification quality assurance. Guidance in the QAH is supported by real-world stories and examples. It aims to flags avoidable pitfalls and to provides techniques, tools, and templates that will facilitate and accelerate the work of the WGs.

Because there is no normative content in QAH, conformance to QAH is not an issue. QAH takes this approach for several reasons, chiefly:

Advice is presented in the imperative voice as in Principles and Good Practices. sections. The aim is to present helpful guidance gathered from the experience of W3C WGs. If it looks helpful, follow it. If not, don't -- there's no consequence. These suggestions will generally be helpful and enhance the quality of the work of a WG. However, each suggestion should be applied or not depending on the specific situation of the WG

1.4. QAH scope

The QA Handbook (QAH) is a practical guide for integrating quality assurance techniques and good practices into the WG. The main focus is on activities and factors things that influence the development and implementation of specifications and tests, especially:

However, the scope is not limited to specifications and tests, but includes the total environment in which the WG operates. The goal of QAH is to capture and share current good practices, point out hazards along the way, and suggest new modes of operation to help the WGs pursue their missions in the most timely and effective ways.

1.5. Other QA Framework resources

In addition to this QAH, chairs and team contacts as well as others such as editors, test builders, and general W3C membership, will find additional guidance and practical advice in other QA documents, including:

advice specific to their roles in the other parts of the QA Framework:

Chairs and staff contacts will likely also get involved with these eventually. A brief orientation to the rest of the QA Framework an appendix to this document An appendix provides a brief orientation to these documents, presented in terms of various WG roles, is provided in an appendix

1.6. Roadmap to the rest of QAH

After this orientation section, QAH contains four topical modules:

Each presents advice and guidance about tasks that contributing to the WG's some aspect part of the WG's realization of quality specifications and tests. and quality activities. These tend to have a chronological correspondence to phases (i.e., Rec-track stages) of the WG's activities. Earlier is better, but later is better than never. Figure 1 is There's a graphic depictsion of when, in a WG's life, the various QAH topics are ideally dealt with and applicable:

[TBD. Here is planned to be embedded a chopped down version of the OpsGLchronology diagram]