Test data
Test data is the set of inputs a test feeds to the software and the records that have to exist for those inputs to be processed: the account being signed into, the product being added to a basket, the file being uploaded, the card being charged. It is chosen deliberately to exercise a specific behaviour, and a test is only as strong as the data it was run with.
The longer version
Every test case has a data column, whether or not it is written down. A sign-in test needs an account with a known password, a checkout test needs a product with a price and a basket that is not empty. The data is picked to match what the case is checking: a valid card for the happy path, an expired one for the decline, a name with an apostrophe for the field that once broke on it. Choosing it well is what test design techniques such as boundary value analysis teach.
Test data is narrower than a test fixture, which is the whole known state a test runs inside; the data is what gets fed in, the fixture is the environment it is fed into. It is also distinct from production data, which most teams cannot use for testing without inheriting its privacy obligations. That leaves the three sources test data management chooses among, and the choice is made there rather than case by case.
A tester who uses the same account, the same product and the same address on every run proves the software against one shape of record and no other. The bugs that reach users are the ones a different shape triggers: a customer with two addresses, an order with a refunded line, a name in a script the font does not carry. Data that nobody refreshes fails the run on its own: a seeded account whose password expired, a product that was deleted, a date that was next week when the test was written and is now last year.
In a team's process the data is named in the test case, provided by whoever owns the environment, and refreshed on a schedule rather than when a test breaks. A test that fails because its data is gone is a data failure, and it is logged as one rather than as a defect in the software.
Common questions
What is the difference between test data and production data?
Production data is the real records real users created, and it carries their privacy obligations wherever it is copied. Test data is chosen or generated for a test and is safe to load anywhere. A masked copy of production is test data once the masking is verified; an unmasked copy on a test server is a breach waiting to be noticed.
Where does test data come from?
From one of three sources: values written by hand for a specific case, a copy of production with the personal fields masked, or synthetic records generated to the schema. Most teams use more than one, hand-written values for unit tests and a masked or synthetic set for the shared environments, and test data management is the practice of keeping those sources current.
Who is responsible for test data?
The test case names the data it needs; whoever owns the environment provides it and keeps it refreshed. On small teams that is the same tester. On larger ones a test data owner or the environment team loads the set and resets it after runs, and a test blocked on missing data is raised with them rather than filed as a bug.
How is test data chosen for a test case?
From what the case is checking. The happy path gets a valid record, the decline path gets an expired card, and the field that once broke on an apostrophe gets a name with one. Test design techniques such as boundary value analysis and equivalence partitioning turn that choice into a method, so the values at the edges of each rule are picked deliberately rather than whichever account the tester used last time.
What happens when test data goes stale?
Tests fail for reasons that have nothing to do with the software: the seeded password expired, the product was deleted, the date that was next week when the case was written is now last year. Those failures are logged as data failures rather than defects, and the fix is a refresh on a schedule, so the data is renewed before it breaks a run instead of after.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.