QA Automation Engineer interview question
How do you automate test data setup?
Create test data through factories or domain APIs with explicit defaults and overrides, generate unique identities, make setup idempotent, isolate per run, mask sensitive samples, and prefer disposable storage over brittle cleanup.
Direct answer
What a strong answer covers
How it works
Automated test data comes from factories or the product’s own APIs, never from hand-maintained SQL dumps. A factory such as createOrder builds a valid object with sensible defaults and accepts overrides for the attributes the test cares about, so tests state only what matters and stay valid as the model evolves. Identities are generated unique per call, setup is idempotent so a rerun does not fail on a duplicate, and each run or worker is isolated by tenant or namespace. Sensitive samples from production are masked before they become fixtures. Cleanup is avoided by using disposable databases or namespaces rather than fragile teardown scripts.
Example
A test needing an overdue invoice calls createInvoice({ dueDate: daysAgo(10), status: 'unpaid' }); the factory creates the customer and account through the public API with a generated email, and everything else takes defaults. Performance tests seed 100,000 orders through the same factories in a disposable schema. When the invoice model gained a required currency field, only the factory changed and 300 tests kept passing.
Common mistakes
- Maintaining a giant seed SQL file that breaks on every schema change.
- Reusing fixed IDs so parallel tests and reruns collide.
- Writing teardown scripts that leave partial data behind when a test fails halfway.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.