Data-driven testing
Data-driven testing is a software test automation technique in which a single test script runs repeatedly over a table of inputs and expected outputs, each row being one test case. The test steps are written once and the data lives outside the script, in a spreadsheet, CSV file or database, so new cases are added by adding rows.
The longer version
The script reads a row, feeds the values into the application, compares the result with the expected value in the same row and moves to the next. A login test, for example, can be one script with a table of usernames, passwords and the message each should produce. The logic is unchanged when a new case is needed, and a failing row identifies the exact data that failed.
The method pairs naturally with equivalence partitioning and boundary analysis, because those techniques produce exactly the lists of representative values that fill the table. Pairwise generators output rows in the same shape. The table becomes the readable record of what has been covered, and a reviewer can scan it for a class that is missing without reading any code.
Most test runners support the pattern directly, with parameterised tests in unit and end-to-end runners, so adopting it rarely needs a new framework. It is not the same as keyword-driven testing, which abstracts the actions: a data-driven script can still be a single hand-written function.
Everything then rests on the rows. The expected result in each has to be right, and a wrong value passes silently when the test only ever checked that the code ran. Expected values also drift from the product as it changes, and data that depends on the state of a shared environment makes the same row pass on one run and fail on the next, so the fixtures behind the table should be created and reset deliberately.
Common questions
What is data-driven testing in software testing?
A test automation technique that separates test data from test logic. One script performs the same steps for every row of an external table of inputs and expected results, so adding a case means adding a row. It is used to cover many input variations without copying the script.
What is the difference between data-driven and keyword-driven testing?
Data-driven testing varies the inputs while the steps stay fixed in one script. Keyword-driven testing varies the steps, assembling tests from reusable action keywords. The two are independent and are often combined, with keywords describing the actions and a data table supplying the values each run uses.
Where is test data stored in data-driven testing?
In an external source the script reads at run time: a CSV or Excel file, a JSON file, a database table or a generated list. Keeping it outside the script means testers can edit cases without touching code, and the same table can be reviewed, versioned and reused by other tests.
What are the advantages of data-driven testing?
One script covers many inputs, so maintenance is concentrated in a single place and coverage grows by adding rows. In most runners each row reports its own pass or fail, which pinpoints the data behind a failure, and the table gives reviewers a plain view of which cases exist and which are missing.
What are the limitations of data-driven testing?
A row with a wrong expected value gives false confidence, and tables that nobody reviews drift away from the product. Tests that rely on shared environment state can pass and fail on the same data. Good rows still have to come from a design technique, because more rows are not the same as better coverage.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.