Business integration test data does not need to be a copy of production. A reliable test requires representative business scenarios, edge cases, and real relationships between records, while removing unnecessary personal data. The starting point is not how many rows to transfer, but which decisions, flows, and exceptions the integration must handle.
Copying the full production environment can appear to be the fastest route to a realistic test. In practice, it raises several questions: which data is genuinely needed, who approves its transfer, whether relationships between records remain valid, and whether a person can be identified again from the test set.
A better approach is to build a small, purpose-built dataset. It includes transactions that show the expected process behaviour and transactions that test its boundaries. For example, an order integration between an ERP and an external system may require an open, partially processed, and closed order, an item without an optional value, a changed partner code, a cancellation, and repeated processing of the same message.
Record count is not a measure of coverage. The measure is whether a business decision can be tested: what is sent, what is rejected, what is logged as an exception, and who decides how work continues.
Before technical work begins, it is useful to complete Business process screening and record the boundaries of the process. This avoids a common failure: a technically valid message that creates an incorrect business state.
For each integration flow, list the business events first. Then assign the minimum set of records needed to test each event.
A practical initial scenario set can include:
This list is not universal. Manufacturing, accounting, and sales use different statuses, responsibilities, and consequences of error. The process owner needs to confirm the scenarios because the technical team cannot determine an acceptable business exception on its own.
In a hypothetical process, an ERP sends an order to an external system and the external system returns a delivery status. The test set does not need every real customer or the full order history. It needs, for example, one order with one line, one with multiple lines, an order with partial delivery, an order with cancellation, and an order whose return status does not match the expected ERP state.
For each order, retain the relationships the test checks: header and lines, item codes, warehouse, status, external-system reference, and event order. Customer name, contact details, address, personal identifiers, and other data with no testing purpose do not belong in the set. Where a field is required by the message format, use a synthetic value under an agreed rule rather than a real personal value.
Integrations often depend on relationships: a document belongs to a partner, a line belongs to a document, a posting belongs to an account, and a status returns to an earlier event. This is why selecting connected chains of records is more useful than sampling rows at random from several tables.
Data constraints can support the technical validation of the set. Uniqueness, mandatory fields, and foreign keys are typical mechanisms for checking record identity and relationships. PostgreSQL documentation describes constraints such as UNIQUE , NOT NULL , and foreign keys and their role in data integrity: PostgreSQL Constraints .
A database constraint is not, however, a business rule. It can prevent a duplicate or a relationship to a non-existent record, but it does not determine whether an order may be sent after a particular status, who approves a correction, or how to respond to a partial delivery. These rules need to be documented separately, assigned an owner, and tested through a scenario.
Masking changes a field value. It can include replacing a name, address, email address, or document number. It is useful, but it does not by itself establish that a person cannot be identified from the combination of remaining fields, relationships, and rare events.
For anonymised business scenarios, ask an additional question: can a person be reconstructed or reasonably singled out from the test set using information available to people who can access the test? The answer depends on the contents of the set, the access context, and the combination of attributes. No universal field replacement resolves that risk by itself.
The process should therefore include a review of:
Where the risk cannot be assessed or reduced acceptably, a synthetic scenario is the safer choice. Synthetic data still needs to retain the formats, cardinality, code lists, and relationships required for the integration test.
For every field and relationship, make one of four decisions:
Link each decision to an owner. The business owner confirms the scenario and the consequence of an exception. The source-data owner confirms the meaning, availability, and limitations of the input. The technical owner defines extraction, transformation, loading, and checks. The person responsible for testing confirms execution and records the result. Without this separation of responsibilities, masking often becomes a technical task without business review.
Confirm the following before building the dataset.
Acceptance criteria need to be verifiable without invented baseline or target values. Examples include:
A small dataset will not reveal every problem of scale, processing time, or rare production combination. A full production copy is not evidence of complete coverage either: it can miss explicit exception testing and bring unnecessary data into the test environment.
Separate two questions. The first is functional and business coverage of scenarios. The second is load, volume, and behaviour under a larger number of messages. Prepare a separate plan and suitable data for the second question.
The next step is a short workshop with the process owner, the source-data owner, and the technical owner. Its output should be a scenario list, decisions for fields and relationships, exceptions, and acceptance criteria. Where process boundaries are unclear, Talk to the ORKA team about structuring that review.