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

[stephen.green@systml.co.uk]

My penny's worth below:

Quoting Dave Pawson <dave.pawson@gmail.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   
>> contain hard
> statements, hence MUST contain MUST statements to avoid lack of clarity in
> interpretation. It isn't a case of ignoring them, more a case of
> responding to them.
> In that response the person designing the tests must be given clear
> actions, which
> will include the word MUST, e.g. must measure between 10 and 12.2 volts.

Isn't the main factor here wanting to make the test assertion into an
expression with a boolean evaluation (a predicate - I think we need to
explain that term by the way)?

If there is prose which doesn't evaluate to a boolean (as I think will
likely be the case if it has 'MUST', etc in it) then doesn't there need
to be a best practise (in ceratin contexts) recommendation that the prose
be accompanied by a predicate expression? Hence, I think, a need exists for
an unstructured predicate item in the model (for when the 'structured flow'
is more than what is needed or wanted).

Either:

1., with the standalone predicate
outside the flow but separate from the prose 'narrative':

-* ta
--* narrative
--* predicate
--* flow
---* pre
---* trigger
---* result
---* post

or 2., with the standalone predicate
inside the flow, as an overloading of the result:

-* ta
--* narrative
--* flow
---* pre
---* trigger
---* result (note to say to use this when a standlone predicate is needed)
---* post

or 3., with the standalone predicate
inside the flow, as an a separate item to the result:

-* ta
--* narrative
--* flow
---* pre
---* trigger
---* result (note to say to use this when a standlone predicate is needed)
---* post
---* <not sure what to call the predicate here which could be standalone
      as an alternative to trigger/result>

I prefer 1.

Then the 'narrative' can just be lifted from the spec along with any
MUST, etc reducing any need to reword the spec expression but adding
a predicate expression if necessary (without MUST, etc of course - e.g.
expressed in XQuery, XPath, OCL, XMI, or whatever).

Best regards

-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice