개념
기능은 맞는데 화면이 깨지는 경우
모듈 13에서 배운 로케이터 기반 자동화는 "버튼이 존재하고 클릭된다"는 것을 확인하지만, 그 버튼이 다른 요소와 겹쳐 보이거나, 레이아웃이 깨져서 이상하게 보이는지는 확인하지 못한다. 코드 관점에서는 "정상"이지만, 사람 눈에는 "이상해 보이는" 경우다.
시각적 회귀 테스트(Visual Regression Testing)
이전 버전과 현재 버전의 화면 스크린샷을 자동으로 비교해서, 의도치 않은 시각적 변화가 있는지 찾아내는 방법이다.
1. 기준(Baseline) 스크린샷을 미리 저장해둔다
2. 배포 후 같은 화면의 스크린샷을 다시 찍는다
3. 두 이미지를 픽셀 단위로 비교해 차이를 표시한다
4. 차이가 발견되면 "의도한 변경인지, 결함인지" 사람이 판단한다이건 모듈 10(레슨 1)에서 배운 어서션(Assertion)의 개념을 시각적 영역으로 확장한 것이다 — "이 값이 저 값과 같아야 한다"는 어서션 대신, "이 화면이 저 화면과 (거의) 같아야 한다"는 시각적 어서션을 쓰는 것이다.
의도한 변경과 결함을 구분하기
시각적 회귀 테스트의 까다로운 지점은, 모든 픽셀 차이가 결함은 아니라는 것이다.
결함일 가능성이 높은 차이: 버튼이 다른 요소와 겹침, 텍스트가 잘림
의도한 변경일 가능성이 높은 차이: 디자인 팀이 의도적으로 색상을 바꿈이 판단은 자동화 도구가 대신할 수 없다 — 차이가 감지되면 사람이 스크린샷을 직접 보고 "이건 버그다" 또는 "이건 이번 스프린트에 의도한 디자인 변경이다"를 판정해야 한다. 판정 후에는 새 스크린샷을 새로운 기준(Baseline)으로 갱신한다.
시각적 회귀 테스트의 함정 — 사소한 차이의 소음
폰트 렌더링의 미세한 차이, 애니메이션 타이밍처럼 실제로는 문제가 아닌 사소한 차이도 종종 "다르다"고 잡힌다. 이건 모듈 14(레슨 5)에서 배운 False Alarm과 정확히 같은 문제다 — 소음이 계속되면 팀이 시각적 회귀 알림 자체를 무시하게 된다. 허용 오차(threshold)를 적절히 설정해 사소한 차이는 걸러내는 것이 실무에서 중요하다.
호환성 테스트(Compatibility Testing)
모듈 13(레슨 8)에서 이미 다룬 크로스 브라우저·디바이스 전략이 바로 호환성 테스트의 핵심이다. 이 레슨에서는 그 원칙을 시각적 관점까지 확장한다 — 같은 화면이 Chrome에서는 정상인데 Safari에서는 레이아웃이 깨지는 경우가 실무에서 드물지 않다.
기능 호환성: 이 브라우저에서도 버튼이 눌리고 동작하는가 (모듈 13)
시각적 호환성: 이 브라우저에서도 화면이 의도한 대로 보이는가 (이 레슨)시각적 회귀 테스트를 여러 브라우저·화면 크기에서 동시에 돌리면, "어느 환경에서만 시각적으로 깨지는지"까지 자동으로 잡아낼 수 있다.
이 모듈 전체를 종합하기
이 마지막 레슨은 모듈 16의 다섯 축을 하나로 묶는다 — 성능(레슨
24)이 "빠른가", 보안(레슨 56)이 "안전한가", 접근성(레슨 7)이
"누구나 쓸 수 있는가"를 물었다면, 시각적 정확성과 호환성(이
레슨)은 **"의도한 대로, 모든 곳에서 보이는가"**를 묻는다. 다섯
축 모두 "기능은 맞다"는 것만으로는 답할 수 없는 질문들이었다는
공통점이 있다.
실무에서 왜 필요한가
"이번 배포 후 결제 버튼이 다른 요소에 가려 안 보인다"는 문제는, 기능 테스트로는 절대 못 잡는다(버튼은 여전히 존재하고 클릭도 된다 — 코드 관점에서는 "정상"이다). 시각적 회귀 테스트를 CI(모듈 14)에 포함시켜 두면, 이런 시각적 결함을 배포 직후가 아니라 배포 전에 잡아낼 수 있다.