This document contains the three QA checklists.
The last three columns are Main, Tech and N/A.
There may be checkpoints that apply to the Main and the Tech group, in this case both will be checked. For example Spec 1.1 is "Include a scope statement" it might be a good idea for both groups to work on this...
A box with "W" are item that I think Wendy owns...
Guideline 1. Commit to Quality Assurance in Working Group activities. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
---|---|---|---|---|---|
1.1 |
Define QA commitment levels for operations, specifications, and test materials. |
[Priority 1] | X | X | |
1.2 |
Commit to test materials. |
[Priority 2] | X | X | |
1.3 |
Commit to complete test materials. |
[Priority 3] | X | ||
1.4 |
Enumerate QA deliverables and expected milestones. |
[Priority 1] | X | X | |
1.5 |
Define QA criteria for Recommendation-track advancement. |
[Priority 2] | X | X | |
Guideline 2. Commit to resource level for Working Group QA activities. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
2.1 |
Address where and how conformance test materials will be produced. |
[Priority 1] | X | ||
2.2 |
Address QA staffing commitments. |
[Priority 1] | W | ||
2.3 |
Request allocation of QA resources to the Working Group. |
[Priority 1] | W | ||
Guideline 3. Synchronize QA activities with the specification milestones. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
3.1 |
Synchronize the publication of QA deliverables and the specification's drafts. |
[Priority 2] | X | X | |
3.2 |
Support specification versioning/errata in QA deliverables. |
[Priority 1] | X | X | |
Guideline 4. Define the QA process. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
4.1 |
Appoint a QA moderator. |
[Priority 1] | X | ||
4.2 |
Appoint a QA task force. |
[Priority 2] | X | ||
4.3 |
Produce the QA Process Document. |
[Priority 1] | X | ||
4.4 |
Specify means for QA-related communication. |
[Priority 2] | X | ||
4.5 |
Define branding policy details. |
[Priority 3] | X | X | |
Guideline 5. Plan test materials development. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
5.1 |
Define a framework for test materials development. |
[Priority 2] | X | ||
5.2 |
Ensure test materials are documented and usable for their intended purposes. |
[Priority 1] | X | ||
5.3 |
Define a contribution process. |
[Priority 2] | X | ||
5.4 |
Address license terms for submitted test materials. |
[Priority 1] | X | ||
5.5 |
Define review procedures for submitted test materials. |
[Priority 2] | X | ||
Guideline 6. Plan test materials publication. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
6.1 |
Ensure a suitable repository location for test materials. |
[Priority 1] | X | ||
6.2 |
Define the licenses applicable to published test materials. |
[Priority 1] | X | ||
6.3 |
Describe how and where the test materials will be published. |
[Priority 2] | X | ||
6.4 |
Provide a conformance verification disclaimer with the test materials. |
[Priority 1] | X | X | |
6.5 |
Promote testing and the publication of test results. |
[Priority 2] | X | X | |
Guideline 7. Plan the transfer of test materials to W3C if needed. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
7.1 |
Perform a quality assessment of any test materials that are candidates for transfer. |
[Priority 2] | X | ||
7.2 |
Identify sufficient staff resources to meet the needs of any transferred test materials. |
[Priority 1] | W | ||
7.3 |
For any transferred test materials, resolve all IPR issues with the external party that produced the test materials. |
[Priority 1] | W | ||
Guideline 8. Plan for test materials maintenance. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
8.1 |
Provide for the long-term maintenance of the contribution and review procedures. |
[Priority 3] | X | ||
8.2 |
Specify a test materials update procedure to track new specification versions/errata. |
[Priority 1] | X | ||
8.3 |
Identify a procedure for test validity appeals. |
[Priority 2] | X |
Guideline 1. Define Scope. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
---|---|---|---|---|---|
1.1 |
Include a scope statement. |
[Priority 1] | X | ||
1.2 |
Illustrate scope. |
[Priority 2] | X | X | |
1.3 |
Illustrate functional details. |
[Priority 2] | X | X | |
Guideline 2. Identify what needs to conform and how. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
2.1 |
Identify classes of product. |
[Priority 1] | X | ||
2.2 |
For each class of product, define the conformance requirements. |
[Priority 1] | X | X | |
2.3 |
Identify the applicable specification categories. |
[Priority 3] | X | ||
2.4 |
If there are several classes of products, define their relationships and interaction with other dimensions of variability. |
[Priority 2] | X | ||
Guideline 3. Address the use of profiles, modules and levels to divide the technology. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
3.1 |
Indicate whether or not the use of profiles is mandatory for conformance. |
[Priority 1] | ? | ||
3.2 |
If profiles are chosen, define any minimal requirements. |
[Priority 2] | ? | ||
3.3 |
If profiles are chosen, address rules for profiles. |
[Priority 2] | ? | ||
3.4 |
If modules are chosen, indicate any mandatory conditions or constraints on their usage. |
[Priority 1] | ? | ||
3.5 |
If profiles, modules or levels are used, define their relationships and interaction with other dimensions of variability. |
[Priority 2] | ? | ||
Guideline 4. Identify the relation between deprecated features and conformance. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
4.1 |
Identify each deprecated feature. |
[Priority 1] | X | X | |
4.2 |
For each class of product, specify the degree of support required for each deprecated feature and the conformance consequences of the deprecation. |
[Priority 1] | X | X | |
4.3 |
If deprecated features exist, define their relationships and interaction with other dimensions of variability. |
[Priority 2] | X | X | |
4.4 |
Include an explanation for the deprecation. |
[Priority 3] | X | X | |
4.5 |
Include examples to illustrate how to avoid using deprecated features. |
[Priority 3] | X | X | |
4.6 |
Identify each obsolete feature. |
[Priority 3] | X | X | |
Guideline 5. Define discretionary items. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
5.1 |
State the circumstances for when discretionary items are allowed. |
[Priority 1] | X | X | |
5.2 |
For implementation dependent values or features, address the allowable differences between implementations. |
[Priority 1] | X | X | |
5.3 |
Indicate any constraints on the number of choices/options that can be implemented for discretionary items. |
[Priority 2] | X | X | |
5.4 |
Promote consistent handling of discretionary choices. |
[Priority 2] | X | X | |
5.5 |
If discretionary items are used, define their relationships and interaction with other dimensions of variability. |
[Priority 2] | X | X | |
Guideline 6. Allow extensions or not |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
6.1 |
Indicate if the specification is extensible, and if extensions are allowed, define their scope and constraints. |
[Priority 1] | |||
6.2 |
Prevent extensions from contradicting the specification. |
[Priority 1] | |||
6.3 |
Define a uniform mechanism to create an extension. |
[Priority 3] | |||
6.4 |
Require that extensions be published. |
[Priority 3] | |||
6.5 |
Mitigate the impact of extensions on interoperability. |
[Priority 3] | |||
6.6 |
If extensions are allowed, define their relationships and interaction with other dimensions of variability |
[Priority 2] | |||
Guideline 7. Clearly identify conformance requirements. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
7.1 |
Use conformance key words. |
[Priority 1] | |||
7.2 |
Distinguish normative and informative content. |
[Priority 1] | |||
7.3 |
Use consistent terminology. |
[Priority 1] | |||
7.4 |
Provide a fast way to find conformance information. |
[Priority 2] | |||
7.5 |
Make normative reference to specifications on which the current specification depends |
[Priority 1] | |||
Guideline 8. Document the conformance policy. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
8.1 |
Specify any universal requirements for minimum functionality. |
[Priority 2] | |||
8.2 |
If special conformance concepts are used, include a definition in the specification. |
[Priority 1] | |||
8.3 |
Justify any usage of a dimension of variability. |
[Priority 1] | |||
8.4 |
Include a conformance section. |
[Priority 1] | |||
8.5 |
Identify and define all conformance designations. |
[Priority 1] | |||
Guideline 9. Specify how to make conformance claims. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
9.1 |
Provide specific wording of the claim. |
[Priority 3] | |||
9.2 |
Provide a conformance disclaimer. |
[Priority 3] | |||
9.3 |
Impose no restrictions about who can make a claim or where claims can be published. |
[Priority 1] | |||
9.4 |
Provide an Implementation Conformance Statement proforma. |
[Priority 3] | |||
9.5 |
Require the ICS be completed as part of the conformance claim. |
[Priority 3] | |||
Guideline 10. Provide test assertions. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
10.1 |
Provide test assertions |
[Priority 2] | |||
10.2 |
Provide a mapping between the specification and the test assertions list. |
[Priority 2] |
Guideline 1. Perform a functional analysis of the specification and determine the testing strategy to be used. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
---|---|---|---|---|---|
1.1 |
Define the test suite scope |
[Priority 1] | X | ||
1.2 |
Identify the specification(s) to be tested. |
[Priority 1] | X | ||
1.3 |
Analyze the structure of the specification, partition it as appropriate, and determine and document the testing approach to be used for the test suite as a whole and for each partition. |
[Priority 1] | X | ||
Guideline 2. Identify and tag testable assertions within the specification. |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
2.1 |
Identify and list assertions within the specification. |
[Priority 1] | X | ||
2.2 |
Metadata must be associated with test assertions, enabling test developers, the test-management system, the test-execution framework, and the results-reporting process to make useful distinctions between groups of tests. |
[Priority 2] | X | ||
Guideline 3. Provide a test management system |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
3.1 |
The Working Group must provide a test management system |
[Priority 1] | X | ||
3.2 |
The test management system must associate tests with metadata. |
[Priority 1] | X | ||
3.3 |
Test management system must allow filtering based on metadata. |
[Priority 2] | X | ||
3.4 |
Test management system must support results. |
[Priority 2] | X | ||
Guideline 4. Provide a test framework |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
4.1 |
Provide a test framework |
[Priority 1] | X | ||
4.2 |
Prototype the test framework |
[Priority 2] | X | ||
4.3 |
Automation of testing is encouraged. |
[Priority 2] | X | ||
Guideline 5. Provide results reporting |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
5.1 |
Test Materials must support results reporting |
[Priority 1] | X | ||
5.2 |
Results reporting framework should generate a unified report. |
[Priority 2] | X | ||
5.3 |
Results reporting framework must indicate result status of each test. |
[Priority 1] | X | ||
5.4 |
Results reporting framework should allow filtering based on metadata |
[Priority 2] | X | ||
Guideline 6. Plan for conformance testing |
|||||
Nbr | Checkpoint | Priority | Main | Tech | N/A |
6.1 |
Organize conformance testing activities. |
[Priority 1] | X | ||
6.2 |
Encourage Vendors to publish test results. |
[Priority 3] | X |