In a TestRail- or Xray-class case repository, what changes when a case's variant rows are stored inside the case itself rather than in a shared table several cases point at?
answer
- values with the case or apart
- self-describing versus one edit
- duplication drifts, sharing ripples
- column names are an interface
- past executions keep their values
basics
~20 sRows stored inside the case make it self-describing and independent, at the cost of duplicating the same values across cases. A shared table gives one edit for every case bound to it, but changes their meaning invisibly.
solid answer
~40 sBinding is identical either way - a placeholder names a column and that column is resolved in whichever table the case is bound to - so the difference is blast radius and readability. Inline rows make the case self-describing: a reviewer sees exactly what will run, a copy carries its values, and an edit disturbs nobody else. The price is duplication, and duplicated values drift because nothing tells one case the other exists. A shared table fixes drift, since one edit reaches every bound case, but a careless edit silently changes the meaning of cases you have never read, and the case can no longer be understood without opening a second object. Because binding is by name, the shared table's column names become an interface unrelated cases depend on.
go deeper
Know that the same rows can sit inside a case or in a separate table it points at, and that the second choice means several cases share one set of values.
Explain both costs concretely: duplicated rows drift apart silently, while a shared table gives one edit a blast radius across cases the editor may never have opened.
Demonstrate operating judgment - who is allowed to edit shared values, how a bad edit would surface, and why a recorded execution must keep the values it ran with rather than re-reading the table.
Own the standard: decide when the repository should share values at all, what makes a shared table an interface with a rename policy, and how that lines up with who owns fixture identities.
## Two places the same rows can live The values a data-driven case runs on have to sit somewhere, and a case repository generally offers two shapes for that: - **Inline** — the variant table is part of the case. Open the case and the rows are right there. - **Shared** — the table is a separate named object, and several cases **point at it**. Open a case and you see a reference, not values. Both bind the same way. A placeholder in a step names a **column**, and that column name is resolved against whichever table the case is bound to. The substitution mechanism does not change at all. What changes is **who else moves when a value changes** and **what a reader learns from the case alone**. ## What inline rows buy and cost Inline rows make the case **self-describing**. A reviewer reading it sees precisely what will run. A copy of the case carries its values with it, so it behaves the same wherever it lands. Editing a row cannot disturb anybody else's case, which keeps the ownership story simple: whoever owns the case owns its data. The cost is **duplication**. Three cases that all need the same set of accounts hold three copies of them. When one of those values goes stale it goes stale in three places and is usually corrected in one, and two cases that were meant to be equivalent quietly stop being so. The drift is silent because nothing in either case mentions that the other exists. ## What a shared table buys and costs A shared table gives you **one edit that reaches every bound case**. When the values are the fixture identities the whole suite depends on, that is a genuine saving: rotating them is one change instead of a search across the repository, and every case that should agree does agree by construction. The costs are **blast radius** and **opacity**. A single careless edit changes the meaning of every case bound to the table, and none of those cases record that anything happened to them. The case also stops being readable on its own: to know what a step will actually do, a reviewer must open a second object. That is a real loss on a repository whose value is that a stored case can be reviewed before anybody runs it. | | Inline rows | Shared table | |---|---|---| | Reading one case tells you what will run | yes | no, follow the reference | | Fixing a stale value | once per case that holds it | once, everywhere | | Blast radius of a wrong edit | one case | every bound case | | Risk of two cases silently disagreeing | high | low | | Copy or export of the case | carries its values | may arrive unbound | ## The column name is the contract Because binding is by name, a shared table's **column names are an interface** that unrelated cases depend on, and the usual interface rules apply: - **Adding a column** is safe; cases that do not name it ignore it. - **Renaming or deleting a column** breaks every case whose steps still name the old one, including cases the person making the change has never read. - **Changing what a value means while keeping its name** is the worst of the three, because nothing breaks. The steps still bind, the run still expands, and expected results that were correct are now quietly wrong. One more thing that must hold whichever shape you choose: an execution already recorded has to keep the values it actually ran with. If a past result re-reads the table at display time, editing a row rewrites history, and a failure investigated next week shows values that were never used. ## Choosing between them 1. **Do several cases genuinely need the same rows?** If not, sharing buys nothing and costs readability. 2. **Does a reviewer need to see the values in the case?** Cases that exist to be read and approved before execution argue for inline. 3. **Who owns the values?** If one person maintains fixture identities for the whole suite, a shared table matches the ownership that already exists. 4. **How loud is a bad edit?** If a wrong shared value would surface as an obvious failure in the next run, sharing is cheap. If it would surface as a plausible-looking wrong expected result, inline the values or make the shared table something people must deliberately change.
- Which change to a shared variant table is the most dangerous, and why?Keeping a column name while changing what its values mean. Renaming or deleting a column breaks bindings loudly, so somebody notices. Redefining the values breaks nothing: every bound case still expands, still renders, and still asserts an expected result that is now quietly wrong for the new meaning. Loud breakage is a gift; silent breakage is what ships.
- Why must an execution recorded last month keep the values it actually ran with?Because a result is evidence of one attempt. If the record re-reads the current table at display time, editing a row rewrites history, and a failure investigated later shows values that were never used. The bound values belong to the execution, not to the live table, which is what makes an old failure reproducible at all.
saying these in an interview costs you the question
- Thinks sharing values changes how placeholders bind
- Assumes a shared edit only affects one case
- Says duplicated rows stay in agreement by themselves
- Ignores that a referencing case is unreadable alone
- Lets a recorded result re-read the current table