Test Script: Interface and Integration

This is a ready-to-use interface and integration test script. It proves that data sent from one system arrives in the receiving system correctly, completely, and once, that fields map and transform as the interface specification says, and that the link behaves safely when something goes wrong in transit. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and execute it under an approved OQ protocol or validation plan. A worked filled specimen follows the template so you can see how a completed version reads. A test script is contemporaneous GxP evidence: write each actual result as you observe it, in ink or in the validated tool, never reconstructed afterward. Verify each cited regulation against the current source before you rely on it.

What this script is, and where it sits

An interface is the seam where two validated systems hand data to each other. Most data integrity failures that survive individual system testing live exactly here, at the seam, because each system passes on its own and nobody proves the handoff. A laboratory system reports a result that a manufacturing system never receives, a quantity arrives truncated, a number that left as kilograms lands read as grams, a message is delivered twice and creates a duplicate batch record, or a transmission fails silently and no one is told. This script tests the path, not the endpoints: the right data leaves the source, the interface maps and transforms it per its specification, the right data arrives in the target, the totals reconcile, and a failed or retried message does not produce loss or duplication.

It sits below the integration or OQ protocol, which says what interfaces will be tested and why, and feeds the traceability matrix, which links each interface requirement to the evidence that exercised it. It assumes both endpoint systems are already qualified in their own right; what is under test is the connection between them. Under FDA’s Computer Software Assurance approach, the rigor here scales with the risk the interface carries: an interface that moves release-decision data, or that feeds a calculation no human re-checks, earns the full scripted, reconciled, evidence-backed treatment below, while a low-risk display-only feed may justify a lighter record. Decide that risk first, in the risk assessment, then write the script.

Document control header

1. Interface and requirements traced

State the interface this script verifies and the requirements it traces to, so the matrix can link requirement to evidence in both directions. Every requirement listed here must be exercised by at least one numbered step below, and no step should test something no requirement asked for.

2. Objective

In one or two sentences, state what passing this script demonstrates.

Example: this script verifies that approved records sent from the source system arrive in the target system complete, accurately mapped and converted, exactly once, that the populations reconcile, and that a failed transmission is detected, retried, and alerted without losing or duplicating data.

<<FILL: objective>>

3. Prerequisites

List everything that must be true before execution starts. If any prerequisite is not met, do not execute; record the gap as a test deviation and stop.

4. Field mapping and transformation under test

This table is the spine of the script. List every source field that crosses the interface, the target field it lands in, the transformation applied, and the exact expected value for the test data. An inspector reads this to see that the mapping was tested field by field, not assumed. Derive every transformed expected value outside the systems under test, by hand or in a separately verified spreadsheet.

State once and apply everywhere: the rounding or tolerance rule for numeric comparisons, the character encoding expected end to end, and how a null or empty source value must be represented in the target.

<<FILL: rounding / tolerance, encoding, and null-handling convention>>

5. Execution conventions

Read these before executing, then apply them to every step.

• Record each actual result contemporaneously, as you observe it. Do not pre-fill, do not batch at the end.
• “Meets expected result” is not an actual result. Write what you actually saw: the value in the target, the message text, the record count, the timestamp, the alert content.
• Read the target through an independent method (a query, report, or export), not through the interface log alone. A “sent” status in the source is not proof of arrival.
• Use one unambiguous mark for pass or fail. A blank cell is incomplete, not a pass.
• For any single-line correction, strike through once, initial, date, and add a brief reason. Never obliterate the original entry.
• Capture objective evidence (target query output, interface log extract, alert screenshot, message payload) for every step whose pass depends on a system output, with a unique reference recorded in the step.
• A silent failure is the worst outcome an interface can have. If a record fails to arrive and nothing is logged or alerted, that is a Fail of the highest severity, not a tester oversight.
• The expected result must be written before execution, specific enough that two people would agree on whether it was met. Do not amend an expected result after you have seen the actual one.

6. Test steps

The steps below cover the four behaviors an interface must prove: correct and complete transfer, accurate mapping and transformation, no loss or duplication under normal and failure conditions, and safe error and retry handling. Number steps continuously. Add or remove rows so every mapping rule and every requirement in section 1 is exercised.

6.1 Normal-path transfer and mapping

6.2 Completeness and reconciliation (no loss, no duplication)

6.3 Error handling and retry

Walk each mapping rule, each boundary value, and at least one failure mode the interface is specified to handle. Do not reuse a step number after a revision.

7. Acceptance criteria

This script passes only when all of the following are true:

• Every step required to verify the requirements in section 1 is marked Pass, with a recorded actual result and, where applicable, an evidence reference.
• Every field in section 4 maps and transforms to its expected value, with no truncation, rounding error, encoding corruption, or mishandled null.
• Source and target reconcile by count and by control total or checksum, with zero missing and zero duplicate records, including after a replay.
• A failed transmission is detected, held without partial writes, alerted, retried, and lands exactly once, and a malformed record is rejected with a reason rather than silently dropped or coerced.
• Every deviation raised during execution is resolved with a documented disposition, and any retest is recorded under its own step or attachment.
• The completed script is reviewed and approved per section 10, by a reviewer who did not execute it.

A script with one or more open Fail steps, a reconciliation that does not balance, or a silent-failure finding does not pass and cannot support the conclusion in the parent report.

8. Deviations raised during execution

Any step that does not meet its expected result, any departure from the written steps, and any prerequisite not met is recorded here and managed per the parent protocol and <<FILL: deviation / test-incident SOP-ID>>. Cross-reference the deviation number on the failing step.

A failed step is data, not a finding against the tester. What an inspector looks for is that the failure was captured honestly, classified, dispositioned, and that any retest is traceable to the original failure, not quietly overwritten. A reconciliation mismatch or a silent-failure result is almost always critical: it means data could be lost or duplicated in production without anyone knowing, so it must be fixed and re-proven, not justified away.

9. Execution summary

10. Sign-off

The tester executes and signs; an independent reviewer who did not execute the test confirms the record is complete, the evidence supports each pass, the reconciliation balances, and any deviation is resolved. The reviewer should not be the same person who executed the script.

11. References

21 CFR Part 11 (electronic records and electronic signatures), for the accuracy, completeness, and integrity of records moving between systems. 21 CFR 211.68 (automatic, mechanical, and electronic equipment), including input and output accuracy checks. 21 CFR 211.180 and 211.194 (records and laboratory records), where interface data becomes part of the GxP record. EU GMP Annex 11 (Computerised Systems), sections on data transfer, accuracy checks, and interfaces between systems. EU GMP Annex 15 (Qualification and Validation), 2015 revision. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final) (risk-based scaling of test rigor). FDA Guidance, General Principles of Software Validation (2002). GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition). MHRA GxP Data Integrity Guidance and Definitions, and PIC/S PI 041 (data transfer and completeness). ICH Q9, Quality Risk Management (for the risk basis of test depth). For medical device software: 21 CFR Part 820 (QMSR, effective 2 February 2026, incorporating ISO 13485:2016 by reference) and IEC 62304.

Confirm the current version and clause numbers of each reference before issue.

12. Revision history

Filled specimen

The following shows the script executed for an example interface that transfers approved laboratory results from a laboratory information management system (LIMS) to a manufacturing execution system (MES) through a message broker. It covers a normal transfer, the field mapping, a batch reconciliation, a replay, and a forced failure with retry. The company, systems, accounts, and numbers are illustrative; replace them with your own.

Header (extract)

Field mapping under test (extract)

Conventions for this run: numeric exact match after conversion; UTF-8 end to end; a null source note must arrive as an empty target Comment, never the literal text “null”.

Test steps (executed, extract)

Execution summary

Sign-off

In this example the tester read the target through an independent MES query rather than trusting the source “sent” flag, checked every mapped field including the unit conversion against a hand calculation, reconciled the batch by count and by summed quantity, replayed the batch to prove the broker would not duplicate, and forced a real failure to confirm the record was held, alerted, retried, and not duplicated. Had step 6.2.4 shown a target sum of 6300 g against a source of 6299 g, the tester would have marked it Fail and opened a critical test incident, because a one-gram gap across the batch means data was lost or altered in transit, which is exactly what section 8 is built to capture.

Common inspection findings this script prevents

• Each system validated on its own, with no test of the interface between them, so a real-world handoff failure was never exercised.
• Transfer confirmed only by a “sent” or “success” status in the source, with no independent read of what actually arrived in the target.
• Field mapping assumed rather than tested, so a unit conversion, date format, code lookup, or truncation error reaches production unnoticed.
• A numeric value verified by the interface itself, never against an independently calculated expected value, so a wrong transformation could pass.
• No reconciliation by count or control total, so records lost or duplicated in transit go undetected.
• No test of the replay or duplicate case, so a retried or resent message silently creates duplicate records.
• A transmission failure that is neither logged nor alerted, leaving a silent gap nobody is responsible for noticing.
• A malformed record silently dropped or coerced to a default instead of being rejected with a reason and held.
• Encoding or special characters corrupted across the interface, with no field tested for it.
• A failed step quietly retested and overwritten, with no test incident and no link between the failure and the eventual pass.
• The same person executing and reviewing the script, with no independent check that the reconciliation actually balanced.
• Testing run in production, or against a different interface version or unfrozen mapping specification than the one being qualified.

How to adapt this script

1. Set your test script ID, parent protocol, both endpoint versions, the interface version, and the frozen interface specification in the header, and confirm you are testing in a qualified non-production environment with both endpoints qualified.
2. Decide the risk of the interface first, then keep or trim the step depth and evidence to match; reserve the full reconciled, error-path treatment for higher-risk interfaces such as those that move release-decision data.
3. Fill the field mapping table in section 4 with every field that crosses the seam, its real transformation rule, and the expected value for your test data, and state your one rounding, encoding, and null-handling convention.
4. Keep the four behavior groups in section 6 (transfer and mapping, reconciliation, replay, error and retry) and add a row per mapping rule and per specified failure mode, so each is exercised and each requirement in section 1 is traced in both directions.
5. Make sure you can read the target independently of the source for every arrival check, and reconcile by both count and a control total or checksum, not by count alone.
6. Point the cross-references in sections 3, 8, and 10 to your real protocol, deviation or test-incident procedure, and review and approval process.
7. Confirm every regulation in section 11 against the current published version before issue.