About this QA Process Document (QAPD) template
This is an Appendix to QA
Framework: Operational Examples & Techniques. It contains a
template for a Working Group QA Process Document (QAPD). It is complete in
outline form -- all necessary sections and topics, as required by the
QA Framework: Operational
Guidelines (OpsGL), are represented.
This template should help implementers of QA Framework: Operational Guidelines
(OpsGL) to satisfy those
OpsGL checkpoints that require a QAPD or place requirements on its content --
start with this template and fill in the designated QA-related information.
This will produce a complete QAPD that satisfies the OpsGL requirements.
This template contains prototype statements and content as required of a
QAPD. The prototype statements contain fill-in-the-blank sections, which
appear like this, "[specification name]". A
WG would supply the appropriate information here to complete the prototype
statement and make it an actual QAPD statement.
This template makes reference to an Authoring Guideline or Test
Material manual. This is typically a separate WG document that describes the
format of the test materials and is used to ensure that test material
contributions are in an appropriate format and include the requisite
information to facilitate consistency, assessment, and inclusion of the test
materials. If a WG does not have an Authoring Guideline or Test material
manual, then it is recommended that authoring information be included in its
QA Process Document.
Each subsection relates to a particular Checkpoint of OpsGL. The
appropriate back reference and link immediately follows the subsection title,
and looks like this:
[For OpsGL checkpoint CPx.y]
These may be deleted from the final QAPD text that the WG produces, at the
discretion of the QAPD author.
The following are some fill-in-the-blank items that are commonly used or
repeated in this template:
- [WG name]: the Working Group's
name
- [specification name]: name of the
WG's standard or specification
- [test materials type]: generic type
of the test materials, e.g., test suite, validator, etc.
- [test materials name]: name and/or
acronym of test materials
- [choice of: choice-1 | choice-2 | choice-3 |
other(specify)]: items such these require the QAPD author to
choose one of the "or" choices, or specify another value for the
item.
- [optional]: item is optional.
Status
@@ This is the second revision. Still some stuff to be done. Inconsistent
use of TM name/type. Look out for "test suite". A couple of undefined
concepts: "Development Guide"; @@
The QA Process Document (QAPD) template follows this line.
This is the [DATE] QA Test Material
Process Document for [WG Name].
Comments on this document are invited and are to be sent to the [name of mail list] mailing list [address of list]. An archive is available at
[address of archive].
This document has been produced by the W3C [WG
Name]. The authors of this document are the [WG Name] WG members.
Table of contents
This document describes the QA process for ensuring availability of
comprehensive conformance [test material type -
choice of: test suite(s) | validator tool(s) | checklist |
other(specify)] for the [specification name
| (W3C-[WG Name]-specifications)]. It provides information about the
WG's quality-related logistical and communications setup, contribution
mechanism, licensing policies, publication and maintenance plans, as well as
any other critical processes and operational details needed to produce and
maintain the [test material type].
The [test material type] produced by the
W3C [WG name] will be known as [test material name].
- The [test material type] should be
developed in a public forum such that participation and contributions
from parties interested in developing the [test materials type] is possible and
welcome.
- A test material framework should be developed to provide a uniform
method for producing and managing the [test
material type].
- The [test material type] should be as
comprehensive, functional and complete as possible.
- A standard approach to [test material
type] IPR which meets the needs of both contributors and users
should be established.
- The [test material type] should aid
implementors in developing [specification
name] implementations. Validation and certification of these
implementations are outside the scope of this work.
The[test material
type]should be available in an environment that can be
accessed publicly and shared among developers and users.- The [test material type] will be
hosted on the W3C site once developed. It may also after development be
mirrored at various sites in order to simplify access and enhance
availability to the community.
The [test material name] will be
produced in a way that provides for contributions from developers and
companies in the community. The [test material
name] will be coordinated and supervised by the [WG Name and/or other names]. The WG appoints a
moderator to lead the effort.
[For OpsGL checkpoint CP4.4]
[Choose one: a) if you use the WGs established list
or b) if you set up a dedicated list]
a) The main channel of communication for the [test material name] will be the existing [WG name] mailing list [address]. An archive is available at [address]
b)The main channel of communication for the [test material name] will be a dedicated mailing
list, called [test material name] mailing
list [address]. An archive is available at
[address].
The public web page for QA information is named /Test/ and is available
at: [http://www.w3.org/WGname/Test/]. This
page includes links to this process document, the [test material name] and information about the
[test material name] including:
- an overview or introduction to the [test
material name]
- releases
- how to participate
- how to use the [test material
name]
- [test material name] principles
- acknowledgements
[For OpsGL checkpoint CP4.5]
The [test material type] will be
produced in a public framework with contributions from members of the [WG name], W3C, or the community at large. The
framework will provide a stable mechanism for submission of test materials,
saving information about those tests, version handling, use of the tests, and
so forth.
[For OpsGL checkpoint CP5.2]
[Delete paragraph, if WG has no Authoring
Guideline or Test Material Manual]Contributions should be
submitted in accordance with the[Choose: Authoring Guidelines | Test Material
Manual].The[Choose: AuthoringGuidelines | Test Material
Manual]explain how to write tests for the[test material name]. It defines
the[choose one or more: format | test
description file | schema | other]for the contribution
along with any additional required documenation.
Choose one:
a) Contributions of test materials should be submitted to the [test material name] via the [WG name or test material name @@ this is a or b from
above] mailing list: [address].
b) Contributions of test materials should be submitted to the [test material name] test submission mailing
list: [name-testsuite]-submit@w3.org. An
archive is available at: [address]
The process for test materials contributions is:
- Contributions of test materials are submitted to the framework.
- Receipt of the contribution is acknowledged. This is done via email
directly to the submitter, with a copy sent to the mailing list. The test
receives the "Received"; status.
- The contributed test materials together with the necessary
documentation is saved for future reference.
[For OpsGL checkpoint CP5.4]
Contributions to the [test material
name] are evaluated according to the following criteria.
- Relevance for the particular implementation of [specification name]. It can be decided here
that the particular test is irrelevant to the [test material name], e.g., because it does
not test a normative requirement of the specification.
- Part of the specification being tested.
- Quality of code and documentation. The code must be stable and
not contain any errors; and if written in an xml based language, must be
well-formed. Documentation must be written in accordance with prescribed
information used to formulate and support the [test material name].
- Scenarios that underly the particular test methodology and its
intended scope.
- [optional item]Adherence to the [choice of: Authoring Guidelines | [test material name] Manual].
If a contributed test is judged suitable for inclusion in the [test material type] according to these criteria,
the test is added to the [test material
type] with status "Accepted".
Tests that are judged to be inappropriate for publication are returned to
the contributor. Such tests are archived and not included in the [test material type].
[For OpsGL checkpoint CP8.3
(?)]
Once a test is included into the[test material name], it becomes
subject to the dispute process outlined below.
At any time, any member of the community or WG may dispute the validity of
any test in the [test material name]. This
is done by raising the issue on the [test material
name] mailing list. If the dispute is felt to be valid either by
the community and/orby members of the WG[test material name]Task
Force, the status of the test is changed to "Disputed", and the test is
referred to the WG for detailed review. The possible outcomes of the review
are:
- Error Free. The test and its accompanying documentation have
undergone review by the WG and have been found to be free of errors and
relevant to the specification.
- Disputed: test error.
The validity of the test has been
questioned by one or more members of the community. A consensus
exists in the community or the[test material name]Task
Force WG agrees (or both) that the test is in error. A
resolution is formulated and the test is changed accordingly.
The[test material
name]Task Force has submitted the test and the
associated dispute to the WG for detailed review, along with a suggested
resolution.
- Disputed: specification error. The
One or more members of
the WG has questioned the consistency, clarity, etc. of the part(s)
of the specification addressed by the test is questioned. The [test material name]Task
Force WG agrees that a problem exists with the specification and
submits The[test
material name]Task Force has submittedthe test
and the associated dispute to the WG's erratum process.
[optional section, may be redundant if Authoring
Guideline or Test Material manual exists)]
Each contribution to the [test material
name] must be fully documented, [@@ if there is a
schema (indicated in subsection:Recept and Review of Test Contributions #3)
add:] and conform to the schema for test submissions, which is
available at the [test material name]
website. The documentation provides such information as:
- Name of submitter, date of creation, and, if appropriate,
organization;
- Suggested ID for each test (this may be changed by the moderator to
comply with the identification mechanism of the technical platform);
- Part(s) of the specification being tested. Areas in the specification
being tested should be suitably indicated by either a link to the
relevant part of the specification or a text annotation to the relevant
part of the specification;
- The expected validity of the test;
- If appropriate, a textual annotation containing remarks on the test in
human readable format, for example any scenario which prompted the
writing of the test.
[For OpsGL checkpoint@@@-- is there
one?]
The[test material
name]should consist only of submitted, reviewed and
stable tests.The[test material
name]for all levels will also contain documentation on
the tests it contains, scenarios that have served as a base for them,
commented code, and possibly comments from the editors.
It is proposed that the W3C[WG
name]WG representative act as moderator and controller for
incoming tests. The[test material
name]moderator is chosen by the[WG name]WG. All tests should be
kept for archive purposes, whether they get published or not.
[For OpsGL checkpoints CP4.6, CP6.4]
The [test material name] aims, as
explained above,to help implementers write applications that support
[specification name]. In no way are these
conformance tests to be construed as providing certification or branding of
[specification name] implementations. The
only claim that could be made is that a particular implementation is
conformant to a particular version of the [test
material name]. There are two cases of results of running the [test material type]:
- The implementation fails at least one aspect of the test materials that
is associated with normative requirements of [specification name]. In this case, it can be
asserted that the implementation fails to conform to [specification name].
- The implementation passes the test materials. In this case, all that
can be asserted is that the implementation is conformant to that
particular version of the [test material
name].
[For OpsGL checkpoints CP5.3, CP6.2]
The Contributor hereby makes certain materials, as described below (the
"Materials";), available for use in supporting the World Wide Web Consortium
(W3C). The Contributor hereby grants to MIT, ERCIM, and Keio (the "W3C
Hosts";) a perpetual, nonexclusive, royalty-free, world-wide right and
license to use, copy, modify, create derivatives of and distribute the
Materials, in whole or in part, solely in connection with the W3C, and to
allow others to do the same. W3C Hosts will publish and distribute the
Materials, or any modifications or derivatives thereof, pursuant to the W3C
Software License (20021231), and/or the W3C
Document License (20021231) as modified from time to time.
The Contributor represents that she/he has all rights necessary to
contribute the Materials, and that use of the Materials as contemplated
herein by W3C Hosts does not violate any copyright, patent, trademark, or
contractual obligations.
The Contributor agrees that any derivatives of the Materials created in
connection with the W3C shall be owned by the W3C Hosts. Any publication or
distribution of the Materials or any derivative thereof, will retain
attribution of authorship to the Contributor. Whenever modifications are made
to the Materials, this fact, and the nature of the modifications, will be
clearly identified in the distributed version thereof. The W3C Hosts make no
commitment to support or distribute the Materials.
The [test material name] produced by the
[WG name] Working Group will be distributed
under the W3C [License type - choice of: Document
| Software].
The [test material name] will be
published on the W3C [WG name] website,
available from: [http://www.w3.org/[WGname]/Test/].
The [test material name] will be
published after thorough review by the WG and the community, and with the
consensus of the WG.
The [test material name] will contain
the conformance disclaimer as stated above.
[For OpsGL checkpoint CP6.5]
The [WG name] WG encourages the
publication of test results. To facilitate publication of results, the WG
will make available on its webspace, a place to publish test results. Only
test results that have been supplied or approved by the developer of the
tested implementation will be considered for publication.
The WG will also consider a 'members only' webspace to publish developer
submitted test results. This restricted publication of results may be used
for situations in which the specification and/or tests are being debugged.
For example, when the specification is in CR and a set of tests are being
used to assess the features of the specification by determining what is being
implemented.
[For OpsGL checkpoints CP8.2, CP8.3]
The WG is committed to maintaining the quality and relevance of the [test material name]. This will be done by
ensuring that the test materials are consistent with any erratum and are
updated as needed to reflect the current versions and status of the
specification. The procedures describe above will be used to accept new
contributions as well as to handle tests that are in dispute.