TA Model

[stephen.green@systml.co.uk]

I don't like restricting the flow part of the model to just
conditions, trigger and result. I question whether there is
always a trigger as such (although in some test technologies
there might always be one, but we are to be independent of
that I think). I question whether there is always *only* a
trigger and result.

In the UBL work there is absolutely nothing in the spec to
specify a trigger or a result, at least not normatively.
I therefore feel there is a need to specify a 'test' which
can be standalone in the TA.
example:

An invoice has the following element as its document root
'Invoice'.

Or even

An invoice MUST have the following element as its document root
'Invoice'.

Either seems appropriate since the latter could be exact wording
from the spec (but I'm over-selling that argument I fear, sorry).

Secondly, during the running of a test there may be a need to
watch for certain things which are not exactly the result as
such. So the extra 'test' element could assert the need to watch
for these things and perhaps terminate the test if they occur
or assert that they have an impact of some sort on the result
or the verdict irrespsctive of the result. Typically this test
element would be stated as a predicate but perhaps not necessarily
(to allow for all kinds of test methodologies and test assertion
authoring methodologies).

Perhaps an attribute in each element (trigger, etc) could indicate
whether the content evaluates to a boolean or there could be some
such thing to express any constraints on the content (which would
align with the UML Testing Profile which has the ability to add
such constraints).


-- 
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