Why test data is a QE concern
Many test failures are actually data failures: missing prerequisites, stale records, shared accounts, invalid states, or unsafe production copies.
Reliable automation requires reliable data creation, ownership, reset, and cleanup.
Data lifecycle
Design
↓
Create / Mask / Generate
↓
Provision
↓
Reserve / Use
↓
Reset / Refresh
↓
Archive / Retire
Strategy decisions
- Data ownership
- Creation method
- Refresh cadence
- Masking/privacy
- Self-service setup
- Parallel isolation
- Cleanup
- Production-like distributions
Synthetic vs masked production-like data
| Approach | Strength | Risk |
|---|---|---|
| Synthetic | Privacy-safe, controlled, repeatable | May miss real distributions and relationships |
| Masked production-like | Realistic relationships and volume | Privacy/security complexity and refresh cost |
Design for isolation
Parallel tests should not compete for the same mutable records unless concurrency is the purpose. Use generated IDs, dedicated tenants, fixtures, reservation, or reset mechanisms.
A strong test can state the data condition it needs instead of depending on manual preparation days earlier.