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...
Story 1: Think about quality early
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...
Story 2: Jump-starting a testing
effort
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...
Story 3: Test-suite transfer
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...
Story 4: Test suite licensing
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...
Story 5: Test development 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.
WG Chairs and staff contacts are
overworked. They share a lot of the same concerns and pressures as specification editors.
Common problems include: are:
- never enough motivated people to do the work;
- deliverables delivered late;
- licenses and legal hassles;
- too much to do, so little time
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.
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:
because of the diversity amongst W3C's working
groups makes it is difficult (but not impossible)
to craft simple normative rules for all;as past experience has shown, imposing such rules in
diverse, for people-centric processes that need to be flexible and
adaptable to the environment, technology, and WG, practical guidance and
suggestions rather than stringent rules is called for. is often not
well received -- too authoritarian and fierce.
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
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:
- people resources;
- deliverables and their schedules;
- interaction with W3C and the world;
- W3C process, licenses, and other legal issues.
IPR,
etc.
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.
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:
- QA Framework: Specification Guidelines [QAF-SPEC]
QA Framework: Test Guidelines [QAF-TEST]- Test Topics on the Wiki [Wiki link]
- Tips for Getting to Recommendation Faster [REC-TIPS]
- anything else?
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
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]