Added by Kerry Lamb, last edited by Kerry Lamb on Jan 28, 2008  (view change)

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

Definition

External Interface Testing (also referred to as Data Exchange or just plain Interface Testing), is a subset of functional testing. It verifies that:

  1. the function or application that processes outgoing data (sent to another entity) provides that data in the required format and with the required contents, using the required delivery mechanism,
  2. the function or application that processes incoming data (received from another entity) performs according to requirements when that data is in the correct format and has the required contents and was sent using the required delivery mechanism,
  3. the function or application that processes incoming data performs according to requirements when the data is not in the correct format, or does not have the expected contents, or is not sent using the required delivery mechanism.

External Interface testing is employed when verifying the connection between two or more entities. Examples include an extract out of a DMSII database for loading into SQL, data placed in a specified location for pickup by another application (or organization), a 'handshake' from one application to another to indicate the status of an action, or a tape created in one MCP application for loading into another. If the interface is between organizations (e.g., the UW and a Washington State Agency, a vendor and the UW), it's usually explicitly referred to as an External Interface.

This type of testing is most often data related and excludes what is done with the data once it's retrieved and stored. For example, the interface test ends when the new data is correctly deposited in a SQL table. The function or application that then uses/updates/deletes that data would be tested separately.

The specifications used to design the tests are often housed in an Interface Requirements Document (IRD) or an Interface Control Document (ICD). These requirements usually cover:

  • Rejection of duplicate files,
  • Rejection of duplicate records,
  • Detection and correction of transmission error,
  • Rejection of incorrect headers or footers,
  • Rejection of incorrect data types in data records,
  • Etc.

SampleICD.doc is a sample Interface Control Document.

When to Start

As with most testing, external interface test planning can begin as soon as specifications are determined. Both applications do not need to be 'production ready' for one application to have started testing. The developer can create test harnesses and contrive data to conform (and not conform) to the specs to validate the processing of the external data.

Interface testing should be done:

  • When a new interface is created (e.g., an existing application creates a new file to send to another existing application),
  • When a new function or application is created that sends data to another function or application,
  • When (for whatever reason) the interface specifications change (e.g., zip code changed from 5 digits to 5 plus 4),
  • When either application changes, whether or not the interface is affected (regression testing).

Interface testing requires coordination with the interfacing organization. The developer can test as much as possible during unit testing, but it is unwise to have the first data exchange occur in production. The interface test can be performed in stages (for example, the sending application can provide the data using a method that won't be used in production, such as via email), but eventually there should be a complete 'end-to-end' test where the sending application creates and delivers the data the same way it would in production, and the receiving application receives and processes the data as it would in production. When both applications are ready for end-to-end testing, the two entities can set up a test in an integration test environment accessible by both entities that will determine if both sides are conforming to the interface requirements, including requirements regarding the delivery. Final testing cannot be completed until the receiving entity has received and verified that the data was sent in the required format and with the required contents.

Examples and Ideas

For incoming data, the tester can create test data to exercise the receiving application. The test data would be created in 4 categories:

  1. good data in a good format,
  2. good data in a bad format,
  3. bad data in a good format,
  4. bad data in a bad format.

Running this test data through the receiving application would highlight problems such as not catching bad data or bad formats, or rejecting good data unnecessarily.
For outgoing data, test methods may depend on how much data must be examined. If a small amount, manual checking may be enough. For large quantities of data, however, creating a test tool which would run the edits as they would exist in the receiving system would provide a reusable and somewhat automated test.

In addition to data testing; verifying the delivery procedures is also important. If the sending entity is not ready to test, the developer could set up an internal delivery process to mimic the processes to be used in production (e.g., sending an email from a personal email account, setting up an ftp from the mainframe).
If passwords or other security measures are used to protect the data, those measures should also be tested prior to deployment.
Before the interface is run in production, however, a test of the 'real' processes should be executed.

The test environment should be set up so that test data cannot be confused with live production data. For example, if the delivery mechanism in production is via email, a test email account should replace the production email account in test.

A couple of sample Interface Test documents:

Here's an interesting link to the California Office of Systems Integration (OSI) Best Practices web site for Systems Acquisition, which has a description of interface testing.

Tools and Reviews

No specific tools are currently available for External Interface testing. Links will be included here as they are created. In the meantime, however, both Excel and Access can be used to verify data and files by highlighting data type errors and comparing expected and actual results.

Local Resources

A host of external and internal interfaces are maintained by UW Technology staff, including data exchanges between systems (e.g., HEPPS and Budget) and between the UW and other entities (Olympia, vendors). Links to publishable test plans and test cases will be provided as they are made available.

Expected Costs

External Interface testing requires an integration test environment to which all interfacing entities have access. Accounts may need to be set up in this environment for non-UW entities, and security concerns addressed. Consideration needs to be given to the costs and complications of coordination (meeting times, phone calls, time zone lags etc.). New email or other accounts may be required to separate test data from production data.

Expected Benefits

External Interface Testing reduces the risk of invalid data entering the receiving system. If one of the entities is external to UW, finding errors in the interface process before deployment can prevent delays and bad impressions, and could prevent unnecessary processing charges if data has to be resent.