통과와 실패만으로는 부족합니다: 14가지 판정이 결정되는 방식

테스트의 빨간색 표시는 애플리케이션에 문제가 있다는 뜻이어야 합니다. 하지만 DNS가 잠시 불안정하거나, 사이트에 CAPTCHA가 표시되거나, 브라우저가 종료된 경우에도 빨간색이 표시된다면, 팀은 결과를 살펴보는 대신 다시 실행하는 데 익숙해지고 실제 결함은 잡음 속에 묻힙니다. Nexus Studio는 모든 실행에 두 가지 대신 14가지 중 하나의 판정을 부여합니다. 이 페이지에서는 엔진이 판정을 선택하는 과정을 결정 순서에 따라 설명하고, 이 방식의 한계도 짚어봅니다.

작성: Nexus Studio 팀, Verdict System LLC. 2026년 10월 7일.

14가지 판정은 무엇인가요?

14가지 판정은 SECURE, CHAOS_RESILIENT, AUTO_RECOVER, FLAKY, PERFORMANCE_DEGRADED, A11Y_VIOLATION, SECURITY_VIOLATION, BREACHED, BREACHED_FLAKY, CHAOS_BREACHED, TIMEOUT, UNREACHABLE, BLOCKED 및 CRASHED입니다. 네 범주로 나뉩니다: 통과, 단서가 붙은 통과, 애플리케이션 오류, 환경이나 테스트 실행 체계의 문제로 인한 애플리케이션 판정 불가.

엔진은 어떻게 판정을 결정하나요?

엔진은 다음 순서로 세 가지 질문을 확인합니다:

1. 테스트에서 결과가 나오기는 했나요?
2. 통과했다면, 아무 문제 없이 통과했나요?
3. 실패했다면, 원인은 테스트 실행 체계, 환경, 애플리케이션 중 어디에 있나요?

버그 보고에 해당하는 답은 하나뿐입니다: 애플리케이션에서 비롯된 실패입니다. 나머지 답은 모두 다른 대상에 관한 정보이며, 그에 맞는 이름이 붙습니다.

어떤 경우에 테스트에 아무 판정도 내려지지 않나요?

세 가지 상태는 애플리케이션에 대해 아무것도 알려주지 않으므로 14가지 판정에 포함되지 않습니다: SKIPPED (테스트가 실행되지 않음), INTERRUPTED (Ctrl+C, --max-failures 제한 또는 전체 시간 제한으로 중단됨), CONFIG_ERROR (테스트 실행 체계가 테스트를 시작하지 못함). 이 상태에서는 증거 폴더도 기록 행도 생성되지 않습니다.

INTERRUPTED가 있는 데는 분명한 이유가 있습니다. 이 상태가 없을 때는 중단된 테스트가 통과 분기로 넘어가 SECURE로 기록되었습니다: 끝나지도 않은 테스트에 녹색 판정이 내려진 것입니다.

통과는 어떻게 등급을 매기나요?

• SECURE: 첫 시도에 통과했으며, 수정된 항목이 없습니다.
• AUTO_RECOVER: 통과했지만, 이 테스트에서 자동 복구 기능이 선택자를 교체해야 했습니다. 작성자가 지정한 위치 지정자는 더 이상 작동하지 않으며, 페이지가 다음에 변경되면 테스트 모음이 실제로 실패하게 되므로, 자동 복구를 거친 통과는 절대 정상 통과로 보고하지 않습니다. 원래 선택자를 수정하세요.
• FLAKY: 실패한 뒤 재시도에서 통과했으며, 자동 복구된 항목은 없습니다. 애플리케이션이나 테스트 어딘가가 불안정하며, 수정된 것은 없습니다.

예외가 하나 있습니다: 첫 시도가 시간 초과만으로 실패했고 재시도에서 통과했다면, 판정은 SECURE입니다. 이 통과 결과가 보여주는 것은 불안정성이 아니라 지연입니다.

실패에는 어떻게 판정을 부여하나요?

테스트가 실패하면 엔진은 해당 실행의 오류 메시지와 네트워크 로그를 읽고, 정해진 순서에 따라 여러 패턴 그룹과 대조합니다. 처음으로 일치하는 그룹이 판정을 결정하므로, 이 순서 자체가 설계의 일부입니다.

1. 먼저 CONFIG_ERROR: Cannot find module, ReferenceError 또는 SyntaxError, 누락된 환경 변수, 준비 단계에서 실패한 픽스처가 해당합니다. 테스트 실행 체계가 시작조차 되지 않았다면, 이후의 증상은 모두 그 결과입니다. 패턴은 의도적으로 좁게 설정되어 있으며, 테스트 코드나 그 환경에서만 발생할 수 있는 오류로 한정됩니다: CONFIG_ERROR가 하나라도 잘못 부여되면 애플리케이션의 실제 버그를 테스트 실행 체계 탓으로 돌리게 됩니다.
2. CRASHED: Target closed, Page crashed, DevTools 프로토콜 오류, SessionNotCreatedError, 유효하지 않은 세션 ID가 해당합니다. 브라우저나 드라이버가 종료된 것입니다. 인프라 문제이므로: 실행 장비와 드라이버를 확인하세요.
3. BLOCKED: 오류나 네트워크 로그의 403 또는 429, CAPTCHA, 접근 거부 페이지, 엔진이 화면에서 인식한 봇 확인 절차가 해당합니다. 사이트의 자체 방어로 요청이 제품에 도달하지 못한 것입니다.
4. UNREACHABLE: 페이지가 관찰되기도 전에 네트워크에서 연결이 거부된 경우입니다: 이름을 확인하지 못했거나 (Chromium의 net::ERR_NAME_NOT_RESOLVED, Firefox의 NS_ERROR_UNKNOWN_HOST, WebKit의 Could not resolve hostname), 연결이 거부되었거나, 실행 장비가 오프라인 상태였습니다. 인증서 오류는 여기에 해당하지 않습니다: 이는 발견된 문제로 취급합니다.
5. TIMEOUT: Playwright의 Timeout 30000ms exceeded, Selenium의 Wait timed out after, TimeoutError, 또는 Playwright가 시간 초과로 표시한 테스트가 해당합니다. 페이지 이동 중 시간이 초과되면 UNREACHABLE이 아니라 TIMEOUT입니다: 이동은 시작되었지만 페이지가 느렸던 것입니다.
6. BREACHED_FLAKY: 위의 어느 항목으로도 설명되지 않으며, 이미 재시도한 테스트입니다. 테스트가 실패했고, 실패 자체에도 일관성이 없습니다. 버그를 보고하기 전에 각 시도를 비교하세요.
7. BREACHED: 한 번의 시도에서 실패했으며, 위의 어느 항목으로도 설명되지 않습니다. 검증 조건을 충족하지 못했고, 환경이나 테스트 실행 체계의 어떤 패턴으로도 오류를 설명할 수 없습니다. 이것이 버그 보고에 해당합니다.

각 그룹은 Playwright와 Selenium WebDriver의 표현을 모두 다룹니다. Selenium 패턴이 도입되기 전에는 WebDriver의 TimeoutError와 오래된 chromedriver의 SessionNotCreatedError가 모두 애플리케이션 결함인 것처럼 BREACHED로 보고되었습니다.

절전 상태이거나 잠겨 있어 실행에 사용할 수 없는 실제 Android 휴대전화도 BLOCKED로 판정됩니다: 제품 오류가 아니라 사전 조건 미충족이기 때문입니다. 이 규칙은 실제 측정 사례에서 나왔습니다. 캠페인 도중 휴대전화가 절전 상태로 전환되자, 네 번 연속 통과했던 로그인 테스트가 심각한 실패를 뜻하는 빨간색으로 표시되었습니다.

카오스 실행은 어떻게 판정하나요?

실행 중 Chaos Lab의 결함을 주입하면 판정은 다른 질문에 답합니다: 애플리케이션이 견뎌냈는가? 통과 판정인 SECURE 또는 AUTO_RECOVER는 CHAOS_RESILIENT가 됩니다. 그 외에는 모두 CHAOS_BREACHED가 되며, FLAKY 통과와 TIMEOUT도 여기에 포함됩니다. 결함이 주입된 상황에서는 이들 자체가 그 영향이기 때문입니다. SKIPPED, INTERRUPTED 및 CONFIG_ERROR는 그대로 유지됩니다: 실행되지 않은 테스트로는 복원력을 판단할 수 없습니다.

어떤 엄격 검사가 통과 판정을 바꿀 수 있나요?

검증문과 함께 세 가지 검사가 실행됩니다: 보안 헤더, axe-core를 이용한 접근성, Web Vitals 및 지연 로딩의 성능 허용 기준입니다. 이 검사들은 실행할 때마다 발견 사항을 기록합니다. 설정에서 엄격 모드로 지정한 경우에만 판정을 바꿉니다. 기존 애플리케이션에서는 어느 검사든 첫날부터 전체 테스트 모음을 빨간색으로 만들 수 있으며, 항상 빨간색인 테스트 모음은 아무도 살펴보지 않습니다.

엄격 모드에서는 통과한 테스트에만 다음 순서로 적용됩니다: SECURITY_VIOLATION, A11Y_VIOLATION, PERFORMANCE_DEGRADED. 보안이 우선인 이유는 셋 중 불만이 아니라 사고로 이어질 수 있는 항목이기 때문입니다. 실패한 테스트에는 추가 판정을 적용하지 않습니다: BREACHED가 이미 더 심각한 문제를 나타내며, 그 위에 주의 사항을 덧붙이면 발견된 문제를 가릴 수 있기 때문입니다.

CI에는 무엇이 전달되나요?

일곱 가지 통과 판정은 종료 코드 0을 반환합니다: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION 및 SECURITY_VIOLATION입니다. 유의 사항은 빌드 실패가 아니라 보고서와 이력에 표시됩니다. 나머지 일곱 가지 판정은 종료 코드 1을 반환합니다. pytest 및 Selenium 실행기는 실행을 아예 시작할 수 없을 때 종료 코드 2를 반환합니다. 예를 들어 Python이 없거나 엔진에 해당 브라우저용 드라이버가 없는 경우입니다.

이 방식에는 어떤 한계가 있나요?

• 분류는 오류 문구를 읽어 이루어집니다. 직접 작성한 메시지에 403, Forbidden 또는 Access Denied가 포함되어 있으면 BLOCKED로, 오류에 is not a function이 포함되어 있으면 CONFIG_ERROR로 해석됩니다. 사용자 지정 검증 메시지는 구체적으로 작성하고, 예상 밖의 판정이 나오면 metadata.json을 열어 보세요.
• TIMEOUT은 애플리케이션이 정상 작동한다는 증거가 아닙니다. 해당 실행으로는 판단할 수 없다는 뜻입니다. 실행할 때마다 시간 초과가 발생하는 테스트는 살펴볼 필요가 있습니다.
• FLAKY와 SECURE, BREACHED_FLAKY와 BREACHED를 구분하는 기준은 재시도입니다. 재시도를 끄면 간헐적인 실패도 BREACHED로 판정됩니다.
• API 테스트에는 다른 규칙으로 결정되는 일곱 가지 고유 판정이 있습니다: API 테스트를 참고하세요.

실제 실패에 대한 판정은 어디에서 볼 수 있나요?

증거 페이지에서는 실패한 테스트 하나를 추적하며 각 판정이 디스크에 남기는 모든 파일을 나열합니다: report.md, metadata.json, raw-data.json, 스크린샷, 그리고 실제 실패인 경우에는 동영상입니다. 30일 체험판에서는 동일한 엔진으로 직접 작성한 테스트를 실행할 수 있습니다.