oiic-formation-discuss message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oiic-formation-discuss] Interoperability versus Conformity
- From: robert_weir@us.ibm.com
- To: jerome.davies@pdghelicopters.com
- Date: Wed, 11 Jun 2008 19:41:43 -0400
"Jerome Davies" <jerome.davies@pdghelicopters.com>
wrote on 06/11/2008 12:10:18 PM:
> -
> I'm not sure I have a clear idea of what I have in mind,
> partially due to my lack of knowledge of the Standard. However
> it seems that to have the best shot at a comprehensive
> auditable standard of interoperability we need to do two things
>
> 1. Define interoperability and what it covers
> 2. Tie these definitions to the standard
>
> I could be way off with this of course.
>
The traceability of our requirements is critical.
If we have a test document that says "verify that the application
does X" then we better be sure we can cite chapter and verse of the
ODF standard to where X is called for.
In fact, one approach, which I've seen done with another
standard, is to read through the standard with a red pen and circle every
testable statement that you find. Then transcribe these statements
into a spreadsheet, assign each one an ID and a category (requirement,
recommendation, permission, possibility, and then define one or more tests.
Picking a page in ODF at random, I see:
15.4.26 Font Relief
Use the style:font-relief property to specify whether
the font should be embossed, engraved, or neither.
<define name="style-text-properties-attlist"
combine="interleave">
<optional>
<attribute name="style:font-relief">
<choice>
<value>none</value>
<value>embossed</value>
<value>engraved</value>
</choice>
</attribute>
</optional>
</define>
In this case, I'd parse this as a recommendation,
since it says "should" rather than "shall". I'd
probably turn this into test cases stated formally as something like this
(pseudo-code -- in reality we would need to define our own or borrow a
similar assertion syntax):
IF (style:font-relief DOES-NOT-EXIST) THEN assert(display
of font is not embossed and not engraved)
IF (style:font-relief EQUALS none ) THEN assert(display
of font is not embossed and not engraved)
IF (style:font-relief EQUALS embossed) THEN assert(display
of font is embossed)
IF (style:font-relief EQUALS engraved) THEN assert(display
of font is engraved)
IF (style:font-relief EQUALS foo) THEN assert(error
"foo is not a valid attribute value of style:font-relief")
So we have 5 testable propositions, or assertions,
from that single ODF feature. Turning these assertions into actual
test cases should be almost a mechanical process, with little judgement
involved. Hopefully we can automate much of it.
That's one way of doing it, but not the only way.
It does enable a useful division of labor, where XML/ODF experts
read the standard and transcribe provisions in a formal notation, while
those with more expertise on the automation side work from the test assertion
notation.
But now I'm getting ahead of myself. Damn this
contagious enthusiasm!
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]