Test quarantine

Quarantine is a deliberate policy for handling tests that have been shown to be unreliable. Once a test is demonstrated to fail intermittently, it is moved out of the blocking suite into a separate group. It continues to run, its results continue to be recorded, and it no longer breaks the build for everybody else. The purpose is to restore the meaning of a red pipeline immediately, without deleting the coverage or pretending the underlying cause has been dealt with. It is a containment measure rather than a repair, and remembering that is the difference between a useful tool and a standing excuse.

Without a policy, teams do one of two worse things. They leave the unreliable test in the blocking suite, and the whole thing loses its authority, because from then on every failure requires a human to guess whether it is genuine. Or they delete the test, losing the coverage silently along with any record that the area was ever checked at all. Quarantine makes the trade-off visible instead: there is a list, it has names on it, and its length is a number the team can be asked about in a review.

Rules that stop it becoming a graveyard

• An entry condition based on evidence, such as repeated failures against unchanged code, rather than on somebody’s frustration during a release evening.
• An owner and a date on every entry, because an unowned quarantined test is a deletion with extra administrative steps.
• A cap on the size of the list. If it grows faster than it drains, the cause is the environment or the fixtures rather than any of the individual tests.
• An exit that demands proof, such as a run of consecutive passes on the reinstated test before it is allowed to gate a build again.

Quarantine buys time to diagnose a cause, so it is a waiting room; a suite where tests check in and never leave has merely relabelled its dead coverage.