16 messages in org.oasis-open.lists.tagRE: [tag] Groups - TA Anatomy V0.4 (A...| From | Sent On | Attachments |
|---|---|---|
| jdur...@us.fujitsu.com | Sep 19, 2007 5:24 pm | |
| Dave Pawson | Sep 19, 2007 11:57 pm | |
| Dave Pawson | Sep 20, 2007 12:21 am | |
| step...@systml.co.uk | Sep 20, 2007 6:47 am | |
| Dave Pawson | Sep 20, 2007 6:53 am | |
| step...@systml.co.uk | Sep 20, 2007 10:45 am | |
| Durand, Jacques R. | Sep 20, 2007 2:36 pm | |
| step...@systml.co.uk | Sep 20, 2007 11:29 pm | |
| Dave Pawson | Sep 20, 2007 11:53 pm | |
| Dave Pawson | Sep 21, 2007 12:01 am | |
| Dave Pawson | Sep 21, 2007 12:05 am | |
| step...@systml.co.uk | Sep 21, 2007 9:10 am | |
| step...@systml.co.uk | Sep 21, 2007 1:15 pm | |
| Dave Pawson | Sep 21, 2007 10:36 pm | |
| step...@systml.co.uk | Sep 22, 2007 2:26 am | |
| Dave Pawson | Sep 22, 2007 5:11 am |
| Subject: | RE: [tag] Groups - TA Anatomy V0.4 (AnatomyTA-v04.doc) uploaded | |
|---|---|---|
| From: | step...@systml.co.uk (step...@systml.co.uk) | |
| Date: | Sep 20, 2007 11:29:41 pm | |
| List: | org.oasis-open.lists.tag | |
But this does seem to clash somewhat with the strong use case of the practice of copying items from the spec straight into the TA (strong in that we agree it avoids the possibility of varying the normative expression of the spec requirement item).
For example the SOAP spec we mention on the Wiki http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/
That seems to be one of the main use cases for the 'prose' element of the model.
Also there is the use of the Ref to the spec item which was agreed could and maybe should be used to avoid redundancy. Since I was concerned that the links to IDs of the spec items could be weak and prone to breaking so argued for including actual prose too, maybe there is a possible best practice here to use a Ref + predicate rather than Ref + prose, so avoiding those RFC2119 keywords.
But maybe there is a case though for recommending against the use of the RFC2119 keywords in the 'flow' where there is more likelihood of a use of the flow for automated test case generation which would require predicates formalised with a predicate expression that XQuery, XPath or OCL, etc, might provide.
-Stephen
Quoting "Durand, Jacques R." <JDur...@us.fujitsu.com>:
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. In other words, whether a normative statement in the referred specification is a MUST, SHOULD or MAY, does not affect the way the TA is written - it only affects the way the result of this TA is interpreted in a broader conformance context (e.g. a conformance profile).
- The TA states an (abstract) test operation, and what is the fail/pass condition(s). 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 (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? It seems we agree that there is a mandatory nature in the association: {observed effect, TA outcome (fail/pass) } but it needs not use MUST keyword to be stated.
-Jacques
-- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk