Philippines staffing research ·

Synthetic test data for outsourced QA: evidence, limits, and ownership

Synthetic test data for outsourced QA: evidence, limits, and ownership

Research on test fixtures that reduce exposure to customer data while preserving important edge cases.

Synthetic data is created for testing instead of copied from a customer record. It reduces direct exposure, but it is useful only when the fixture represents the states and relationships the test needs.

NIST SSDF calls for protected development environments. OWASP ASVS supplies testable application security requirements. Neither source says synthetic data automatically proves privacy, security, or production behavior.

Start with a data dictionary for the selected flow. Include valid values, boundaries, missing fields, conflicting relationships, and denied identities. Give every fixture an owner and expected result.

Do not make a supposedly synthetic set by lightly editing production exports. Logs, screenshots, recordings, and failed-test artifacts can leak the same values the fixture was meant to avoid.

Rare production combinations, volume behavior, provider responses, and migration history may not exist in the test set. Record those gaps. The company retains data classification, access, and retention decisions.

Sources

  1. NIST SSDF
  2. OWASP ASVS

Related Research

FAQ

What should happen first?

Begin with a bounded ticket, approved access, and a named reviewer.

Who approves production changes?

The company’s technical owner keeps final merge and release authority.