Re: [tag] TA Model

[stephen.green@systml.co.uk]

So how about

1. introducing steps called 'Test' into the flow with IDs,
2. making such 'Test' steps multiple occurrence
3. adding a unique ID to each part of the step
4. allowing preconditions and postconditions to reference parts of another
    step
5. adding 'Previous Test' and 'Following Test' pointers to each step
6. adding 'Comment' outside the flow
7. adding something to state what constitutes overall pass or fail of TA
8. adding specification quote
9. being explicit in the name of the part about it being an ID or reference

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.
Test: TST#111
Previous Test: None
Pre-condition ID: 111PRE001
Pre-condition: The po-receipt.xsd schema is available. The rules  
defining product identifiers - ProductNorm1234 specification, version  
2005 - are available. The business endpoint produces a document in  
response to a Purchase Order message.
Pre-condition Cross Reference: None
Test Trigger ID: 111TR001
Test Trigger: The document is validated against the po-receipt.xsd  
schema, and then the format of the element <productRef> is verified  
against the rules in ProductNorm1234.
Test Trigger Cross Reference: None
Test Effect ID: 111TE001
Test Effect: Successful schema validation – possibly with warnings -  
together with conforming product reference format, result in a “pass”  
outcome to this test, otherwise in “fail”.
Test Effect Cross Reference: None
Post-condition ID: None.
Post-condition: None.
Post-condition Cross Reference: None.
Following Test: TST#112
Test: TST#112
Previous Test: TST#112
Pre-condition ID: 112PRE001
Pre-condition: Successful schema validation – possibly with warnings -  
together with conforming product reference format, result in a “pass”  
outcome, otherwise in “fail”.
Pre-condition Cross Reference: 111TE0045
Pre-condition ID: 112PRE002
Pre-condition: Successful schema validation – with warning.
Pre-condition Cross Reference: None
Test Trigger ID: 112TR001
Test Trigger: Successful schema validation warning. result in a “true”  
outcome, otherwise in “false”.
Test Trigger Cross Reference: None
Test Effect ID: 112TE001
Test Effect: Warning is passed to human interface. result in a “pass”  
outcome to the TA as a whole, otherwise in “fail”.
Test Effect Cross Reference: None
Post-condition ID: 112PST001
Post-condition: A human interface capable of outputing a warning  
exists at the end of this test.
Post-condition Cross Reference: None.
Following Test: None


It only shows an example of multiple cardinality for precondition.
It includes empty items (as None) but I suggest these MAY be left out.
It shows redundancy but that is just to show the whole extended model.
I suggest cardinalities be defined for each part of the model.

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