Re: [tag] revised "Anatomy of a TA"

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

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

> antecedent and consequence seem to be borrowed from a long way away?
> Pre-test and post-test conditions is more usual?
>
> <JD> possibly. We shied away from "condition" that seems to focus more
> on describing a state and seems inappropriate for events or behaviors.
> I like pre-test conditions - more intuitive. But post-test seems to
> suggest that the "test"  is over when these effects occur.

That's exactly the case? This test (singular) is over, and the object under test
has an altered state (the car window now open, whereas in neutral state
it is closed example). Not testing per se, just this test. Hence post -


True for a
> state change which persists, but not for produced behavior/event, the
> observation of which is still part of the test.

In which case it isn't post test state.
This seems to mix the test result with the post test state.



> So maybe we have to be more precise and get to something closer to what
> is proposed in
> http://www.oasis-open.org/committees/document.php?document_id=20661&wg_a
> bbrev=ebxml-iic
> Test assertion =
> (a) ref to spec requirement.
> (b) object under test
> (c) pre-condition (of object under test, possibly includes test env.)
> (d) test trigger (an operation or event)
> (e) test effect (an operation or event)
> (f) post-condition (of object under test, possibly includes test env.)
> (g) final outcome.
> Semantics: when (c)+(d) , then if (e)+(f) the test outcome = (g)
> (="pass" by default)

I disagree. f is simply the state the test object is left in post test?
It is not a part of the test result. Almost a side effect?
Its purpose is to document the fact that any expected state needs
to be preset prior to executing further tests.


> Note: not sure if we need be more specific about the actual test:
> It could consist of bringing the system under state described by (c),

In which case the pre-condition would be false?
pre-condition is the state that the object under test (sorry UUT from now on)
when the test is entered.
If you have to prepare it, then that is a part of the test, possibly
closing the
already open window? You call it a trigger, it could be one of many actions
needed to execute the test. These could be automated or manual.


> then causing the trigger to occur (d), then observing (e) and (f).
Again no. The test outcome (if that's what is meant by e) is one thing
which is of interest. The 'side effect' of f is incidental and simply documented
for later tests. It is not a part of the test, or if it is, then it
isn't a post condition
and becomes a sought test outcome.



In
> the case of schema validation, (d)="validate doc against schema xyz",
> (e)="the validation is successful, warnings are OK". Note: could it be
> in some cases  that trigger and effect are events that do not need to be
> caused for the sake of testing, but naturally occur in the system under
> test.

For the sake of the example.
pre: Intance and schema files available and readable.
post: instance file closed, schema file closed. (which probably constitutes
neutral state)

And no mention of expected result? Possibly zero output from the validator?
(Or n warnings: Any from following list:.......)



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