관측성·신뢰도 지표
pass rate를 넘어 evidence completeness, environment drift, MTTR까지 묶어 테스트 운영 지표로 설계하는 방법
핵심 요약
- 테스트 관측성은 얼마나 많이 돌렸느냐보다 무엇을 측정해 어떤 행동으로 잇느냐가 더 중요합니다.
- Pass/Flake Rate를 넘어 MTTD·MTTR·Evidence Completeness·Environment Drift·Cost per Decision까지 KPI로 둡니다.
- 대시보드는 팀 운영·리드/매니저·경영 요약 3계층으로 분리해 보고합니다.
- 파이프라인의 핵심은 러너가 아니라 정규화 계층이며 gate·service·owner·classification·fingerprint를 함께 저장합니다.
- main/release failed는 즉시 알리고 flaky 3일 누적 시 deflake 티켓, evidence completeness 95% 미만 시 정책을 점검합니다.
에이전틱 테스트 환경에서는 얼마나 많이 돌렸느냐보다 무엇을 측정하고 그것을 어떤 행동으로 잇느냐가 더 중요합니다. 대시보드는 예쁘게 꾸미는 게 목적이 아닙니다. gate 품질과 우선순위를 결정하는 도구여야 합니다.
핵심 KPI
| 지표 | 정의 | owner | 권장 활용 |
|---|---|---|---|
| Pass Rate | 최근 N회 실행 중 성공 비율 | suite owner | 안정성 추세 |
| Flake Rate | retry/pass 패턴 포함 간헐 실패 비율 | QA platform | deflake 우선순위 |
| MTTD | 실패 발생 후 triage 시작까지 시간 | QA platform | 탐지/알림 품질 |
| MTTR | triage 시작 후 green 복구까지 시간 | suite owner | 운영 반응 속도 |
| Evidence Completeness | trace, log, event, env info가 충분히 남은 비율 | DevEx / QA platform | triage 생산성 |
| Environment Drift | 동일 probe의 환경 fingerprint 변화량 | SRE / Platform | 환경 안정성 추세 |
| Cost per Decision | release 판단 1회당 runner/infra/스토리지 비용 | Dev Productivity | 예산 관리 |
보고 계층 분리
팀 운영 대시보드
- 오늘 실패한 gate와 owner
- flaky / nondeterminism top 10
- quarantine 목록
- suite duration 변화
- evidence 누락 비율
리드 / 매니저 대시보드
- 주간 gate 안정성
- release blocker 빈도
- 서비스별 nondeterminism debt
- deflake backlog burn-down
경영 / 임원 요약
- 릴리즈 승인에 걸리는 평균 시간
- 테스트 환경이 사전 차단한 장애성 이슈 수
- 운영 비용과 변화 추이
실패 분류 체계
| 분류 | 의미 |
|---|---|
| Product Regression | 실제 제품 회귀 |
| Test Issue | locator, assertion, helper 문제 |
| Data Issue | seed, reset, 계정 충돌 |
| Infra Issue | runner, network, container, environment |
| External Dependency | sandbox, provider, quota 이슈 |
| Model Variance | agent / LLM 결과 분산 |
수집 파이프라인 예시
이 파이프라인에서 진짜 중요한 건 러너가 아니라 정규화 계층입니다.
같은 실패라도 gate, service, owner, classification, environment_fingerprint를 함께 저장해 둬야 운영 질문에 답할 수 있습니다.
정규화 이벤트 스키마
| 필드 | 의미 | 예시 |
|---|---|---|
run_id | 실행 단위 식별자 | gha-20260401-1832 |
gate | 어떤 gate에서 실행됐는지 | pr, main, release, canary |
probe_type | probe 성격 | browser, api, workflow, synthetic |
service | 소유 서비스 | payments-web |
runner | 사용 러너 | playwright, http-client, queue-harness |
final_status | 최종 결과 | passed, failed, flaky, skipped |
classification | 실패 분류 | product, test, data, infra, external, model |
retry_count | 재시도 횟수 | 1 |
duration_ms | 실행 시간 | 18432 |
owner | suite owner 또는 팀 | @payments-qa |
artifact_url | evidence 링크 | https://ci.example.com/runs/1832/report |
commit_sha | 코드 버전 | abc1234 |
environment | 실행 환경 | preview, integration, prod-like, canary |
environment_fingerprint | seed/flag/version 요약 | seed-v14|ff-a92|queue-3 |
started_at | 시작 시각 | 2026-04-01T02:11:10Z |
운영 액션 연결 규칙
main또는releasegate에서final_status=failed면 incident 채널에 즉시 알립니다.final_status=flaky가 3일 연속 누적되면 deflake 티켓을 자동 생성합니다.evidence completeness가 95% 아래로 떨어지면 reporter / retention 정책을 점검합니다.classification=infra비중이 급증하면 제품팀이 아니라 플랫폼팀이 먼저 triage합니다.
운영 팁
- pass rate 하나만 보고 건강도를 판단하지 마세요.
- flaky와 infra failure를 구분하지 않으면 엉뚱한 곳에 투자하게 됩니다.
- environment drift를 측정하지 않으면 "테스트는 안 바뀌었는데 왜 흔들리나"라는 질문에 답할 수 없습니다.