How do you quarantine an automated test that fails intermittently on unchanged code without the quarantine becoming permanent?

## What quarantine is for A case that fails unpredictably on unchanged code poisons a shared signal. Left in the gating lane it blocks unrelated merges, and the team's response is predictable and corrosive: people start re-running until green, and then they start ignoring red runs generally, including the true ones. Quarantine buys the team's attention back by removing one case from the gate. What it must not buy is amnesia. The distinction that matters is between **quarantine** and **switching a case off**. Switching off - a skip marker in the source, a commented-out block, a deleted line - stops the case executing, produces no data, and is visible only to someone reading that file. It has no owner, no date and no exit condition, so it becomes dead code that nobody dares remove because nobody remembers why it is there. Quarantine keeps the case running in a lane that does not block anything, so you accumulate exactly the evidence you will need later: how often it fails, whether it started passing again, whether it began failing consistently, which is a different problem entirely. ## The record A quarantine entry is a small, explicit contract. Six fields carry it: - **The case**, named by the behaviour it checks rather than by a file path. - **The date it entered**, so age is visible without archaeology. - **The observed symptom**, in one line, including where it fails and where it passes. - **A named individual owner.** Not a team alias, not a rotation, not the person on call. Aliases absorb responsibility; a name in a list that someone reviews aloud does not. - **An expiry date**, short enough to be uncomfortable. Two weeks is a common choice; the number matters less than that it exists and is enforced. - **The behaviour now unguarded.** This is the field teams skip and the one that makes the entry honest. Quarantining a case silently withdraws a check; writing down what is no longer verified is what lets someone judge whether that is acceptable. A seventh field is worth adding: a triage note distinguishing "this looks like a problem in the case" from "we have not ruled out a real intermittent defect in the product". Quarantine is legitimate for the first and dangerous for the second, because a genuine product race that only shows up occasionally is precisely the failure you most want to keep looking at. ## Enforcement, or the list only grows A policy nobody enforces is a wish. The mechanism is a check that runs in the pipeline on every build and fails it when an entry has no owner, when today is past an entry's expiry, or when the list exceeds a hard cap. The cap is the part that changes behaviour: once it is reached, nothing new enters quarantine until something leaves it, which converts a private convenience into a shared budget. Pair it with a fixed review cadence where the list is read aloud, oldest first, and each entry gets one of two dispositions. There are exactly two exits. **Repaired and returned** to the gating lane, after the fix has survived enough runs to mean something. Or **removed**, with a written decision recording what risk was accepted, by whom, and whether a compensating check was put anywhere else. If the case was the last thing guarding a behaviour that matters, removal is a decision to cover it another way, not a decision to stop caring. ## What it looks like when it goes wrong A suite over a clinical-trial data capture form had a quarantine list of 27 entries. The oldest had been there for eight months; nobody at the review could say what it had originally checked, because the entry recorded only a case identifier and the word "flaky". Two entries turned out to be the same case, added twice under different identifiers after a rename. One was a real intermittent product defect in how the form persisted a value entered in a locale-dependent format - it had been quarantined because it was inconvenient, and the behaviour it guarded had been unverified in every release since. Introducing a cap of twelve and a fourteen-day expiry drained the list in six weeks, mostly by forcing a decision rather than by anyone doing heroic repair work: nine cases were repaired, six were removed with a recorded rationale, and one became a defect ticket. ## The point an interviewer is testing Anyone can say "quarantine the flaky test". The question is whether you understand that quarantine transfers a risk rather than eliminating it, and whether you will build the small amount of machinery - owner, expiry, cap, review, written exit - that keeps the transfer visible. An empty quarantine list is not automatically good news either; it may simply mean the team is skipping cases in source instead, where no policy can see them.