A data-driven framework separates test LOGIC from test DATA, feeding inputs and expected results from external sources (Excel, CSV, JSON, databases, or DataProviders) so one test method covers many cases.
The test method is written once and parameterized; a data source supplies rows of (inputs, expected). Sources include TestNG @DataProvider, JUnit @ParameterizedTest, Apache POI for Excel, CSV/JSON parsers, or a DB. Benefits: broad coverage (valid/invalid/boundary) without duplicating tests, and non-developers can add cases by editing data files. Design considerations: keep data isolated per test (avoid shared mutable data across parallel threads), version data alongside tests, and choose a format that matches the team (JSON for structured, Excel for business users). Data-driven design is central to scalable coverage.
One login test reads 20 credential combinations from users.json via a DataProvider, covering valid, invalid, locked, and boundary cases — adding a 21st case is a one-line data edit, not new code.
How do you design a login test to cover 30 credential scenarios without writing 30 test methods?