Re: [tag] TA Model

["Dave Pawson" <dave.pawson@gmail.com>]

Thanks for the clarifications Stephen.

On 22/09/2007, stephen.green@systml.co.uk <stephen.green@systml.co.uk> wrote:


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


<grin/> OK, a general term for the 'things we're talking about'!


re flows.

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

A scope issue? I've made the opposite assumption. I'll guess the
actuality is somewhere in between!!

Possibilities. A TA 'defines' a test (at some level of abstraction, TBA)
between the UUT specification and the executable test.

I guess it's up to the group to decide?




 The tests include how to test things (test
> data etc) whereas the TA is more general and indicates what to test.

I'd have a problem with that, insofar as this is too high level.
Test that car is a what level.
Rolling road, 5000rpm, brake max possible (some brake pedal pressure over time)
and measure the time taken for the wheels to stop rotating.
That's also a 'what' to do. Not how.

IMHO it also lacks, if the test passes, carry on testing with Test Number xxxx.
I.e. the control flow through the test suite.
That's how  envisaged this groups output in terms of scope. Exactly what to do,
not in the abstract, which is the closest layer to the UUT specification.



> So the flow gets interpreted (variously) as the kinds of sequences
> you describe but such sequences could depend on the test methodology.

OK, lets agree to differ on that, perhaps it could be added as an
agenda item for the telcon/ F2F?


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

Preconditions are presumed, not checked IMHO. If the UUT needs
preconditioning that should be an exception not a rule.

We seem unable to agree to the boundaries of a test, I won't argue
that one any further.


regards



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