Quarantine Without Creating a Permanent Test Graveyard

Quarantine starts as discipline: a test is failing intermittently, the cause isn’t understood yet, and rather than let it block every merge, it’s pulled out of the required path with a ticket attached. Eighteen months later, a team runs an audit and finds two hundred quarantined tests, most with tickets nobody has looked at since they were filed, several testing behavior the product no longer has. The mechanism that was supposed to buy time to investigate has become a place tests go to be forgotten without ever being deleted.

That drift isn’t a failure of the concept. It’s what happens when quarantine has an entry door and no exit process. Quarantine is a temporary risk-control mechanism, not a destination for inconvenient tests.

Why quarantine exists

Valid reasons to quarantine a test are narrow and specific: a newly discovered nondeterministic test whose cause isn’t yet known, a confirmed infrastructure incompatibility, a test genuinely blocked by an active, tracked product defect, or a dependency incident outside the team’s control. Each of these has a natural resolution point. None of them is “this test is annoying” or “we don’t have time to fix it this sprint” — those are real pressures, but they describe a maintenance backlog, not a quarantine candidate.

What quarantine must preserve

The failure mode that turns quarantine into a graveyard is removing a test from the required path and removing it from visibility at the same time. A properly quarantined test should still execute on a defined schedule, still report its result, retain a named owner, link to a tracked issue, carry an expiry or review date, and remain visible in whatever quality reporting the team actually looks at. A test that stops running the moment it’s quarantined isn’t quarantined — it’s silently deleted with extra steps.

quarantined: true
quarantineReason: "Intermittent duplicate event delivery"
quarantineIssue: "QE-1842"
quarantineOwner: "checkout-quality"
quarantinedAt: "2026-07-10"
reviewAt: "2026-07-24"

Every one of those fields exists to answer a question someone will eventually ask: why is this here, who’s responsible, and when does this get revisited. A quarantine entry missing any of them is already halfway to being forgotten.

Exit conditions

A test leaves quarantine — back into the required path, or deleted outright — when the cause has been identified, a fix has passed repeated execution, the test has demonstrated stability over a defined window, the blocking product defect has been resolved, or the test has been intentionally replaced or removed. The point of naming these conditions explicitly is that “we’ll look at it eventually” is not a condition; it’s the absence of one, and it’s exactly what produces a two-hundred-test backlog nobody owns.

1. Confirm the original quarantine reason still applies — has the underlying cause been reproduced recently, or has the system moved on?
2. If the cause is known and fixed, run the test repeatedly against the fix before restoring it to the required path.
3. If the cause is still unknown after the review window, escalate — don’t silently extend the expiry date.
4. If the behavior it protects no longer exists or is covered elsewhere, delete it instead of re-quarantining it.

Governance without bureaucracy

The lightest version of this that actually works is a weekly quarantine review, a maximum age past which a test must be resolved one way or another, a visible count broken down by owning team, and automated expiry warnings that surface before a ticket goes stale rather than after. None of this requires a formal process document — it requires the review actually happening, which is the part that tends to lapse first once the initial urgency fades.

When deletion is the right call

Not every quarantined test deserves to be fixed. Some deserve to be deleted: tests protecting behavior the product no longer has, tests duplicating coverage a cheaper test already provides, tests that have never produced a reliable signal even before quarantine, tests with no owner willing to claim them, and tests whose maintenance cost has clearly outgrown the risk they control.

Key takeaways