How to Explain a Flaky Test Quarantine Policy in English

A flaky test — one that intermittently fails without any real code change — erodes trust in a test suite faster than almost anything else. A quarantine policy (moving flaky tests out of the blocking suite while they’re investigated) is a common fix, but it needs to be explained carefully in English, or it quietly becomes a graveyard where tests go to be ignored forever. This guide covers the phrases for proposing and enforcing that policy clearly.

Proposing the Policy

Frame quarantine as a temporary holding area with an expiry, not a permanent exemption.

• “I’d like to propose a quarantine process for flaky tests — instead of blocking every merge, we move a confirmed-flaky test out of the required suite for a fixed window while someone investigates.”
• “The key word here is temporary — quarantine isn’t a place tests go to die, it’s a two-week holding pen with an owner and a deadline.”
• “Without a policy like this, people are already working around flaky tests informally — re-running CI, ignoring red builds — this just makes that visible and tracked instead of ad hoc.”

Defining What Qualifies

Be precise about the bar for quarantining a test, so it isn’t used as an escape hatch for genuine bugs.

• “A test qualifies for quarantine if it’s failed intermittently at least three times with no corresponding code change — not just ‘it failed once and I’m in a hurry.’”
• “If the failure is reproducible even occasionally under the same conditions, that’s a real bug, not flakiness — it doesn’t belong in quarantine.”
• “Quarantine is for the test’s reliability, not a way to silence a test that’s correctly catching a real regression.”

Assigning Ownership

A quarantine without an owner is where tests disappear permanently — be explicit about who’s responsible.

• “Every quarantined test needs an owner and a ticket — no exceptions, even if the fix looks trivial.”
• “Whoever quarantines the test is responsible for triaging it within the window, not just tagging it and moving on.”
• “If nobody owns it after two weeks, the default is to delete the test, not extend the quarantine indefinitely.”

Handling Pushback

Some team members will worry quarantine hides problems rather than solving them — address that directly.

• “I understand the concern that this could become a way to avoid fixing tests — that’s exactly why we’re pairing it with a hard expiry and a visible dashboard of what’s currently quarantined.”
• “The alternative isn’t ‘no flaky tests’ — it’s flaky tests silently blocking merges and everyone re-running CI without a paper trail. This makes the problem visible instead of invisible.”
• “We’ll review the quarantine list in the weekly engineering sync, so it stays a shared responsibility, not one person’s forgotten backlog.”

Reporting on Quarantine Health

Regularly surface the state of the quarantine list so it doesn’t grow silently.

• “This week we had four tests in quarantine — two got fixed and un-quarantined, one got deleted as obsolete, one is still being investigated and needs a new owner.”
• “The quarantine list has been growing for a month without anything coming out of it — that tells us the process is broken, not that we suddenly have more flaky tests.”

Vocabulary Reference

Key Takeaways

• Frame quarantine explicitly as temporary, with an expiry — not a place tests go to be forgotten.
• Define a precise bar for what qualifies as flaky, distinct from a genuine, reproducible bug.
• Assign an owner and a ticket to every quarantined test — an ownerless quarantine is where trust breaks down.
• Address the “this hides problems” concern directly by pairing quarantine with visibility and a hard deadline.
• Report on quarantine health regularly so a growing, stagnant list gets caught early.