테스트 실패는 어떻게 운영 데이터가 되는가
데브옵스
테스트 실패는 어떻게 운영 데이터가 되는가
두줄요약
모바일 E2E 실패를 AI 후보 분류와 근거 검증으로 안전하게 운영하는 흐름을 소개했습니다. 실행·케이스 이력을 분리해 반복 실패와 품질 지표를 신뢰성 있게 분석합니다.
문제 상황
- 모바일 E2E 실패 후 원인 분류, 담당자 지정, 후속 조치를 사람이 반복 판단하는 운영 부담
- 리포트 링크와 실패 메시지만으로 제품·테스트 코드·인프라 문제 구분의 어려움
구조와 흐름
- GitHub Actions 결과 payload를 기반으로 즉시 알림, 실패 분류·검증, 실행·케이스 이력 적재, Daily QA Report로 분리
- test_run의 전체 품질 지표와 test_case/test_history의 반복 실패 이력 분리 저장
- Slack의 즉시 확인, Notion의 운영 기록, InfluxDB의 시간 기반 집계 역할 분담
트레이드오프
- AI를 최종 판정자가 아닌 원인 후보 생성기로 제한하고 SSR HTML·FE 소스 검증 단계 추가
- confidence, 허용 파일, 안전한 subtype, 변경 근거를 모두 충족할 때만 Appium PR 후보 생성
- 근거 부족 시 자동 변경 대신 Issue와 사람 검토로 폴백
성능/운영 포인트
- run ID, 리포트 시각, 테스트 합계, 플랫폼 정규화, 인프라 오류 분리로 지표 왜곡 방지
- FE 수정 뒤 selector 교체·skip 해제·재실행 확인까지 포함한 테스트 커버리지 복구 관리
- 최근 24시간 실행 지표와 최근 7일 반복 실패를 분리해 Daily QA Report 구성
