12 KiB
title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_branches | related_projects | created | last_reviewed | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Flaky test quarantine 전략 — Spotify / Google / Microsoft / Fowler 사례 모음 | company-tech-blog | https://martinfowler.com/articles/nonDeterminism.html | raw | medium |
|
|
|
2026-05-22 | 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-confirmationstrength 로 표기.
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) 모니터링 메커니즘 정의
- Spotify/Google/Microsoft 원본 인용을 archive.org 또는 대체 미러로 재확인 (현 상태로는 wiki/concepts 인용 시
메모 / 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:
- 인용한 wiki 요약: (미작성)