Integrations are complex. Data flows from tool A to tool B, may be transformed, may be filtered. Errors are easy: a field maps wrong, a filter is too strict, data types don't match. Bad data breaks downstream decisions. Testing and validation ensure integrations work correctly before they're relied upon. This chapter covers how to test integrations and validate data across connected systems.
Types of Integration Tests
Unit testing
Test individual components. Example: does the conversion event from analytics include all required fields (user_id, conversion_type, timestamp)? Does the CRM field mapper correctly convert "type_purchase" (analytics) to "deal_closed" (CRM)?
Integration testing
Test end-to-end flow. Example: trigger a conversion in analytics, confirm it appears in CRM within expected time with correct data.
Regression testing
Ensure changes don't break existing functionality. Example: you update the field mapper for email addresses. Verify the mapper still works for phone numbers.
Data Validation Checks
Volume checks: daily conversions in analytics should match CRM (within 5%). If they diverge, investigate.
Completeness checks: every event should have required fields. If 10% of events are missing user_id, that's a data quality issue.
Consistency checks: if a conversion has email jane@wemasy.com in analytics and jane.c@wemasy.com in CRM, that's a mismatch. Investigate.
Timeliness checks: conversions should appear in destination system within expected timeframe (real-time or daily). If data appears hours late, integration may be slow.
Accuracy checks: spot-check sample of conversions end-to-end. Did conversion flow correctly from source to destination? Are data values accurate?
Building a Testing and Validation Process
Before going live: run all four test types on sample data. Document results. Sign-off from both teams (analytics and destination tool). Create test cases for future regression testing.
After going live: daily reconciliation: compare volume, completeness, consistency between systems. Weekly deep dive: spot-check 10-20 conversions end-to-end. Monthly review: check for drift, patterns, anomalies.
When issues arise: pause integration if data is clearly wrong (e.g., 10x volume spike). Investigate: what changed? Retest before resuming.
Common Integration Issues and Fixes
Issue: conversions in analytics but not CRM. Cause: API key expired, permissions changed, transformation error. Fix: check logs, verify API key, check field mapping.
Issue: volume mismatch (analytics = 100, CRM = 80). Cause: filtering error, CRM has additional validation that rejects some events. Fix: check CRM filters, verify field types match, adjust validation rules.
Issue: data appears delayed (hours instead of real-time). Cause: integration uses batch processing instead of streaming. Fix: check integration settings, upgrade to streaming if available.
Documentation and Governance
Document each integration: source, destination, data types, transformation rules, expected latency, owner (who fixes if broken). Create runbook: if integration breaks, what's the troubleshooting sequence? Who do you contact?
Assign ownership: one person is responsible for each integration. They monitor, test, and fix issues. This prevents "nobody knows" situations.
How do I test an integration before going live?
Step 1: send test data (test conversion with fake email, test lead with test company). Step 2: confirm test data appears in destination system within expected time. Step 3: verify all fields are correct (user_id, amount, date). Step 4: run for 24-48 hours to check stability. Step 5: cleanup test data. Once passed, integration is ready for production.
What should I include in an integration testing checklist?
- [ ] All required fields present, [ ] Data types correct (email vs. phone), [ ] Values within expected range (price > $0), [ ] Timestamps accurate, [ ] User ID matches between systems, [ ] No duplicates, [ ] Volume matches baseline (±5%), [ ] Latency acceptable (within SLA), [ ] Error handling works (errors logged, not silently dropped), [ ] Deletion requests processed. Customize per integration.
How often should I validate data from integrations?
Daily: reconcile volume, spot-check 10 records. Weekly: deep dive, test edge cases. Monthly: review trends, check for drift. Quarterly: full audit, verify all test cases still pass. This catches issues early. If you wait until monthly, problems compound.
What's an acceptable margin of error for data reconciliation?
Volume: ±5% (small tracking differences are normal). Completeness: 98%+ (a few missing fields is acceptable). Consistency: < 1% mismatches (most data should match). If you exceed these thresholds, investigate. 2-3% errors are acceptable; 10%+ indicates a broken integration.
How do I handle integration failures (integration breaks and stops sending data)?
Immediate: pause integration, notify stakeholders that data is stale. Investigate: check logs, verify API keys, test connectivity. Fix: address root cause (expired key, missing permissions, code error). Resume: test again, monitor closely for 24 hours. Post-mortem: why did it break? How do we prevent this? Add monitoring/alerting.
Can I automate integration testing?
Yes. Use data validation tools (Great Expectations, dbt tests) to run daily checks automatically. Set up alerts: if volume diverges >5%, alert engineer. If completeness < 98%, alert. Automate volume and completeness checks; manually spot-check accuracy (harder to automate). Most companies combine automated checks + manual review.