Test quarantine
Test quarantine moves a flaky test out of the blocking suite into a tagged 'quarantine' suite that runs but doesn't fail the build. Quarantine prevents the flaky test from blocking deploys while preserving its signal for triage; the discipline requires actively working through the quarantine, not letting it grow.
Quarantine is a triage tool, not a permanent home. Healthy use: a test moves to quarantine when flakiness is identified; an owner is assigned; a deadline (typically 1-2 weeks) is set for fix or delete. Tests that linger in quarantine for months should be deleted — they're not catching regressions, they're not being maintained, and they're not going to be fixed. The metric to watch is quarantine size and age: a quarantine that's stable or shrinking is healthy; one that grows indicates teams aren't paying down the debt.
Related terms
- Flaky test
A flaky test is one that sometimes passes and sometimes fails without any code change — typically caused by timing dependencies, shared state, network/external-system reliance, or race conditions.
- Test isolation
Test isolation is the property that each test runs independently — no shared state, no execution-order dependency, no side effects bleeding to the next test.
- Test impact analysis
Test impact analysis identifies the subset of tests relevant to a code change — by analysing the dependency graph between source files and test files — so CI runs only the affected tests instead of the entire suite.