A single row of a data-driven case fails during a run in a TestRail- or Xray-class repository. What has actually failed, and what should the run's record show?
answer
- a description cannot fail
- row granularity, not case granularity
- values travel with the failure
- retest one row, not the table
- check the row before the product
basics
~10 sOne execution failed, not the case. Each row produces its own execution record, so the failure carries that row's values, its own evidence and its own defect link, and only that row is retested.
solid answer
~40 sA stored case is a description; it cannot fail. What failed is one execution - the attempt generated for that one row - and the record should show it that way, with the bound values, its own evidence, its own defect link and its own retest. Two mistakes follow from losing that granularity. Collapsing the rows into a single case-level outcome hides which values reproduce the failure, forces a retest of the whole table, and points the defect at a description rather than an attempt. Over-correcting by promoting each failing row into a new stored case destroys the one-set-of-steps economy and starts the copies drifting. Before raising anything, check whether the row itself is stale: a retired code or a deleted identity fails honestly while the product is fine.
go deeper
Be able to say that a failing row means one failed execution and that the rows which passed still passed; the stored case itself is not marked failed.
Explain what a per-row execution record must hold - the bound values, its own evidence and its own defect link - and why a single case-level outcome makes the failure unreproducible.
Walk the triage: did the row bind, is the value still valid, do the other rows fail too, and only then raise a defect against the execution so the values travel with it.
Own the reporting convention. Teams collapse rows because a summary asked for one line per case; decide what the record must preserve and make the honest shape the default.
## The case is not the thing that ran A stored case is an **authored artefact**: steps, expected results, and — for a data-driven case — a table of variant rows. An **execution** is one recorded attempt at that case, and for a data-driven case the repository generates one execution per row. So when a tester works through the case and row seven does not behave, the honest sentence is *one execution of this case failed*. The case did not fail; a case cannot fail, because a case is a description. The other rows produced their own executions and their own outcomes, and those stand on their own. This is not pedantry. Almost everything you want to do next depends on the failure having been recorded at row granularity. ## What the per-row execution record has to carry - **The bound values.** The row is what makes the failure reproducible. Without it, the next person knows the case failed but not with what. - **Its own outcome.** Recorded against that execution, not merged with its siblings. - **Its own evidence.** Screens, logs and notes attached to the failing row, not to a case-level bucket where they cannot be told apart. - **Its own defect link.** A ticket raised from the failure should point at the execution that produced it, so the ticket carries the values in its trail. - **Its own retest.** Re-checking a fix means re-running one row, not fourteen. ## The two ways teams get this wrong | Mistake | What it looks like | What it costs | |---|---|---| | Collapsing rows into one case outcome | the case shows a single result for all rows | the failing values are unidentifiable, retest means the whole table, and a defect link points at the case rather than the attempt | | Promoting every failing row to a new stored case | the inventory grows a case per bad row | the one-set-of-steps economy is gone, the same steps now live in several places, and the copies drift | The first is the common one, and it usually arrives as a convention rather than a product limit: somebody decides the team reports one line per case because that is what the summary wants. The second is the over-correction, made in good faith by people who noticed the first problem and reached for the only tracking unit they trusted. Neither is necessary — the per-row execution already is the tracking unit. ## Before blaming the product: is the row wrong? A data-driven case has an extra failure mode a plain case does not have, and it is worth working through before a ticket is raised: 1. **Did the row bind at all?** A placeholder naming a column that was renamed or removed produces a step nobody can perform. That is an authoring defect against the case. 2. **Is the value still valid?** A row can hold an identity that was deleted, a code that was retired, or a date that has drifted into the past. The execution fails truthfully and the product is fine. The fix is the row. 3. **Do the other rows fail too?** One row failing while eleven pass points at something specific to that value class. All twelve failing usually points at the steps, the environment, or a genuine product break that has nothing to do with the data at all. 4. **Only then**, raise the defect against the failing execution so the values travel with it. Step 3 is the diagnostic the shape gives you for free: because the same steps ran against every row, the pattern across rows separates a data problem from a product problem far faster than a set of cloned cases would. ## Why the granularity keeps paying afterwards Once a defect is fixed, the retest is one execution, and the record shows a row that failed and then passed rather than a case that flip-flopped. When the same case runs next cycle, the row that failed last time is identifiable, so anybody scanning results can see whether that particular variation is a repeat offender. And when someone asks how much was actually tested, the executions answer honestly: the table multiplied the volume of what ran, and the record kept every one of those attempts addressable instead of averaging them into one line that says nothing about which values were exercised.
- Eleven rows pass and one fails. What does that pattern tell you before you look at anything else?That the same steps, the same environment and the same expectation worked eleven times, so the difference is almost certainly the value class in that row - a boundary, a retired code, a deleted identity. If all twelve had failed instead, the data would be the least likely culprit and the steps, environment or product the most likely.
- Why is promoting each failing row into its own stored case the wrong correction?It fixes the symptom with the most expensive tool available. The per-row execution is already individually recorded, addressable and retestable, so nothing is gained; meanwhile the steps now exist in several places, the copies drift apart, and the inventory grows a case for every bad day the data had.
- A defect ticket is raised from a failing row. What must travel with it?The bound values of that row, so the ticket is reproducible without the repository, and a link back to the execution rather than to the stored case. A link to the case says only that something in a twelve-row table misbehaved, which is the same as saying nothing.
saying these in an interview costs you the question
- Marks the whole case failed for one bad row
- Reruns the entire table to recheck a fix
- Links the defect to the case, not the execution
- Creates a new stored case per failing row
- Never questions whether the row itself is stale