Re: Thread: TA modeling - RE: [tag] TA Model still weak on tests of structure?

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

On 26/09/2007, Durand, Jacques R. <JDurand@us.fujitsu.com> wrote:

> - challenge: not always clear which category a TA should fall into:
> consider a requirement R1 on a message header structure (either a field
> must be conform to a format, or the header itself be schema-valid).
> Another spec requirement R2 says this message header is expected to be
> produced in response to some operation on the message handler.
> Two options here:
> (a) TA for R1: the IUT is the header document --> a structural test.
> TA for R2: the IUT is the message handler --> a behavior test, but that
> uses TA-for-R1 as pre-requisite (must be satisfied for a "pass" outcome)
> (b) TA for R1+R2: the IUT is the message handler --> a behavior test
> (header structure test is just part of describing the expected behavior:
> to send out a well-formed message header)

I dislike this separation.
Rationale. It's verging on the 'how' the test is executed.
Analysis for test may decide that  1 and 2 should be two separate tests/
one combined test. OK.
Test implementor decides to combine them, generate two test results
to match the tests. The design authority should be happy, the coverage
is complete, where is the problem.
It's too arbitrary a slice based on external logic.
Don't let UML drive this please.




>
>
> 2. So far we have a candidate TA anatomy (for non-prose Tas) like:
>
> - Pre-condition
> - Test trigger
> - Test effect
> - Post-condition (maybe)
>
> It seems to me that the notion of test trigger vs test effect is more
> appropriate for "behavioral"  tests where both "trigger"  and "effect"
> refer to specific events that are clearly serialized over time (in form
> of action on test harness, or of behavior of the IUT).

trigger and effect wrt behaviour and ...
Moving into the realms of words for their own sake?

All tests need a trigger to initiate testing.
All tests have a test outcome or result (assuming that's whats meant by effect).



>
> But for "structural"  tests like validating a doc, I feel the
> distinction is somewhat contrived. There might be a single event (e.g.
> do the doc validation against rule/schema/...) and no "effect" expected
> in response, besides the result of this validation.

Then call it a test outcome or result.


>
> How about using instead

No thanks.


regards

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