What is Test Quarantine?

Test quarantine is the practice of moving a flaky or unreliable test out of the main pass/fail gate, so it no longer blocks the build, while keeping it running and tracked separately so it is fixed rather than forgotten.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

Flaky tests, which pass and fail without code changes, are corrosive: they erode trust in the suite, cause people to ignore or blindly re-run failures, and block delivery when a green pipeline is required. Test quarantine is a pragmatic response: when a test is identified as flaky, you remove it from the blocking gate (so one unreliable test does not stop everyone) but keep executing it in a separate, non-blocking lane and log it for repair.

The key tension is that quarantine must be a temporary holding area, not a graveyard. The danger is that quarantined tests are forgotten, quietly reducing real coverage, sometimes hiding genuine bugs the flaky test was intermittently catching. Good practice puts guardrails around it: a quarantine has an owner and a deadline, the list is reviewed regularly, limits are set on how many tests can be quarantined, and metrics track time-in-quarantine so flakiness is actively driven down, not just hidden.

Quarantine pairs with flakiness detection (identifying tests that fail intermittently) and root-cause fixing (the real goal, addressing timing, isolation, or environment issues). Done well, it keeps the pipeline fast and trusted while preserving the intent to restore every test; done poorly, it becomes a way to sweep unreliable tests, and lost coverage, under the rug.

WHY IT MATTERS

Why interviewers ask about this.

Flaky-test management, including quarantine, is a practical interview topic for automation and lead roles. Explaining quarantine as a temporary, tracked isolation (with owners, deadlines, and limits) shows you can keep a pipeline trustworthy without letting flakiness either block delivery or quietly destroy coverage.

EXAMPLE

Example scenario.

A flaky end-to-end test fails about 20% of the time and keeps blocking deploys. The team quarantines it: it moves to a non-blocking lane with an owner and a two-week deadline to fix the underlying race condition. The pipeline is green and trusted again, and because the test is tracked, it gets fixed and restored rather than silently abandoned.

TIP

Interview tip.

Define test quarantine as removing a flaky test from the blocking gate while still running and tracking it so it gets fixed. Stress the risk, quarantine becoming a graveyard that quietly loses coverage, and the guardrails that prevent it: owners, deadlines, limits, and regular review, with root-cause fixing as the real goal.

FAQ

Frequently asked questions.

What is the risk of quarantining flaky tests?

That quarantine becomes a graveyard: tests are moved out of the gate and then forgotten, quietly reducing real coverage and sometimes hiding genuine bugs the flaky test intermittently caught. Guardrails, owners, deadlines, quarantine limits, and regular review, keep it a temporary holding area rather than a way to bury unreliable tests.

How is test quarantine different from deleting a flaky test?

Deleting removes the test (and its coverage) permanently. Quarantine keeps the test running in a separate, non-blocking lane and tracks it for repair, so the pipeline is not blocked but the intent and coverage are preserved. The goal is to fix the flakiness and restore the test to the gate, not to discard it.