- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Tue, 3 Jan 2006 20:32:56 -0600
- To: "'Tim Boland'" <frederick.boland@nist.gov>
- Cc: <w3c-wai-gl@w3.org>
- Message-ID: <012101c610d7$2f4e9510$056fa8c0@NC6000BAK>
Hi Tim. Some thoughts Gregg "A good test is: * Mappable to the specification (you must know what portion of the specification it tests) Well. The tests don't test the specification. They only test the technique. Since they are attached to the bottom of the technique, yes they are directly mapped to (and connected to) the item that they test. * Atomic (tests a single feature rather than multiple features) Yes - the test is atomic. It tests only the technique above it. * Self-documenting (explains what it is testing and what output it expects) Yes - what the test is testing is immediately above it. the output of the test is specified in the test section (right after the test process) * Focused on the technology under test rather than on ancillary technologies Yes - it tests the technology under test (the technique). * Correct " Correct? Do you mean the test is correct? I presume all of our tests will be correct. Note that there are no tests of the success criteria. There are any number of ways to satisfy most of the success criteria. We always give at least one way of meeting the success criterion and a way to test that you have done that technique. RE 14 test metadata elements identifier, -- Covered by Technique Number? title, -- Covered by Technique Name purpose, -- not needed. All tests are to test the technique above them description, -- provided by process section. status, -- Covered by Status of the technique doc that contains the test specref, -- not needed. All tests refer to the technique above them. preconditions, -- covered by process? (what would a precondition be for us?) (Lets watch this one) inputs, -- Same comment as preconditions expected results, -- Covered by version, -- Hmmmmm. Should we add?? Covered by release date of collection? contributor, -- covered by copyright/credits at bottom of techniques rights, -- covered by copyright statement at bottom of techniques (to be added later - as soon as we get formal format) grouping, and -- no grouping of tests or techniques other than by collection (HTML,CSS, etc) and that is handled by seealso. -- We are looking at whether this should be done or not. May put ties to related advisory techniques+tests. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison _____ From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Tim Boland Sent: Tuesday, January 03, 2006 7:56 AM To: Gregg Vanderheiden Cc: w3c-wai-gl@w3.org Subject: RE: Instructions and team assignments for getting to Last Call Thanks for the update for the TEST portion! >From QA Test FAQ Question #7 ("What makes a good test?") [1], "A good test is: * Mappable to the specification (you must know what portion of the specification it tests) * Atomic (tests a single feature rather than multiple features) * Self-documenting (explains what it is testing and what output it expects) * Focused on the technology under test rather than on ancillary technologies * Correct " Would any of these points apply/be relevant to the TEST portion mentioned in the excerpted message following (as possible additional guidance for the TEST portion)? Also, the QA Note Test Metadata [2] mentions 14 test metadata elements as follows: identifier, title, purpose, description, status, specref, preconditions, inputs, expected results, version, contributor, rights, grouping, and seealso. Some of these are already included in the TEST portion, but would any of these additional terms be useful for the TEST portion mentioned in excerpted message following? Thanks and best wishes Tim Boland NIST [1]: http://www.w3.org/QA/WG/2005/01/test-faq#good [2]: http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/ At 04:41 PM 12/30/2005 -0600, you wrote: Hi Tim, I updated the wiki page for techniques to include the information for the TEST portion. http://trace.wisc.edu/wcag_wiki/index.php?title=Tips_for_editing_techniques Thanks Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Tim Boland Sent: Wednesday, December 28, 2005 3:24 PM To: w3c-wai-gl@w3.org Subject: Re: Instructions and team assignments for getting to Last Call Will there be any consideration of a template for tests, in addition to the Techniques template mentioned in the excerpted message following? Is a test template appropriate or necessary? I think that possibly including such a test template, or at least some additional specific instructions for test creators, might serve to enhance the consistency of test format across the various SCs, as well as simply the process of test description and maintenance. Since tests are to evaluate the implementation of related techniques (which have a template), perhaps tests should also have a template? Just a thought.. Thanks and happy new year! Tim Boland NIST At 03:05 PM 12/21/2005 -0600, you wrote: >4. Draft new techniques and edit existing ones as required, using >the Techniques template in the WIKI <http://tinyurl.com/dgcd7>. Refer >to Tips for editing techniques <http://tinyurl.com/78v78> for detailed >instructions. >5. Include both pass and fail tests in the tests section of each >technique. ("Pass" shows correct implementation of the technique; "Fail" >shows incorrect implementation.) >6.
Received on Wednesday, 4 January 2006 02:33:11 UTC