Call today (note new passcode)

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: Call today (note new passcode)

All:

Call today:

Host: Fujitsu
Time: 2pm PT, Monday May 10
Toll only :  1-512-225-3050
Participant code: 716071

Will send minutes of previous meeting soon.

Agenda:

1- secretarial position: only Michael Kass nominated, so we will vote if we have quorum,
else we open a mail vote (1 week).
2- TestFramework 1.1 Follow-up on the simplification of control flow operators for test case scripting.
- go through use cases (see attached) and decide which operators in TFk1.1 are sufficient to best script them.
- recap of BPSS choreography patterns and what operators are most familiar to workflow.
- outline what simplifications can we do to TFk1.1 scripting, while covering BPSS test requirements.

3- TestFramework 1.1 : what Test Service for BSI (BPSS engine)?
- at f-2-f, we have outlined the possibility of using a subset of Test Driver, to simulate the application components
that process and send payloads via the BSI.

Regards,

Jacques
<<UseCases-3-Scripts.txt>>

 Test use cases, representative of test case control patterns.
They should help focus on the minimal set of operators for control flow.

-------------------------------------- 
  Use Case #1: Basic Business Transaction, 
(e.g. PIP 3A4) with TimeToPerform, and TimeToAcknowledge 
  -------------------------------------- 

Test Case: (test driver plays "buyer")
Step 1: Buyer Send a P.O. to Supplier.
Step 2: Receive a signal ack, correlated with the P.O. based on Conversation ID
Step 3: Receive a P.O. Confirmation or Rejection.
Step 4: Send a signal Ack.

Constraints: 
- total time for 1-2-3 is bounded by TimeToPerform.
- total time for 1-2 is bounded by TimeToAcknowledge.

Success:
- within TimeToPerform, receive either a P.O. Confirmation or Rejection, but not both.
- TimeToAcknowledge is satisfied.

Variant:
The correlation is based on a PO reference # that is in the payload.


  -------------------------------------- 
  Use Case #2: Catching unexpected ebXML Error messages (a test case "design pattern") 
  -------------------------------------- 

  Test Case: (test driver plays "buyer")

  Step 1: buyer sends a message M1 
  Step 2: receive and verify message M2 
  

  Correlation M1-M2 based on COnversation ID.
But in case an error is received that correlates with M1 (in addition or instead of M2), 
at any point in time within 300sec after sending M1, before or after receiving M2, 
and regardless of the outcome of verifying M2, we want the test case to fail. 


 
  -------------------------------------- 
  Use Case #3: conditional branching 
  -------------------------------------- 
  Test Case: (test driver plays "buyer")

  - buyer sends M1 
  - received M2 (e.g. an approval, or rejection) 
  ---> if M2 is "approval", we will expect a sequence of: 
- receive M3 (e.g. a quotation)  
- send M4 (e.g. approval of quote and payment info) 
- receive M5 (final delivery details). 
  ---> if M2 is "rejection", we will expect a sequence of: 
- receive M6 (proposed alternative)
  
We need to verify all received messages, as the test case would fail if they do not comply. 
Any error message received, would also fail the test case (see use case #2)