How do you manage test data in an automation framework?

Test data problems cause a large share of flaky and order-dependent failures. My default strategy is: every test creates the data it needs, through the fastest reliable channel, with values that cannot collide with any other test.

Principles

• Tests own their data. A test should not depend on a record another test created or on a user someone set up manually last year. That is what lets tests run in parallel, in any order, and be rerun individually.
• Create data below the UI. Use public APIs, internal test endpoints or direct seeding to create users, orders and products. UI tests should only drive the UI for the behaviour being tested.
• Unique by default. Generate identifiers per test (order-${uuid}, emails with a random suffix) so parallel workers never fight over the same row.
• Shared reference data is read-only. Things like country lists or product catalogues can be seeded once per environment, but no test may modify them.
• No real personal data. Production copies bring privacy and compliance risks. Use synthetic data, or properly masked data when realistic volumes or distributions are needed.

Builders with sensible defaults

A builder lets a test state only what matters for that scenario:

public final class CustomerBuilder {
    private String email = "user-" + UUID.randomUUID() + "@test.example";
    private String country = "GB";
    private boolean loyaltyMember = false;

    public CustomerBuilder inCountry(String country) { this.country = country; return this; }
    public CustomerBuilder loyaltyMember() { this.loyaltyMember = true; return this; }

    public Customer create(CustomerApi api) {
        return api.create(new CreateCustomerRequest(email, country, loyaltyMember));
    }
}

// In a test
Customer member = new CustomerBuilder().loyaltyMember().create(customerApi);

Libraries such as Datafaker (Java) or @faker-js/faker (JavaScript) help generate realistic values, but seed them or log generated values so failures are reproducible.

Cleanup options

1. Delete what you created in teardown, tracking created IDs in a per-test registry. Make cleanup tolerant of failures so it does not mask the real error.
2. Transaction rollback works for integration tests that share a database connection with the code under test, but not for end-to-end tests through a deployed service.
3. Disposable environments: spin up databases with Testcontainers or per-PR environments, and throw them away. This removes most cleanup code.
4. Scheduled sweeps of data tagged as test data, as a safety net in long-lived shared environments.

Hard cases

• Data that is expensive to create (a fully onboarded enterprise tenant): create a pool once per run, lease items to tests, and keep tests from mutating shared parts.
• Third-party systems: use sandbox accounts, or stub them with tools like WireMock at the boundary.
• Time-dependent data: control the clock in the system under test if possible, rather than waiting for real time to pass.

What interviewers look for

• Independence and parallel safety as the explicit goal.
• API or seed-based setup instead of UI setup.
• A concrete cleanup strategy, not “we reset the database sometimes”.
• Awareness of privacy rules around production data.

Common mistakes

• Hard-coded shared accounts that every test logs into and modifies.
• Excel sheets as the single source of truth with no versioning.