The Test Plan, when completed, should identify all test cases to be run by the implementation and the partner associated with each test case. The content of each test is specified in the Interlibrary Loan (ILL) Interoperability Test Suite.

Each table in the test plan contains the following information:

Common Services:

SERVICES SUPPORTED

IUT CASE:

PARTNER CASE:

PARTNER SYMBOL:

DATE COMPLETED:

See the sample ILL INTEROPERABILITY TEST PLAN TABLE 4. This table lists the requester test cases which test the ILL services required in transactions of returnable items.

In this scenario, the annotation "NOT RUN" is entered in "DATE COMPLETED" column for CASE153 and CASE154, since the implementation does not support the RENEW service and its partner does not support the OVERDUE service. The institution-symbol SYMB2 found in the PARTNER SYMBOL column identifies the partner that plays the responder role and corresponds to the partner identified in the Test Party.

Before testing begins, participants must contact their partners. The contact person, telephone number, library symbol, etc. can be found in the test plan.

During the test campaign, an IUT operator will initiate the transactions for the cases where it plays the role of the requester. The cases to be executed are identified in the test plan and specified in the ILL Interoperability Test Suite. A case specification identifies all events which occur in a test case (see the example below). Consult the document "ILL Interoperability Test Suite" for a description of the notation used in specifying test cases.

<IUT!ILLreq>
 L!ILL
  L?SHI
   <IUT?SHIind>
    <IUT!RCVreq>
     L!RCV
      <IUT!RENreq>
        L!REN
         L?REA
          <IUT?REAind>
           <IUT!RETreq>
            L!RET
             L?CHK
              <IUT?CHKind>

BSILLreq001


BSSHIind001
BSRCVreq001
BSRENreq000



BSREAind000(?)
BSRETreq000


BSCHKind000

Thirty-four test cases have been defined for each role. Thus and implementation will run a maximum of 68 test cases during a test campaign. Before executing a test case, the operator should consult the Purpose section of the Dynamic Behaviour Table. It provides specific instructions for executing the case.

In the example of Test Case Dynamic Behaviour, CASE154, the requester is encouraged to provide data for all parameters in the RENreq service and the responder, data for all parameters in the REAreq service.

For example, the responder invokes the SHIreq (no SHI APDU is sent) followed by the STRreq. The requester would only receive the STR APDU and get an STRind.

Testing partners should discuss how test cases are to be executed.

For better efficiency, concurrently execute the test cases belonging to the same test group. If using store and forward communications, the length of time it takes to execute the cases one at a time is not practical. The groups should be processed in the following order:

• BASIC
• NONRET
• OPTAPDU
• RETURN
• FORWARD

This order reflects the increasing complexity of the ILL transactions defined in the test cases. It is also possible to execute all cases at once.

As well, concatenate a group of APDUs into one ILL message. For example, when executing the BASIC group, the requester initiates three transaction, one for each of the cases CASE100, CASE101, and CASE102 and combines them into one message.

Each testing partner should start initiating the transactions for the requester group as indicated above. This means that implementations will be processing transactions as a responder and a requester simultaneously, reflecting the normal operations of a library.

Use the Interoperability Test Results form to report test results. Compete a form for each transaction of the test campaign.

Attach system logs to the test result form. The logs can consist of printouts of received and transmitted APDUs, screen dumps illustrating the data from a request or indication service, and/or communication logs listing the events and actions occurring within the system during transaction processing.