Test Data Provisioning
Getting each test the data it needs, in a state it can rely on, without copying production personal data into a weaker environment.
Test data is the most common reason a promising test strategy stalls. Copying production is realistic and is a data protection incident waiting to be discovered. Hand-crafted fixtures are safe and diverge from reality until they test a world that no longer exists.
The workable arrangement has three parts. Each test builds the state it needs through the application's own interfaces rather than depending on a pre-seeded database, which makes it independent and lets it run in parallel. A small set of reference data is shared and versioned. And where genuine volume or distribution is required, production data is masked with a documented method that preserves referential integrity and distribution while removing identity.
The failure mode to design against is the shared mutable dataset. Once tests depend on record 4711 existing in a particular state, they cannot run concurrently, they fail in an order-dependent way, and nobody can safely change the data — which usually ends with the suite being run nightly and ignored.