A shared environment breaks and forty cases fail in one cycle of a TestRail-class case repository. What stops that becoming forty tracker items, and where does that protection stop working?
answer
- suppression is per case, per cycle
- forty cases are forty distinct keys
- a new cycle forgets last cycle's filing
- one item attached to many results
- over-suppressing loses a real defect silently
basics
~20 sSuppression covers a repeat filing of the same case within the same cycle: the action offers the existing item instead of creating another. It cannot help here - forty different cases are forty keys, so each is a legitimate first filing.
solid answer
~50 sBuilt-in suppression is narrow on purpose. It remembers, per cycle, that this case already produced a tracked item, so pressing the file action again on the same case offers to attach the existing item rather than create a second one. That defeats the honest mistakes — two testers on the same red, or one tester filing after a re-attempt. It does **not** defeat the scenario in the question: forty different cases are forty distinct keys, and each one is a first filing. Nor does it survive a new cycle: a rerun in a fresh cycle has no memory of the previous one, so a still-broken case files again. The controls that actually work here are human and procedural — recognise the common cause, file one item, and attach that existing item to the other thirty-nine results so every red is accounted for without a queue of near-identical tickets.
go deeper
Know that pressing file twice on the same failing case in the same cycle offers you the item that already exists, rather than making a second one, and that this only covers that same case.
Explain what the check is keyed on and why the scope is narrow: the repository knows the case, the cycle and the item, but not the cause, so it cannot match two different cases.
Show the operational move — diagnose the common cause, file one item, attach it to the other failed results so no red is left unaccounted for — and name the rerun cycle as the place the protection lapses.
Own the asymmetry: an over-eager matcher loses a real defect silently while a duplicate is merely visible work. Decide where automation stops and what convention your teams follow during an environment outage.
## What the product actually suppresses The duplicate protection built into filing is **per case, per cycle**. The repository remembers that an execution of this case in this cycle already produced a tracked item, so the second press of the file action does not silently create a second one: it surfaces the existing item and offers to attach it to this result instead. That narrow scope is not laziness. It is the only judgement the repository can make from data it actually holds. It knows the case, the cycle and the item that was filed. It does not know *why* the run failed, so it cannot tell whether two failures share a cause. **What that reliably prevents:** - Two testers working the same cycle both filing the same red. - One tester filing, re-attempting, watching it fail again and filing a second time. - A retried result creating a second item for a failure already tracked. ## The three places it stops working 1. **Many cases, one cause — the scenario above.** Forty cases are forty keys. Every filing is a first filing for its own case, so nothing is suppressed and the tracker receives forty items about one broken environment. This is the failure mode that actually hurts, because it arrives in a burst and takes a human afternoon to unpick. 2. **A new cycle resets the memory.** The suppression is scoped to the cycle. A rerun executed as a fresh cycle — a nightly, a re-test after a build, a per-release copy — has no record of what was filed last time, so a still-broken case files again. Across a week of nightlies, one unfixed defect can produce a stack of items that differ only in the cycle they name. 3. **Filing that bypasses the action.** Someone opens the tracker directly, or an automated result feed creates items on its own path. The repository never learns that an item exists, so its check has nothing to check against. | Situation | Suppressed by the product? | Why | |---|---|---| | Same case, same cycle, filed twice | yes | same key, item already recorded | | Forty cases, one broken environment | no | forty distinct keys, each a first filing | | Same case, new cycle after a rerun | no | the memory is scoped to the cycle | | Item created by hand in the tracker | no | the repository was never told | ## What to do about the burst 1. **Stop and diagnose before filing anything.** A wall of simultaneous reds in one cycle is far more often one condition than forty defects. The first question is what they have in common, not which to file first. 2. **File one item for the cause.** It gets the provenance from one representative execution and a plain statement of scale — that this many cases in this cycle fell over together. 3. **Attach that existing item to the other results.** This is the part teams skip. Every other red then reads as accounted for, the cycle stops showing a wall of untracked failures, and nobody re-files them tomorrow. The attach path is exactly what the suppression prompt offers; use it deliberately instead of only when the product suggests it. 4. **Separate anything that turns out to be its own defect.** Some of the forty will not be explained by the common cause. They deserve their own item, filed from their own execution. 5. **Re-attach rather than re-file on the next cycle.** When the rerun cycle is still red, attach the existing open item to the new results. This is the discipline that stops one unfixed defect turning into a week of near-identical tickets. ## Why the product does not try harder An automatic cross-case matcher would have to decide that two failures share a cause — from a failure comment and an attachment, written by different people, in prose. Guessing wrong in the direction of suppression is far worse than a duplicate: a suppressed filing means a real defect was never tracked, and nobody sees an absence. So products stay on the safe side and suppress only what they can prove — the same case, in the same cycle. Deciding after the fact that one item restates another is triage work in the tracker, done by a person with the two reports in front of them. ## The interview signal The answer that lands is not "the tool deduplicates". It is: **the tool suppresses one narrow, provable repeat; the burst, the rerun and the hand-filed item all get through; and the operational answer is one ticket attached to many results.** That is the answer of someone who has cleaned up the queue the morning after a shared environment fell over.
- Why do products not try to detect that two different cases failed for the same reason?Because the only evidence is prose written by different people. Guessing wrong toward suppression is the dangerous direction: a real defect is never tracked and nobody notices an absence, whereas a duplicate is visible and cheap to resolve. Judging that two reports restate one problem is triage work done by a person.
- How do you keep a week of nightly reruns from producing seven near-identical items?Attach the existing open item to each new cycle's failed result instead of filing again. The rerun cycle carries no memory of the previous one, so the discipline has to be human: the first red in a new cycle is checked against what is already open before anyone presses file.
saying these in an interview costs you the question
- Claims the product deduplicates across different cases
- Assumes suppression survives into a new rerun cycle
- Files one ticket and leaves the other reds untracked
- Wants aggressive automatic matching, ignoring the silent-loss risk
- Confuses filing-time suppression with rejecting an item later