8.3 Suite architecture와 runbook
유지 가능한 suite는 product risk와 test cost에 맞춰 계층을 나눕니다.
tests/
smoke/ # 배포 차단 핵심 flow
regression/ # 기능별 상세 flow
visual/ # 고정 환경 screenshot
playwright/
fixtures.ts
pages/
auth/
Review 기준
- 다른 test와 독립적인가?
- User-facing locator를 사용하는가?
- Fixed sleep과 불필요한 force가 없는가?
- Test data가 worker별로 분리되는가?
- Assertion이 business 결과를 확인하는가?
- 실패 시 trace, log로 원인을 찾을 수 있는가?
- Cleanup이 안전한 target만 다루는가?
실패 runbook
- Product failure와 infrastructure failure를 분류합니다.
- HTML report와 첫 실패 trace를 확인합니다.
- 같은 commit, project, shard에서 재현합니다.
- Locator, network, console, server log를 대조합니다.
- 제품 bug면 issue와 artifact를 연결합니다.
- Test bug면 원인과 회귀 test를 남깁니다.
- Quarantine에는 owner와 복귀 조건을 지정합니다.
Suite 크기보다 신뢰도가 중요합니다. Flaky test를 방치하면 팀이 red build를 무시하기 시작하므로 flaky budget과 정리 시간을 운영 지표로 둡니다.
운영 지표
| 지표 | 질문 |
|---|---|
| Pass rate | 실제 제품 품질과 일치하는가? |
| Flaky rate | Retry가 숨긴 불안정성이 얼마나 되는가? |
| P50/P95 duration | 느려지는 test group은 무엇인가? |
| Failure signature | 반복되는 root cause는 무엇인가? |
| Artifact size | 분석 가치 대비 비용이 적절한가? |
| Quarantine age | 임시 제외가 영구화됐는가? |
Failure triage template
- Run / project / shard:
- 최초 실패 step:
- Product bug / test bug / environment:
- Trace·network·server log 증거:
- 재현 command:
- Owner / issue / deadline:
- Release decision:
Upgrade runbook
- Playwright release note 확인
- Package와 browser binary 함께 update
- Smoke + representative visual baseline 실행
- Deprecated API와 behavior change 확인
- Full nightly 실행
- Rollback 조건과 artifact 비교
실습
- 의도적 failure를 세 분류로 triage합니다.
- Flaky budget과 quarantine SLA를 숫자로 정합니다.
- Upgrade pull request checklist를 작성합니다.
- 오래된 test 삭제 기준을 정합니다.