In a TestRail- or Xray-class case repository, how do you decide whether a variation belongs as another row in a case's variant table or as a stored case of its own?

principalnice to knowfreq 40%

answer

only the values may differ
conditional step wording is the tell
rows are not individually addressable
authoring cheap, execution linear
leverage traded against addressability

basics

~20 s

Keep it as a row when only the values differ and the steps and expected result are identical. Split it into its own case when it needs different steps, a different expected result, or its own attributes.

solid answer

~40 s

The criterion is what a placeholder can actually do: substitute a value. It cannot add a step, skip one, or change what a step asserts. So a variation stays a row while the steps and the expected result are identical, and becomes a case the moment either differs - conditional wording creeping into step text is the reliable early signal. The second axis is addressability. Priority, owner, labels and independent selection attach to the case, not to a row, so a variation that genuinely needs its own is asking to be a case even when its steps match. Weigh that against execution cost: rows are almost free to author and linear to perform, so a wide table on a manual case is an execution-budget commitment, not just an authoring choice.

go deeper

for a junior

Know the simple rule: if only the values change, it is another row; if the steps or the expected result change, it needs a case of its own.

for a middle

Explain why the rule holds mechanically - a placeholder substitutes a value and cannot add, skip or re-assert a step - and name conditional step wording as the early warning sign.

for a senior

Bring in the running cost. A wide table on a manual case commits real tester hours per cycle, so decide which rows earn a place in every run rather than treating rows as free.

for a principal

Own the tradeoff explicitly: rows buy maintenance leverage and give up addressability, cases do the reverse. Be able to say which of the two your repository is currently short of.

The row test

The decision has one clean criterion, and most cases answer it immediately:

Keep it as a row when the steps and the expected result are identical and only the values differ. Make it a case when anything other than the values differs.

That is the test because of how binding works. A placeholder substitutes a value into step text; it cannot add a step, remove one, change what a step asserts, or make an expectation conditional. If the variation needs any of that, the variant table is the wrong container and forcing it in there produces steps that argue with themselves.

Signals a row is really a case in disguise

Conditional wording in the steps. If this row is an expired card, expect the retry prompt instead means two expected results are wearing one coat.
A step that some rows skip. Any instruction only some rows perform is a second procedure.
A different precondition. If one row needs the account in a state the others do not, the setup is no longer shared.
A row that needs its own attributes. Priority, component, owner and labels attach to the case, not to a row. If one variation genuinely needs to be higher priority or owned by someone else, the table cannot express it.
A row somebody wants to run on its own. Rows are chosen as a set when the case goes into a cycle. A variation that must be picked independently is asking to be a case.

The costs sit on opposite sides

	More rows, fewer cases	More cases, smaller tables
Steps to maintain	one set	one set per case
Cost of adding a variation	append a row	clone and diverge
Risk of stale duplicated steps	low	high
Individually addressable	no	yes
Own priority, owner, labels	no	yes
Visible in an inventory count	no	yes
Execution time	grows with rows	grows with cases

Read that table as the actual tradeoff: rows buy maintenance leverage and give up addressability; cases buy addressability and give up leverage. Neither column is the safe default, and a repository that has gone all the way to either end is usually in trouble — a thousand near-identical cases nobody dares edit, or a handful of cases carrying tables so wide that no one knows what is in them.

Authoring is cheap; running is not

The seductive property of a variant table is that a row costs almost nothing to add. That is true at authoring time and false at execution time. On a case a person performs by hand, every row is another pass through the same procedure, so a case that takes twenty minutes and grows to forty rows has quietly bought a multi-day commitment for whoever runs that cycle. On an automated case the marginal cost is small but not zero, and it lands on wall-clock feedback time.

So the honest form of the question is not does this variation deserve a row but does this variation deserve to be executed every time the case is. Rows that only matter for a deep regression pass and rows that matter on every build are not the same thing, and packing both into one table forces them to share a fate.

A rule that survives contact with a real repository

Same steps, same expectation, different values → row. No discussion needed.
Different expectation → case, even if the steps look similar. The expected result is what the case is for.
Same steps, same expectation, but this variation needs its own priority, owner, or independent selection → case, and accept the duplicated steps as the price of addressability.
When the table gets wide enough that nobody can say what is in it, that is a signal about execution budget, not about correctness. Split the table into the rows that run always and the rows that run occasionally rather than splitting the case.
Never split a case because a row failed. A failing row is one failing execution, and it is already individually recorded.

The judgment worth demonstrating here is that this is a representation decision with an operating cost attached, not a matter of taste: you are choosing between one artefact everybody edits safely and many artefacts everybody can point at, and you should be able to say out loud which of those two the team is currently short of.

## The row test The decision has one clean criterion, and most cases answer it immediately: > Keep it as a **row** when the steps and the expected result are identical and only the **values** > differ. Make it a **case** when anything other than the values differs. That is the test because of how binding works. A placeholder substitutes a value into step text; it cannot add a step, remove one, change what a step asserts, or make an expectation conditional. If the variation needs any of that, the variant table is the wrong container and forcing it in there produces steps that argue with themselves. ## Signals a row is really a case in disguise - **Conditional wording in the steps.** *If this row is an expired card, expect the retry prompt instead* means two expected results are wearing one coat. - **A step that some rows skip.** Any instruction only some rows perform is a second procedure. - **A different precondition.** If one row needs the account in a state the others do not, the setup is no longer shared. - **A row that needs its own attributes.** Priority, component, owner and labels attach to the case, not to a row. If one variation genuinely needs to be higher priority or owned by someone else, the table cannot express it. - **A row somebody wants to run on its own.** Rows are chosen as a set when the case goes into a cycle. A variation that must be picked independently is asking to be a case. ## The costs sit on opposite sides | | More rows, fewer cases | More cases, smaller tables | |---|---|---| | Steps to maintain | one set | one set per case | | Cost of adding a variation | append a row | clone and diverge | | Risk of stale duplicated steps | low | high | | Individually addressable | no | yes | | Own priority, owner, labels | no | yes | | Visible in an inventory count | no | yes | | Execution time | grows with rows | grows with cases | Read that table as the actual tradeoff: rows buy **maintenance leverage** and give up **addressability**; cases buy addressability and give up leverage. Neither column is the safe default, and a repository that has gone all the way to either end is usually in trouble — a thousand near-identical cases nobody dares edit, or a handful of cases carrying tables so wide that no one knows what is in them. ## Authoring is cheap; running is not The seductive property of a variant table is that a row costs almost nothing to add. That is true at authoring time and false at execution time. On a case a person performs by hand, every row is another pass through the same procedure, so a case that takes twenty minutes and grows to forty rows has quietly bought a multi-day commitment for whoever runs that cycle. On an automated case the marginal cost is small but not zero, and it lands on wall-clock feedback time. So the honest form of the question is not *does this variation deserve a row* but *does this variation deserve to be executed every time the case is*. Rows that only matter for a deep regression pass and rows that matter on every build are not the same thing, and packing both into one table forces them to share a fate. ## A rule that survives contact with a real repository 1. **Same steps, same expectation, different values → row.** No discussion needed. 2. **Different expectation → case**, even if the steps look similar. The expected result is what the case is for. 3. **Same steps, same expectation, but this variation needs its own priority, owner, or independent selection → case**, and accept the duplicated steps as the price of addressability. 4. **When the table gets wide enough that nobody can say what is in it**, that is a signal about execution budget, not about correctness. Split the table into the rows that run always and the rows that run occasionally rather than splitting the case. 5. **Never split a case because a row failed.** A failing row is one failing execution, and it is already individually recorded. The judgment worth demonstrating here is that this is a **representation** decision with an operating cost attached, not a matter of taste: you are choosing between one artefact everybody edits safely and many artefacts everybody can point at, and you should be able to say out loud which of those two the team is currently short of.

A table has grown so wide that nobody can say what is in it. Is that an argument for splitting the case?
Usually not. Width is a signal about execution budget rather than correctness, so the useful split is between the rows that must run every time and the rows that belong in an occasional deeper pass. Splitting the case instead duplicates the steps and buys nothing, because the maintenance leverage was the only thing keeping a wide table affordable.
How do you argue against a team that clones a case for every variation because cloning feels safer?
Show the cost where it lands: a corrected expected result now has to be applied in every clone, and it will be applied in some. Cloning trades a hard problem you can see - a wide table - for an easy-looking one that fails silently, namely near-identical cases that quietly stopped agreeing.

saying these in an interview costs you the question

Puts conditional logic into shared step text
Adds rows freely without counting execution time
Clones cases whenever any detail differs
Expects a row to carry its own priority or owner
Splits a case because one row failed

The row test

The decision has one clean criterion, and most cases answer it immediately:

Keep it as a row when the steps and the expected result are identical and only the values differ. Make it a case when anything other than the values differs.

Signals a row is really a case in disguise

Conditional wording in the steps. If this row is an expired card, expect the retry prompt instead means two expected results are wearing one coat.

A step that some rows skip. Any instruction only some rows perform is a second procedure.

A different precondition. If one row needs the account in a state the others do not, the setup is no longer shared.

A row that needs its own attributes. Priority, component, owner and labels attach to the case, not to a row. If one variation genuinely needs to be higher priority or owned by someone else, the table cannot express it.

A row somebody wants to run on its own. Rows are chosen as a set when the case goes into a cycle. A variation that must be picked independently is asking to be a case.

The costs sit on opposite sides

	More rows, fewer cases	More cases, smaller tables
Steps to maintain	one set	one set per case
Cost of adding a variation	append a row	clone and diverge
Risk of stale duplicated steps	low	high
Individually addressable	no	yes
Own priority, owner, labels	no	yes
Visible in an inventory count	no	yes
Execution time	grows with rows	grows with cases

Authoring is cheap; running is not

A rule that survives contact with a real repository

Same steps, same expectation, different values → row. No discussion needed.

Different expectation → case, even if the steps look similar. The expected result is what the case is for.

Same steps, same expectation, but this variation needs its own priority, owner, or independent selection → case, and accept the duplicated steps as the price of addressability.

When the table gets wide enough that nobody can say what is in it, that is a signal about execution budget, not about correctness. Split the table into the rows that run always and the rows that run occasionally rather than splitting the case.

Never split a case because a row failed. A failing row is one failing execution, and it is already individually recorded.

In a TestRail- or Xray-class case repository, how do you decide whether a variation belongs as another row in a case's variant table or as a stored case of its own?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The row test

Signals a row is really a case in disguise

The costs sit on opposite sides

Authoring is cheap; running is not

A rule that survives contact with a real repository

▾common follow-ups2 questions

▾red flags5 flags

The row test

Signals a row is really a case in disguise

The costs sit on opposite sides

Authoring is cheap; running is not

A rule that survives contact with a real repository

answer

go deeper