OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?

2008/6/23 Shawn <sgrover@open2space.com>:
> Dave Pawson wrote:
>> I'm interpreting a 'may' etc as test it, but you can't fail
>> anything without a 'shall' or 'must'. (Right or wrong I don't know).
> A few of us had a discussion on this yesterday.  A "must" and "may"
> conditions can become clear test cases.  With regards to a must, it is a
> pass/fail.  It does it or it doesn't.
> A may condition is also a pass/fail,

The result of the test is either pass or fail.....

 but with a little more consideration.
>  If the implementation or application handles a "may" condition, then this
> is pretty much the same as the must.

I'd suggest that's a pre-condition Shawn?
An app that doesn't implement a 'may' clause isn't at fault
and should not be penalized for that decision.
Hence 'if implemented':
  run the test
  Display the result (but not as a pass/fail)

I differentiate between a pass/fail that results in the overall result
of the test run being a fail (e.g. failing a shall clause)
a test failure against a may clause, where the vendor
(should) want to know about the failure, but we cannot
fail the entire test run because of a 'may'.

An overall test result = and(all mandatory test results).
Boolean and, so 1 or more fail and the overall result is a fail.

 However, if the spec says "you may do
> XXX, but if you do not then you need to ensure YYY", then a check for YYY
> can be done to ensure the may condition is a pass/fail.  If the standard
> does not provide the "or" part of an either/or setup then the test can be
> ignored if the may condition is not implemented.  again, pass/fail (or in
> this last case, ignored)

I'm not sure I understand that part.
I can see the pre-conditions.
If we cannot (programmatically) determine if
a clause has been implemented we are into
an untestable clause (maybe)
or we run the test and issue a warning only
which the vendor responds to by shrugging his shoulders, knowing
he didn't implement that one.

Perhaps rather than untestable, we report it back to the main TC as unclear
(how to determine if the clause is implemented or not)


Dave Pawson

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]