3.3 Data-Driven Testing (DDT) with CSV/Excel Matrices

How to parameterize test cases with CSV spreadsheets to run hundreds of data combinations with row-level diagnostics.

From One Case to Hundreds of Rows

Cloning a test case by hand for every currency, locale, or plan tier you need to cover doesn’t scale, and it rots the moment the underlying steps change – update the real flow and now forty near-identical clones are each subtly out of date. Data-Driven Testing (DDT) decouples the two concerns: author the request-and-assertion logic once, upload a dataset of the values that should vary, and let CertiQA multiply the two together at generation time instead of you doing it by hand, row by row.

Upload a CSV or Excel file at the project level under Datasets – CertiQA previews the parsed rows before anything is generated, so a malformed header or an unexpected extra column is caught before it becomes forty broken test cases. Generation itself is a column mapping step: each spreadsheet header is mapped to a target variable name (they don’t have to match literally, so a column titled “Customer Email” can map cleanly to {{ email }}), and an optional row limit lets you generate against just the first handful of rows for a quick smoke pass before committing to the full matrix.

Two Ways to Turn Rows Into Test Cases

Generation can target two different shapes, depending on how you want the results to show up in Run Reports. Generating into a single case adds one set of case lines per row inside that one case – reasonable for a handful of rows you want to see as one pass/fail unit. Generating into a suite instead creates one full test case per row, each linked into that suite – the right choice once a matrix grows past a dozen or so rows, because each row’s failure then shows up as its own named case in the report, not buried inside one aggregate case you have to scroll through to find the failing row.

A dataset row can also instantiate a CertiBlock instead of raw case lines, one instance per row – useful when every row in the matrix is really exercising the same reusable flow (say, a “create user” CertiBlock) with different input data, rather than a one-off sequence of steps that only makes sense for this dataset.

Generation Target	Result	Best For
Single case	One case, one set of case lines repeated per row.	A small matrix (roughly under a dozen rows) you want to treat as one unit.
Suite	One full test case per row, linked into the suite.	A large matrix where each row deserves its own pass/fail visibility.

Row-Level Diagnostics, Not One Big Red X

• When rows generate into a suite, a failure in row 214 of a 300-row matrix shows up as case 214 failing in Run Reports – with its own captured request/response evidence – rather than a single “DDT case failed” result that gives no indication which data combination actually broke.