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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

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


Subject: Re: [tag] Groups - TA Anatomy V0.4 (AnatomyTA-v04.doc) uploaded


On 20/09/2007, Durand, Jacques R. <JDurand@us.fujitsu.com> wrote:
>
> >>A test assertion ignores the keywords MUST, SHOULD, MAY because its
> focus is on the
> >> feature to be verified on the item under test.
>
> >I quite disagree with this statement. IMHO a test assertion MUST
>
> The intent behind this ban of RFC2119 keywords was primarily (recalling
> here the outcome of the F2F on this topic):
>
> - those keywords, when used in the referred specification requirement
> (to be addressed by the TA), have no reason to appear in the TA itself.

OK, I see the connotation. If a TA does not reflect the nature of the
requirement
that is one issue. I'm referring to the content of the TA. E.g. the
definition of pass.
Here IMHO the MUST class of language is imperative. The output of X must
be greater than 5V. The XML instance MUST validate using XYZ parser.
Subtle, but  different.
Variations between the TA and the spec are a QA issue, not a language one.




> - The TA states an (abstract) test operation, and what is the fail/pass
> condition(s).

Why abstract? Could you justify that? 'Validate the instance to this schema'
is not abstract in any way.


The operation outcome is of predicative nature: either
> some effect (behavior or condition) is observed, or not. No room for
> MUST, SHOULD or MAY here

Exactly the place where the MUST should appear. Its binary (forget the
predicative bullshit). The condition for a pass MUST be seen in order
to obtain a pass for this test.

Its English we're debating, not testing :-)


(unless we have a convincing example where
> these help?). Now, an effect that actually occurs (predicate = "true")
> can be interpreted as a failure by the TA ("negative" TA) or as a
> success (pass).
>
> Does this clarify the point?

I think we both had variant, clear views on this.

It should be noted that a pass may be 'negative' in some way though.

regards




-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


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