llm-wiki/raw/company-tech-blogs/ci-flaky-test-quarantine-spotify-google.md

---
title: Flaky test quarantine 전략 — Spotify / Google / Microsoft / Fowler 사례 모음
source_type: company-tech-blog
url: https://martinfowler.com/articles/nonDeterminism.html
archive_url:
status: raw
confidence: medium
tags: [ci, flaky-test, quarantine, test-strategy, ca-skeleton]
related_branches: [feature-ci-quality-gates-contract, feature-test-taxonomy-fixture-contract]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Flaky test quarantine 전략 — Spotify / Google / Microsoft / Fowler 사례 모음

> Layer: `raw/company-tech-blogs/` — 다수 기술 블로그 + Fowler 글 발췌.
> 공식 best practice 아님. quarantine 자체에 찬반 양론 공존.
> **검증 상태 주의**: 2026-05-27 재확인 시 **Spotify (2019) URL HTTP 404**, **Microsoft VSTS 글 HTTP 404**, **Google Testing Blog 본문 미스크랩** — Fowler 글 외 verbatim quote 재확인 불가. 본 문서의 Spotify / Google / Microsoft 인용은 **원본 raw 기록(2026-05-22)의 archived recollection** 으로 보존하되 `needs-confirmation` strength 로 표기.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-ci-quality-gates-contract]] | "flaky test quarantine bucket 허용 + sunset 14일" 결정의 외부 근거 — Spotify/Google 의 quarantine 운영 사례 + Fowler 의 sunset 강조 |
| [[raw/branch-notes/feature-test-taxonomy-fixture-contract]] | flaky 발생 시 어느 taxonomy bucket 으로 격리할지의 contract 결정 근거 |
| [[raw/project-notes/ca-skeleton-operational-contract]] | Group G-G — Skeleton Governance / CI quality gates 의 quarantine 정책 외부 사례 |

## 컨텍스트 / 왜 저장했는지

`feature-ci-quality-gates-contract` 결정 "flaky test quarantine bucket 허용 + sunset 14일" 의 외부 근거. quarantine 자체가 안티패턴이라는 주장 (Martin Fowler) 과 quarantine 을 운영 도구로 인정하는 주장 (Google/Spotify/Microsoft) 이 공존하므로, ca-tmpl 이 어느 입장인지 명시할 근거가 필요.

## 출처 / Source

- 원본 URL (Fowler — verified 2026-05-27):
  - Martin Fowler — "Eradicating Non-Determinism in Tests" https://martinfowler.com/articles/nonDeterminism.html
- 원본 URL (재확인 시 dead links, 2026-05-27):
  - Spotify Engineering — "Test Flakiness: Methods for identifying and dealing with it" (2019-11) https://engineering.atspotify.com/2019/11/test-flakiness-methods-for-identifying-and-dealing-with-it/ — **HTTP 404**
  - Google Testing Blog — "Flaky Tests at Google and How We Mitigate Them" (2016) https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html — 페이지 응답 200 이나 본문 본 fetch 에서 미스크랩 (재확인 필요)
  - Microsoft Engineering — "How we approach testing VSTS to enable continuous delivery" https://devblogs.microsoft.com/devops/how-we-approach-testing-vsts-to-enable-continuous-delivery/ — **HTTP 404**
- 아카이브 URL: (미수집 — 추가 작업 필요)
- 저자 / 조직: Spotify Engineering, Google Testing Blog, Microsoft DevOps Blog, Martin Fowler
- 발행일: 2011 (Fowler) / 2016 (Google) / 2019 (Spotify) / 시점불명 (Microsoft)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§Fowler — Quarantine] "Place any non-deterministic test in a quarantined area. (But fix quarantined tests quickly.)"

> [§Fowler — Test debt risk] "A danger here is that tests keep getting thrown into quarantine and forgotten, which means your bug detection system is eroding."

> [§Fowler — Definition] "A test is non-deterministic when it passes sometimes and fails sometimes, without any noticeable change in the code, tests, or environment."

> [§Fowler — Goal] "My principal aim in this article is to outline common cases of non-deterministic tests and how to eliminate the non-determinism."

> [§Spotify 2019 (original raw, archived recollection — link dead 2026-05-27)] "When we detect a flaky test, we automatically move it to a quarantine list. Tests in the quarantine list still run, but their failures don't block the build. The owning team has a fixed deadline to either fix or delete the test."

> [§Google Testing Blog 2016 (original raw, archived recollection — body not re-scraped 2026-05-27)] "Almost 16% of our tests have some level of flakiness associated with them! … We have a system that automatically detects flaky tests and, if a test fails too often, we mark it as flaky and ignore its result for the purpose of build verification."

> [§Microsoft DevOps Blog (original raw, archived recollection — link dead 2026-05-27)] "If a test fails because of a flaky problem, then we have a process to file a bug, quarantine the test, and continue our pipeline. … Quarantined tests must be fixed within a defined SLA, or they are deleted."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| FLAKY-QUAR-C1 | Fowler 는 non-deterministic test 를 quarantine 영역에 두되 "빠르게 고치라" 고 명시 (sunset 의 필요성을 직접 언급) | [§Fowler — Quarantine] "Place any non-deterministic test in a quarantined area. (But fix quarantined tests quickly.)" | `engineering-blog` | 일반적 CI quarantine 정책 설계 | 정확한 sunset 기간 (며칠/주) 은 Fowler 가 명시하지 않음 — ca-tmpl 의 "14일" 은 별도 결정 |
| FLAKY-QUAR-C2 | Fowler 는 quarantine 의 위험으로 "tests keep getting thrown into quarantine and forgotten" 을 명시 — 잊혀지면 bug detection system 이 침식됨 | [§Fowler — Test debt risk] "A danger here is that tests keep getting thrown into quarantine and forgotten, which means your bug detection system is eroding." | `engineering-blog` | quarantine policy 의 운영 리스크 | quarantine 이 무조건 안티패턴이라는 뜻은 아님 — Fowler 는 "고치라" 는 단서로 허용 |
| FLAKY-QUAR-C3 | Fowler 의 non-deterministic test 정의: "without any noticeable change in the code, tests, or environment" 임에도 pass/fail 이 갈리는 테스트 | [§Fowler — Definition] "A test is non-deterministic when it passes sometimes and fails sometimes, without any noticeable change in the code, tests, or environment." | `engineering-blog` | flaky test 의 명확한 정의 채택 | 이 정의가 모든 CI 도구의 표준 정의라는 뜻은 아님 — Fowler 의 articulation |
| FLAKY-QUAR-C4 | Spotify (2019) 는 flaky 감지 시 자동으로 quarantine list 로 이동, 실패가 build 를 막지 않으며, 소유 팀에 고정 deadline 부여 — **본 인용은 원 raw 기록의 archived recollection. 2026-05-27 재확인 시 source URL HTTP 404** | [§Spotify 2019 (archived recollection)] "When we detect a flaky test, we automatically move it to a quarantine list. Tests in the quarantine list still run, but their failures don't block the build. The owning team has a fixed deadline to either fix or delete the test." | `needs-confirmation` | Spotify 의 CI quarantine 운영 (재확인 필요) | 원 URL 재확인 불가 → 인용 정확성 보장 안 됨. archive.org 등으로 별도 검증 필요 |
| FLAKY-QUAR-C5 | Google Testing Blog (2016) 는 "Almost 16% of our tests have some level of flakiness" 을 보고하고, fail-too-often 한 테스트를 자동으로 flaky 마킹 + build verification 에서 무시 — **본 인용은 원 raw 기록의 archived recollection. 2026-05-27 재확인 시 본문 미스크랩** | [§Google Testing Blog 2016 (archived recollection)] "Almost 16% of our tests have some level of flakiness associated with them! … We have a system that automatically detects flaky tests and, if a test fails too often, we mark it as flaky and ignore its result for the purpose of build verification." | `needs-confirmation` | Google 의 flaky test 비율 + 자동 마킹 정책 | 16% 수치 + 자동 무시 정책 재확인 필요. 본 fetch 에서 본문 미스크랩, 재시도 필요 |
| FLAKY-QUAR-C6 | Microsoft VSTS 는 flaky 발견 시 bug 등록 + quarantine + 파이프라인 진행, quarantine 된 테스트는 정의된 SLA 내 수정 또는 삭제 — **본 인용은 원 raw 기록의 archived recollection. 2026-05-27 재확인 시 source URL HTTP 404** | [§Microsoft DevOps Blog (archived recollection)] "If a test fails because of a flaky problem, then we have a process to file a bug, quarantine the test, and continue our pipeline. … Quarantined tests must be fixed within a defined SLA, or they are deleted." | `needs-confirmation` | Microsoft VSTS 의 CI quarantine 운영 (재확인 필요) | URL 재확인 불가 → 인용 정확성 보장 안 됨. archive.org 등으로 별도 검증 필요 |
| FLAKY-QUAR-C7 | "quarantine 후 sunset" 패턴은 다수 (Spotify / Google / Microsoft / Fowler) 가 공유하는 일반 아이디어 — 단 정확한 SLA 일수, 자동/수동 여부는 사례별 다름 | (cross-source synthesis) | `engineering-blog` | quarantine 정책의 공통 패턴 인식 | "Google/Spotify 가 하니까 공식 best practice" 이라는 격상 금지 (`company-tech-blog` 등급, CLAUDE.md §5) |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `FLAKY-QUAR-C1` ~ `C3`: Fowler 의 quarantine 허용 + sunset 강조 + 위험 경고 + non-deterministic test 정의 (verified 2026-05-27)
  - `FLAKY-QUAR-C7`: 다수 사례에서 "quarantine + sunset" 패턴이 반복되는 사실 (cross-source synthesis, 약한 일반화)
- **이 자료가 증명하지 않는 것**:
  - `FLAKY-QUAR-C4` ~ `C6`: Spotify/Google/Microsoft 인용은 원 raw 기록의 archived recollection — 본 fetch 시점에 재확인 실패. 별도 archive.org 검증 전까지 `needs-confirmation`
  - "ca-tmpl 의 14일 sunset" 이 industry 평균 / 권장값이라는 일반화 — 그 어느 사례도 정확한 일수를 공개하지 않음
  - quarantine 자체가 효과적이라는 측정 데이터 (pass rate 향상 등)
  - quarantine 이 모든 CI 환경에 적합하다는 일반화
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - Spotify/Google/Microsoft 원본 인용을 archive.org 또는 대체 미러로 재확인 (현 상태로는 wiki/concepts 인용 시 `needs-confirmation` 명시 필수)
  - ca-tmpl 의 14일 sunset 이 14일인 이유의 별도 결정 근거 (생산성 vs debt 트레이드오프)
  - quarantine 통계 (현재 ca-tmpl 의 quarantine 진입/탈출 rate) 모니터링 메커니즘 정의

## 메모 / Notes

> 검증되지 않은 내 해석은 wiki source-summary 단계에서만.

- 공통 패턴 (사례 공유): (1) flaky detect → (2) auto-quarantine → (3) sunset deadline → (4) deadline 초과 시 delete.
- ca-tmpl 결정 "sunset 14일" 은 Spotify (미공개 SLA) 와 Google (rerun threshold) 사이의 보수적 값 추정. raw 단계에서는 근거 부족 — 내부 결정 노트 별도 확인 필요.
- Martin Fowler 반대 입장도 보존: ca-tmpl 은 "quarantine 허용하되 14일 강제 sunset" 으로 절충.
- 주의: Spotify/Google/Microsoft 는 모두 *company-tech-blog* 등급이므로, wiki/concepts 에 옮길 때 "Google 이 그러니까 공식이다" 로 표현 금지 (CLAUDE.md §5).
- **재확인 TODO**:
  - [ ] Spotify 2019 글의 새 URL 또는 archive.org 스냅샷
  - [ ] Microsoft VSTS 글의 새 URL 또는 archive.org 스냅샷
  - [ ] Google Testing Blog 본문 verbatim 재추출 (현 fetch 에서 본문 미스크랩)

## Related / 관련

- 같은 주제 다른 raw:
  - (없음 — 본 문서가 flaky test 주제 집합 단일 문서)
- 인용하는 branch:
  - [[raw/branch-notes/feature-ci-quality-gates-contract]] — flaky test quarantine bucket SSOT (sunset 14일)
  - [[raw/branch-notes/feature-test-taxonomy-fixture-contract]] — consumer (flaky 발생 시 quarantine bucket 참조)
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-operational-contract]] (Group G-G)
- 인용한 wiki 요약: (미작성)