Top 6 Test data Interview Questions
Browse 6 real-world technical and behavioral interview questions about Test data. Review scenarios, edge cases, and architectural best practices.
Your API suite runs on every commit against a shared database. How do you keep the tests from corrupting each other's data?
Make every test create its own preconditions under a generated identity, scope each assertion to records that test owns, and treat cleanup as housekeeping rather than as the isolation mechanism, because teardown does not run when a test is killed.
You own the API test suite for a service from scratch. How do you structure it, and what do you mock?
Separate contract tests, which check shape and backwards compatibility cheaply, from integration tests that exercise real behaviour across real dependencies. Make every test create and own its data so the suite is re-runnable, spend most of your negative cases on authorisation and malformed input.
You are shipping an LLM feature and there is no evaluation set. How do you build one?
Harvest cases from real inputs and past incidents rather than inventing them, record for every case why it exists and what failure it guards, separate deterministic assertions from graded quality, and freeze a regression slice you never tune against.
No environment in the estate contains the whole stack, so nobody can test an order end to end before release. How do you get assurance anyway?
Stop trying to build one environment containing eight vendors' products. Pin every boundary with a contract test each side can run alone, simulate the network, keep a small high-fidelity path for whole journeys, and put continuous synthetic orders through production as the real assurance.
How do you plan and run UAT, and what happens if the business signs off something that does not meet the original need?
Plan UAT backwards from the business outcome rather than forwards from the specification, and have real users run real work on realistic data. If sign-off lands on the wrong thing, measure the gap against the original objective and raise it as a change with its own business case.
Which tests should run on every commit and which should run nightly, and how do you decide?
Give the blocking stage a fixed time budget and put only fast, deterministic, developer-diagnosable tests inside it; everything slow, environment-dependent or exploratory moves to a scheduled run with a named owner. Use this ci cd answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects test automation to the point an interviewer is testing.