Re: [tag] TA Model

[stephen.green@systml.co.uk]

Quoting Dave Pawson <dave.pawson@gmail.com>:

> On 22/09/2007, stephen.green@systml.co.uk <stephen.green@systml.co.uk> wrote:
>
>> > Without  a test result the test is a waste of time. It may be an interim
>> > result eventually discarded, but there needs to be a result.
>> >
>>
>>
>> So following this through, if the result is a mandatory element
>> of the flow but the other elements (I use the term element not
>> necessarily in the XML sense) are all optional,
>
> In what sense are you using 'element'? We seem to have
> quite different vocabularies.
>
> A test? A TA? Something else?

Yes, I've been floundering for lack of an agreed word for an item
in our model (I mean those things 'prose', 'pointer', 'result', etc)


>
>
> then a flow can
>> at its simplest be just a formalization (perhaps in an expression
>> language evaluating to a boolean) of the prose or pointer
>>
>> -TA
>> --prose
>> --pointer
>> --flow
>> ---result
>
> flow? The above list looks like its the process steps from reading
> a requirement through to running a test?
>

see below

>
>
>>
>> The more complex flow would cover joining flows together with in
>> a series say where conditions guard the join between a result and
>> the next trigger
>>
>> -TA
>> --prose
>> --pointer
>> --flow
>> ---trigger
>> ---result
>> ---post
>> --flow
>> ---pre
>> ---trigger
>> ---result
>
>
> Interpreting this into a test environment, is this the same as
> saying that running test n+1 depends on the success / failure
> of test n?

Yes but that is more for the test designer and not so much for the
TA writer - I think we are distinguishing a TA as precursor to all
sorts of possible tests. The tests include how to test things (test
data etc) whereas the TA is more general and indicates what to test.
So the flow gets interpreted (variously) as the kinds of sequences
you describe but such sequences could depend on the test methodology.

I think the SOAP test assertions are very close indeed to what we are
modeling
http://www.w3.org/TR/soap12-testcollection/
It has

-Assertion (our TA)
--location of assertion (our pointer)
--text copied from spec (our prose)
--comments (we don't have)
--test (our flow) 0..n
---description (we don't have here in model but corresponds to prose  
not copied)
---messages 2..2 ? (our trigger and result, specialized here as SOAP messages)

>
> If that's the case, I'd agree, and note that 'test flow', i.e. the sequence
> of tests to be followed on any test run, has not been clearly addressed.
> Most generally, it utilizes the test numbers/ID values of tests.
> Then any test has
>
> if pass, goto TestNumber XXX | Test(id='XXX')
> else
>   goto TestNumber YYYY | Test(id='YYYY')
> fi
>

I agree. But a way to do it seems to me to add a pointer to
the precondition and an ID to the flow step or to the items in the flow
so result or postcondition (important to allow either) of step XXX can be
the precondition or trigger (important to allow either) of step YYYY.

>>
>> >
>> >> Perhaps an attribute in each element
>
> Suggest that's insufficient, if my understanding of the terms is accurate.
>
>
>> >
>> > I've not seen any evidence that XML is helpful here.
>> >
>>
>> I was thinking there could be something in the model which
>> describes the evaluation of the expression used (irrespective
>> of whether it is XML), like:
>>
>> -TA
>> --prose isTrueFalse=true
>> --pointer isTrueFalse=false
>> --flow
>> ---result isTrueFalse=true
>
> Sorry Stephen. I've no context into which that may be placed.
> I dont understand it.
>
>
>
>> I still think any constraints forbidding keywords 'MUST' are best applied
>> just to the flow, not to the prose and certainly (of necessity) not to
>> the pointer/reference.
>
> I think it would be folly to prohibit words from any TA.
> All it needs is clarity in terms.
>
> regards
>
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk
>


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