Re: [tag] TA Model

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

On 22/09/2007, stephen.green@systml.co.uk <stephen.green@systml.co.uk> wrote:
> So how about
>
> 1. introducing steps called 'Test' into the flow with IDs,
> 2. making such 'Test' steps multiple occurrence
.. of what Stephen?

> 3. adding a unique ID to each part of the step
> 4. allowing preconditions and postconditions to reference parts of another
>     step

Why? IMHO a test should be independent. Dependencies on other tests goes
against this. Perhaps such a test is at too low a level?


> 5. adding 'Previous Test' and 'Following Test' pointers to each step

I find this confusing. Test flow / routing shouldn't be set by the test.
It may be that a test could be re-used in different places?


> 6. adding 'Comment' outside the flow
> 7. adding something to state what constitutes overall pass or fail of TA
> 8. adding specification quote
or reference. By whatever means are appropriate.
> 9. being explicit in the name of the part about it being an ID or reference

I don't understand this one.


>
> Is that too complex or just complex enough? Maybe most things are optional
> I suggest where there is a reference such as 'Test Trigger Cross Reference'
> then it could be implemented as a hyperlink if the implementation is HTML
> (so it might not add complexity all that much).
>
> Extended example:
>
> Test Assertion ID: TA-101c
> Specification requirement ID: < req 101>
> Specification requirement quote: "Purchase Order Receipt documents
> must be XML documents that are valid against the XML schema
> po-receipt.xsd, and that must use the approved format for product
> identifiers."
> Item under test: A business endpoint.
> Assertion prose: "Purchase Order Receipt documents must be XML
> documents that are valid against the XML schema po-receipt.xsd, and
> that must use the approved format for product identifiers."
> Comment: Test TST#112 is only required when test TST#111 results in a warning
> Test Assertion Pass Criteria: Test Assertion results in 'pass' if no
> test result is 'fail' and all required tests are run.

Except for the test criteria, a good example.
Pass conditions must be explicit and UUT oriented. This would might be
'Parser must not report any errors when validating the instance.

Other than that this seems to be about the right 'level' of abstraction.
Says 'what' to test. Not how.
Is independent of other tests.
(Might add a precondition: An xml instance - PO receipt, has been received
by the end point).
Post condition might be, PO receipt on disk as file identified by
...PO ident number
with XML extension.

I'd generalise that the 'right' level of abstraction is at, or
slightly lower than,
the sentence level in the specification. The usual caveats about no conjunctions
etc. Unsure if its reasonable to go much beyond such a generality.



regards


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