test-data-strategy

Test data strategy

Getting data you're allowed to have that behaves like data you aren't.

Why this exists

In a regulated organization, production data cannot be copied into a test environment. Not "shouldn't" — cannot, without a legal basis, and often not even then. GDPR, PCI-DSS, HIPAA, and internal data policies all land in the same place: the realistic data you need to verify anything is the data you are least allowed to touch.

The result is a specific and very common failure. Tests run against three hand-written rows containing "Test User" and "123 Test Street." They pass. The change ships. It breaks immediately on a customer whose name contains an apostrophe, an address with no postcode, an order placed before the 2019 migration, or an account with forty thousand transactions.

The data wasn't wrong. It was unrepresentative, which is harder to notice.

This is frequently the real bottleneck to shipping in an enterprise — not the code, and not the tests, but having anything sensible to run them against.

When this applies

• Tests need data you don't have
• Verification blocked by an empty or unrealistic environment
• Someone proposes copying production data
• A bug reproduces in production and not locally
• Performance work needing realistic volume

When it doesn't

• Adequate fixtures already exist — check they're representative, then use them
• Pure unit tests over in-memory logic with no data shape dependency
• The blocker is access to an environment rather than data — that's access-and-onboarding

Prerequisites

• .fde/03-requirements.md — the criteria determine what data must exist
• .fde/02-system-map.md — where data lives and what shape it takes
• Understand the organization's data policy before starting. See ../_shared/enterprise-constraints.md.

Procedure

1. Establish what's actually permitted

Ask before designing anything, because the answer determines the whole approach and people's assumptions about it are usually wrong in both directions.