자동화 실패 분석·격리·복귀 운영 양식

테스트를 다시 돌려 통과했다고 해서 처음 실패한 이유가 사라지지는 않습니다. 실행 순서나 데이터가 바뀌었거나 첫 실행이 남긴 상태 때문에 결과가 달라졌을 수 있습니다. 최초 실패와 재실행을 같은 사건 번호로 연결하고 코드·테스트 리비전, 환경, 사전 데이터와 기대 결과를 함께 적습니다. 제품 버전이 같아도 다른 계정이나 초기화된 데이터에서 실행했다면 그 차이가 조사 근거가 됩니다.

실행 결과와 조사 상태, 자산의 사용 상태는 구분합니다. PASS·FAIL·BLOCKED·NOT RUN은 시나리오 실행 기록에 쓰고 접수·조사·조치·검토는 실패 사건의 진행을 나타냅니다. 격리는 자동화 자산을 어느 실행에서 분리했는지 적는 별도 결정입니다. 도구의 상태 이름도 그대로 해석해야 합니다. Playwright 재시도 문서는 최초 실행에서 통과한 테스트와 재시도 후 통과한 테스트를 구분합니다. 이 도구 상태를 제품 결함 수나 출시 판정으로 바로 옮기지 않습니다.

실패를 분류할 때는 합의한 요구, 테스트가 기대한 값, 제품의 실제 동작을 먼저 대조합니다. 요구가 맞고 제품 동작이 다르면 제품 결함을 조사합니다. 제품이 요구대로 동작하는데 테스트의 기대값이나 선택자, 관찰 시점이 틀렸다면 테스트 수정이 필요합니다. 공유 데이터가 덮였거나 실행 환경이 달랐다면 해당 조건을 통제해 다시 확인합니다. 로그의 마지막 문구가 시간 초과라는 이유만으로 환경 문제라고 확정하지 않습니다.

원인 조사표에는 사건 번호와 가설, 확인하거나 배제한 근거, 다음 조사, 담당과 확인일을 남깁니다. 한 번에 제품·테스트·데이터를 모두 바꾸면 무엇이 원인을 해결했는지 읽기 어려워집니다. 가능한 범위에서 조건을 나눠 바꾸고 전후 결과를 연결합니다. 아직 원인을 확정하지 못했다면 미확정으로 둡니다. Playwright의 테스트 독립성과 데이터 제어 지침은 준비 조건을 점검할 때 참고할 수 있습니다.

이 자료의 완성 예제는 IXC가 작성용으로 실행한 로컬 Node.js 합성 시험입니다. 원인을 의도적으로 넣은 작은 함수와 데이터 순서에서 결과를 비교했습니다. 고객 소프트웨어, 브라우저 또는 운영 CI를 시험한 것이 아니며 실제 실패 빈도를 측정한 결과도 아닙니다.

F-PRODUCT에서는 읽기 역할에 편집을 허용한 제품 로직이 실패 원인이었습니다. 같은 입력과 기대값으로 실패를 다시 확인한 뒤 제품의 역할 조건을 수정했습니다. F-DATA에서는 A와 B의 준비 작업이 같은 문서 키를 써 B가 A의 소유자를 덮었습니다. 깨끗한 데이터의 재시도는 통과했지만 A쓰기·B쓰기·A조회 순서를 반복하면 다시 실패했습니다. 실행별 키로 분리한 뒤 같은 순서를 확인했습니다. 이는 통제한 실행 순서의 예이며 실제 병렬 스케줄러 검증이 아닙니다.

F-TEST에서는 활성 레코드만 세는 요구에 테스트가 전체 레코드 수를 기대하고 있었습니다. 활성 두 건과 비활성 한 건이라는 데이터와 요구를 대조한 뒤 제품은 그대로 두고 기대값만 수정했습니다. 세 사건은 각각 수정 뒤 세 번 통과를 확인했습니다. 이 횟수는 자체 예제의 기록이며 모든 자동화 자산의 안정성 기준이 아닙니다. 실무 기록에는 수정된 코드나 데이터 준비 규칙, 바뀐 기대값의 이유까지 남겨야 합니다.

격리할 때는 대상 테스트와 사건 번호, 빠지는 실행 단계, 격리 이유, 출시 영향과 다음 검토일을 적습니다. 임시로 수동 검증을 한다면 누가 어떤 데이터로 언제 실행할지 정합니다. 다른 계층의 테스트로 대체한다면 원래 시나리오의 어떤 부분까지 확인하는지 남깁니다. 대체 수단이 없으면 미검증 범위로 출시 담당자에게 전달합니다. 격리된 테스트는 실행하지 않은 검증을 통과한 것처럼 계산하지 않습니다.

예를 들어 공유 데이터 충돌을 조사하는 동안 독립 데이터로 핵심 동작을 확인할 수 있습니다. 다만 그 결과로 전체 병렬 실행이 안정됐다고 말할 수는 없습니다. 대체 확인의 실행 번호와 남은 조건을 함께 기록합니다. 격리 수만 줄이는 목표는 테스트 삭제로 달성될 수 있으므로 경과 기간과 대체 검증 여부, 미해결 위험까지 검토합니다. 자동화에서 제외하기로 했다면 해당 검증을 사람이 계속 맡을지도 결정해야 합니다.

복귀 기록에는 원인 근거, 수정 번호, 재검증 조건, 실행 결과, 남은 한계와 검토 담당을 연결합니다. 제품을 수정했다면 같은 테스트가 유지됐는지, 테스트를 수정했다면 요구를 덜 확인하도록 바뀌지 않았는지 봅니다. 기대값을 실제 결과에 맞추기만 하면 신호를 없애고 통과 표시만 남길 수 있습니다. F-TEST의 수정은 결과가 두 건이어서가 아니라 합의한 요구가 활성 건수를 세도록 정했기 때문에 타당합니다.

필요한 반복 횟수와 환경은 제품 위험, 데이터와 실행 변동을 보고 합의합니다. 원래 실패를 만든 순서나 조건을 빼고 횟수만 채우면 복귀 근거가 부족합니다. 자산을 다시 사용한 뒤 같은 증상이 나타났을 때의 담당과 기록 위치도 인계합니다. 자동화 자산의 복귀와 출시 승인은 별도로 다루고 출시 회의에는 해당 빌드에서 실제 수행한 결과와 미검증 영역을 전달합니다.

월간 검토에서는 최초 실패 건수와 재실행, 원인 조사 시간, 스크립트 수정 시간, 환경·데이터 준비 시간을 구분합니다. 같은 관측 기간으로 맞춰야 실행량 변화와 유지 작업의 변화를 읽을 수 있습니다. 재시도 후 통과율이 올랐다는 이유만으로 제품 품질이 좋아졌거나 비용이 줄었다고 단정하지 않습니다. 어떤 자산을 자동화에 남길지는 테스트 자동화 포트폴리오에서 다루고, 이번 결과를 출시 근거로 넘길 때는 릴리스 판정 메모·시나리오 결과표를 연결합니다.

제공하는 PDF와 작성용 Excel은 한국어판입니다. 실패 사건 기본 기록, 원인 조사, 격리·대체 검증, 복귀 검토와 유지 작업을 같은 사건 번호로 이어 작성합니다. 대표 실행 로그와 환경·데이터 준비 방식, 현재 유지 담당을 정리하면 IXC의 테스트 자동화 서비스에서 조사와 수정·인계 범위를 구체적으로 상담할 수 있습니다.