브라우저 테스트가 실패했습니다. 실제로는 왜 그랬을까요?

출처: Dev.to

CI에서 빨간 테스트는 정확하게 보입니다.
무언가 실패했습니다. 파이프라인이 멈췄습니다. 스크린샷, 스택 트레이스, 그리고 perhaps 비디오가 있습니다.

하지만 누군가가 스크린샷을 열면 로딩 스피너를 보게 됩니다. 트레이스에는 로케이터가 발견되지 않았다고 나와 있습니다. 동일한 테스트는 로컬에서는 성공합니다. 작업을 다시 실행하면 녹색으로 변합니다.

이 시점에서 팀은 실제 실패한 테스트가 아니라 미해결 이벤트를 가지고 있습니다.
이 구분은 몇 년 전보다 지금 더 중요합니다. 브라우저 애플리케이션은 더욱 동적이며, CI 환경은 일회성이고, 테스트 스위트는 점점 AI 생성 단계, 검증문, 로케이터, 수정 제안을 포함하게 됩니다.

새로운 테스트를 만드는 것은 쉽지만, 그 결과가 릴리즈를 차단해야 할지 판단하는 것은 어렵습니다.
브라우저 테스트 시스템의 품질은 통과율이나 실행 속도만으로 측정될 것이 아니라, 문제가 발생했을 때 제공하는 증거에도 달려야 합니다.

이 문서는 팀이 실제로 그 증거를 신뢰할 수 있게 하는 요소를 살펴봅니다.
팀은 보통 브라우저 테스트를 하나의 지표에 최적화합니다: 실행 시간입니다.
그 말이 맞습니다. 세 시간이 걸리는 회귀 스위트는 결국 무시될 것이거나 야간 스케줄로 옮겨지거나 릴리즈 경로에서 제외될 것입니다.

속도만으로는 충분하지 않습니다.
스물 분짜의 스위트가 모호한 실패를 만든다면, 정확한 진단을 제공하는 서른 분짜 스위트보다 엔지니어링 시간 낭비가 더 클 수 있습니다.
실제 피드백 루프는 실행과 조사를 모두 포함합니다:

• 테스트가 얼마나 빨리 실패했나요?
• 누가 실수를 이해하는 데 걸리는 시간은 얼마나 되나요?
• 팀이 제품, 테스트, 데이터, 혹은 환경 중 무엇이 책임인지 빠르게 판단할 수 있었는가?

빠른 실패 증거가 필요한 팀을 위한 최고의 브라우저 테스트 도구 개요는 좋은 출발점이 됩니다. 중요한 문구는 단순히 “빠른 브라우저 테스트”가 아니라 “빠른 실패 증거”입니다.

좋은 증거로는 다음이 포함될 수 있습니다:

• 실제 실패 지점에서 촬영한 스크린샷
• 그 시점의 DOM 또는 접근성 상태
• 브라우저 콘솔 오류
• 네트워크 요청 및 응답
• 단계별 타이밍
• 이전 성공한 시도
• 명확한 타임라인을 가진 비디오
• 시도된 로케이터 전략
• 환경 및 브라우저 메타데이터
• 테스트 실행과 연동된 애플리케이션 로그

그_context가 없으면 실패는 추측 게임이 되기 쉽습니다.
실패한 브라우저 테스트는 보통 즉시 제품이 변경됐다는 가정으로 이어집니다.

하지만 자동화된 테스트 실행에서는 최소 세 개의 움직이는 시스템이 존재합니다:

• 애플리케이션
• 테스트 또는 AI 에이전트
• 실행 환경

애플리케이션은 레이아웃, 텍스트, 타이밍, API 동작, 혹은 인증 흐름을 바꿀 수 있습니다.
테스트는 누군가가 직접 편집했거나, AI 시스템이 일부를 재생성하거나, 자체 치유 메커니즘이 새로운 로케이터를 선택하거나, 의존성이 런타임 동작을 바꾸면서 바뀔 수 있습니다.
환경은 브라우저 업데이트, 캐시 복원, 컨테이너 이미지, 로컬 설정, 타임존, 네트워크 정책, 패키지 버전, 혹은 머신 용량 때문에 바뀔 수 있습니다.

그래서 AI 테스트 드리프트와 UI 드리프트 사이의 구분이 매우 유용합니다.
AI 에이전트가 변경되지 않은 인터페이스에서 다른 결정을 내린다면那是 UI 드리프트가 아니라 에이전트 드리프트입니다.
그 차이는 증거에 명시되어야 합니다. 팀은 다음과 같은 것을 알아야 합니다:

• 사용된 프롬프트 또는 지시문
• 해당 단계를 수행한 모델과 모델 버전
• 모델이 받은 페이지 상태
• 모델이 선택한 동작
• 이전 동일한 입력이 다른 결과를 냈는지 여부
• fallback 혹은 복구 메커니즘이 작동했는지 여부

그 어떤 것도 기록되지 않으면 AI 기반 실패는 재현하기 어렵습니다.

AI 코딩 도구는 인터페이스 변경을 빠르게 생성할 수 있습니다. 개발자는 리디자인된 폼, 새로운 결제 구성 요소, 혹은 반응형 네비게이션 시스템을 요청하고 몇 분 안에 대규모 패치를 받을 수 있습니다.
그 속도를 자동 승인과 동일하게 맞추려는 유혹이 있습니다.

하지만 생성된 코드는 미묘한 문제를 일으킬 수 있습니다:

• 검증 로직은 형태는 올바르게 보이면서도 바뀔 수 있습니다
• 세맨틱 라벨이 사라질 수 있습니다
• 로딩 상태가 생략될 수 있습니다
• 오류 메시지가 실패와 더 이상 일치하지 않을 수 있습니다
• 모바일 동작이 불완전할 수 있습니다
• 인증 상태가 잘못 처리될 수 있습니다
• 기존 분석 또는 접근성 속성이 제거될 수 있습니다

팀은 AI 생성 UI 변경에 대한 테스트 증거를 평가하는 실용적인 방법을 찾고, 릴리즈 결정을 늦추지 않아야 합니다.
수동으로 AI가 만든 모든 것을 검사하는 것이 목표가 아니라, 위험 수준에 따라 필요한 증거를 결정하는 것이 목표입니다.

작은 텍스트 변경은 시각적 확인과 몇 개의 타깃 어서션만 필요할 수 있습니다.
생성된 결제 흐름 변경은 다음과 같은 것이 필요할 수 있습니다:

• 기능 브라우저 테스트
• 네트워크 응답 검증
• 접근성 검사
• 다중 브라우저 커버리지
• 음의 시나리오
• 세션 만료 동작
• 중요한 어서션이 실제로 달성됐다는 증거

릴리즈 프로세스는 보편적으로 느려질 것이 아니라 비례적으로 빨라져야 합니다.

많은 브라우저 테스트 데모는 클릭, 텍스트 입력, 간단한 네비게이션에 집중합니다.
그것은 필요하지만, 도구의 한계를 보통 드러내는 상호작용은 아닙니다.

드래그 앤 드롭 보드, 캔버스 편집기, 타임라인 구성 요소, 지도 인터페이스, 파일 드롭존은 훨씬 더 rivelatory합니다.
드래그 동작은 포인터 좌표, 스크롤, 요소 기하학, 브라우저 이벤트, 애니메이션 상태, 드롭존 활성화 등에 의존할 수 있습니다.
테스트가 제스처를 올바르게 수행한 것처럼 보여도 애플리케이션이 이를 거절할 수 있습니다.

드래그 앤 드롭 보드, 캔버스 상호작용, 드롭존 엣지 케이스를 테스트하는 가이드는 심각한 평가를 위한 필요한 시나리오들을 다룹니다.
이 워크플로우는 화면 캡처만으로는 충분하지 않다는 것을 보여줍니다.

스크린샷은 카드가 다른 열에 놓였다는 것만을 보일 뿐이며,

• 정확한 백엔드 업데이트가 발생했는지
• 키보드 접근성 경로가 여전히 작동하는지
• 드롭 이벤트가 한 번 발생했는지
• 작업이 페이지 새로고침 후 유지됐는지
• 항목이 예상 인덱스로 이동했는지
• 애플리케이션이 무효 드롭존을 거절한지

복잡한 브라우저 상호작용에서는 증거가 시각적 요소와 상태 모두를 포괄해야 합니다.

개발자 노트북에서 실행되는 브라우저 테스트는 누적된 상태의 이점을 얻습니다.
의존성은 이미 설치되어 있습니다. 브라우저 바이너리는 존재합니다. 폰트는 캐시되어 있으며, 머신은 충분한 메모리를 가지고 있습니다.
개발자는 이전 실행에서 남은 인증 상태를 가질 수도 있습니다.

임시 CI 작업은 훨씬 더 제어된 환경에서 시작하지만, 다른 리스크도 도입합니다.

컨테이너 또는 가상 머신에는 다음이 포함될 수 있습니다:

• 다양한 CPU 가용성
• 다른 폰트
• 다른 타임존 또는 로컬 설정
• 브라우저 차가운 시작
• 운영체제 패키지 누락
• 복원된 의존성 캐시
• 다양한 네트워크 지연
• 계속된 인증 상태 없음
• 공유 메모리 감소
• 예상보다 새로운 브라우저 이미지

이러한 실행을 권위적으로 받아들이기 전에, 임시 CI 환경에서 브라우저 테스트를 신뢰하기 전에 확인해야 할 사항을 검토하는 것이 가치가 있습니다.

신뢰할 만한 결과는它이 생성한 환경을 식별해야 합니다. “Chrome on Linux”만으로는 충분하지 않습니다.
정확한 브라우저 버전, 운영체제 이미지, 의존성 잠금 파일, 테스트 런너 버전, 관련 환경 변수, 뷰포트, 로컬 설정, 타임존을 기록하세요.

그 세부 정보를 갖추지 않으면 CI 전용 실패를 재현하는 것이 불필요하게 어렵습니다.
캐싱은 CI를 빠르게 만들 목적이지만, 실행 간에 혼동스러운 차이를 만들 수도 있습니다.

변경된 캐시 키는 다른 의존성 트리, 브라우저 바이너리, 패키지 관리자 상태, 또는 생성된 자산을 복원할 수 있습니다.
손상되거나 오래된 캐시는 깨끗한 실행 후에 사라지는 실패를 만들 수 있습니다.

GitHub Actions 캐싱 변경 후 로컬에서는 정상 동작하던 Playwright 테스트가 즉시 실패하는 것은 특히 답답합니다.
GitHub Actions 캐싱 변경 후 로컬에서는 정상 동작하던 Playwright 테스트를 디버깅하는 실용적인 시퀀스는 캐시를 실행 환경의 일부로 취급한다는 점을 강조합니다.