Our integration tests use unrealistic data. What should we improve?
Unrepresentative integration evidenceUse authorized representative data patterns, including relevant exceptions and volumes, while protecting sensitive information. Synthetic or masked data can be useful when it reflects real constraints.
What to do now
- Identify important production data characteristics
- Prepare safe representative datasets
- Test boundary and exception behavior
- Record coverage limitations and remaining checks
When to escalate
Escalate when
Critical behavior remains untested or sensitive data is used improperly.
Who decides
The accountable integration or dependency owner
Example
A migration test includes duplicates, missing values, and valid edge cases using approved safe data.
Mistake to avoid
Copying production data into an uncontrolled test environment.
Prevent a repeat
Verify dependency completion with the consuming team and test the integrated outcome early enough to act.
Suggested ApprovedFlow setup
- Tasks
- Documents
- Projects
Keep dependency owners, required evidence and dates with linked work records, confirming supported link behavior in the current build. See the platform
Related cases
- Can we use a mock to unblock a dependency?Controlled provisional interface
- The same data means different things in connected systems. How do we resolve it?Semantic data mismatch
- The test environment differs from production. How much does that matter?Unrepresentative verification
- We discover integration problems only before release. How can we improve?Late integration feedback