W3C home > Mailing lists > Public > public-qa-dev@w3.org > August 2006

Re: Test Cases and Comparisons Re: Minutes for Teleconference on 30 August, 2006

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Thu, 31 Aug 2006 19:08:16 +0200
Message-ID: <44F71780.6020707@w3.org>
To: Johannes Koch <johannes.koch@fit.fraunhofer.de>
Cc: public-wai-ert@w3.org, www-qa@w3.org, QA Dev <public-qa-dev@w3.org>

Hi Johannes,

You are absolutely right on both points! In both cases the property would be earl:testable but once pointing to an earl:TestCase class, and the other time to an earl:TestRequirement class. Also the last example mentioned should have the caps on as you correctly point out.

Thanks,
  Shadi


Johannes Koch wrote:
> 
> Shadi Abou-Zahra wrote:
>> 1. The first assumption is that a test case is an atomic test in the 
>> context of the test suite. The test case consists of the test 
>> description (aka test procedure) and the required files to execute the 
>> procedure. So, for each executed test case you need an assertion to 
>> express the outcome from the validator:
>>
>> <earl:Assertion rdf:ID="assertionX">
>>  <earl:testcase 
>> rdf:resource="http://example.org/validator/css-tests/test-X" />
>>  ...
>> </earl:Assertion>
> 
> Stop! Didn't we say, the predicate is called earl:testable and the 
> object is an earl:Testable or a subclass thereof (e.g. earl:TestCase or 
> earl:TestRequirement)?
> 
> So it would be
> 
> <earl:Assertion rdf:ID="assertionX">
>   <earl:testable
>  rdf:resource="http://example.org/validator/css-tests/test-X" />
>   ...
> </earl:Assertion>
> 
> 
> 
>> 2. The second assumption is that there may be a grouping of test cases 
>> in the test suite to address requirements. For example, to test that 
>> the validator adequately addresses a specific CSS functionality, you 
>> may need to execute one or more test cases to determine. For each 
>> statement you want to make about such a requirement, you need a 
>> different "sort" of assertion:
>>
>> <earl:Assertion rdf:ID="assertionY">
>>  <earl:requirement 
>> rdf:resource="http://example.org/css-spec/functionality-Y" />
>>  ...
>> </earl:Assertion>
> 
> Same as above.
> 
>> Note: We included the optional properties dc:title, dc:description, 
>> dc:hasPart, and dc:isPartOf in the earl:testable statement 
>> (super-)class. This provides a very rudementary method to describe 
>> tests until an appropriate test description language is available. 
>> Here is an example of using this:
>>
>> <earl:testcase rdf:about="http://example.org/validator/css-tests/test-X">
> 
> <earl:TestCase ...>
> 
>>  <dc:title xml:lang="en">Test Case X</dc:title>
>>  <dc:description>take file A and run it with parameters o,p, and 
>> q</dc:description>
>>  <dc:isPartOf 
>> rdf:resource="http://example.org/css-spec/functionality-Y" />
>> </earl:testcase>
> 
> </earl:TestCase ...>
> 

-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe | 
Chair & Staff Contact for the Evaluation and Repair Tools WG | 
World Wide Web Consortium (W3C)           http://www.w3.org/ | 
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ | 
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ | 
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ | 
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France | 
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 | 
Received on Thursday, 31 August 2006 17:08:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:46 GMT