Orchestration Test Suite

"Orchestration describes how web services interact with each other at the message level, including the business logic and execution order of the interactions" [Chris Peltz 2003]. These interactions may span applications and/or organizations, and result in a longlived, transactional, multi-step process model. For example, in the eLandings /wiki/spaces/et/pages/8454262, the simplest case of reporting a landing requires a minimum of the following web service method invocations:

  1. ProcessorReportManagementService.reserveLandingReportNumbers
  2. ProcessorReportManagementService.reserveFishTicketNumbers
  3. ProcessorReportManagementService.submitInitialLandingReport
  4. ProcessorReportManagementService.submitIfqReports (if IFQ reports are included in this landing)
  5. ProcessorReportManagementService.submitFinalLandingReport

In practice few transactions are this simple, and there is more involved than simply getting the steps in sequence. For example when submitting an update to an existing report it is necessary to distinguish between updates to existing lines versus insertion of new lines, etc.

In order to support integration with third party systems these details of message sequences and conventions must be explicitly documented and there should be test plans specified for a number of common transactional processes, including:

  • Reset of data to a known base state
  • Request for landing report and fish ticket numbers
  • Submission of a specified "test" landing report
  • Update of a previously submitted landing report with specific updates, inserts and deletions
  • additional as-yet-unspecified steps

After execution of any of these specific steps, it must be possible to compare the resulting state to the expected state, to provide feedback and identify any discrepancies.

Resources

Advice on test planning and documentation for manual system testing.
Tigris.org Words of Wisdom re Test Cases
Tigris.org Test Case Format
Tigris.org Test Suite