Test data management is how a framework provides, isolates, and cleans up the data tests need — via external files, factories/builders, API/DB setup, and per-test isolation — so tests are deterministic and independent.
Approaches: static data in JSON/CSV/Excel for data-driven inputs; data BUILDERS/factories to generate objects (a UserBuilder) with sensible defaults; API/DB SEEDING (create the needed state via REST Assured/SQL before a UI test) for speed and reliability; and dynamic/randomized data (faker) with unique values to avoid collisions in parallel runs. Crucially, tests should CLEAN UP what they create (teardown) and not depend on shared mutable data, especially under parallelism. Poor data management — shared records, no cleanup, hard-coded data — is a leading cause of flaky, order-dependent suites.
Before a UI 'edit profile' test, the framework seeds a fresh user via the REST API (fast) with a unique email, runs the UI test, then deletes the user in teardown — deterministic and parallel-safe.
Parallel tests intermittently fail because they all use the same test user. How do you redesign the data strategy?