개념
조합 폭발(Combinatorial Explosion)의 현실
브라우저(Chrome, Safari, Firefox, Edge) × OS(Windows, macOS, Linux) × 모바일 기기(수십 종의 화면 크기·OS 버전)를 모두 곱하면 수백 가지 조합이 나온다. 모듈 3(레슨 5)에서 배운 페어와이즈 테스팅이 여기서도 그대로 적용되는 문제 상황이다 — 모든 조합을 다 테스트할 수는 없다.
사용자 데이터로 우선순위 정하기
모듈 4(레슨 2)에서 배운 위험기반 테스트 원칙을 그대로 적용한다. "어떤 브라우저·기기 조합이 실제 리스크가 큰가"는 감이 아니라 실제 사용자 통계로 판단해야 한다.
실제 방문자 브라우저 비율(예시):
Chrome 65%, Safari 20%, Edge 10%, Firefox 5%
→ Chrome·Safari를 최우선으로, Edge는 핵심 흐름만, Firefox는
최소한만(또는 커버하지 않음)으로 결정이 데이터 없이 "모든 브라우저를 똑같이 중요하게" 다루면, 리소스가 분산되어 정작 사용자가 가장 많은 브라우저의 검증이 얕아질 수 있다.
계층별로 커버리지를 다르게 가져가기
모든 테스트를 모든 조합에서 돌릴 필요는 없다 — 레슨 1에서 배운 "핵심 흐름"과 "그 외 기능"을 구분해서 커버리지 깊이를 다르게 가져간다.
핵심 흐름(로그인, 결제): 주요 브라우저·기기 전체에서 실행
일반 기능: 대표 브라우저(예: Chrome) 하나에서만 실행이건 모듈 11(레슨 2)에서 배운 "무엇을 자동화할지" 판단 기준을, "어디까지 확장해서 자동화할지"로 한 단계 더 적용한 것이다.
병렬 실행으로 시간 관리하기
브라우저·기기 조합이 늘어날수록 전체 실행 시간이 길어진다. 여러 조합을 동시에(병렬로) 실행하면 전체 소요 시간을 줄일 수 있다 — 다만 모듈 7(레슨 2)에서 배운 테스트 데이터 격리가 병렬 실행에서 특히 중요해진다. 여러 테스트가 동시에 같은 데이터를 건드리면 레슨 6에서 배운 플래키 테스트의 새로운 원인이 된다.
클라우드 디바이스 팜(Device Farm)
모든 브라우저·기기 조합을 회사가 직접 갖추기는 현실적으로 어렵다. 클라우드 서비스(BrowserStack, Sauce Labs 등)를 통해 다양한 실기기·브라우저 환경을 필요할 때만 빌려 쓰는 방식이 실무에서 널리 쓰인다 — 이건 모듈 11(레슨 3)에서 배운 ROI 계산의 관점에서, 자체 기기를 다 갖추는 것보다 훨씬 합리적인 경우가 많다.
이 모듈 전체를 종합하기
이 마지막 레슨은 모듈 13의 모든 레슨을 하나로 묶는다 — 왜 UI 자동화가 필요한지 판단하고(레슨 1), Playwright로 짜고(레슨 2), 깨지지 않는 로케이터(레슨 3)와 POM 구조(레슨 4)로 유지보수 가능하게 만들고, 올바른 대기 전략(레슨 5)으로 안정성을 확보하고, 그래도 생기는 플래키를 체계적으로 진단하고(레슨 6), 모바일까지 확장하고(레슨 7), 마지막으로 이 모든 걸 어디까지, 어떤 우선순위로 커버할지 전략적으로 결정하는 것까지가 "오래가는 UI 자동화"의 완결된 그림이다.
실무에서 왜 필요한가
"우리 서비스는 모든 브라우저에서 완벽해야 한다"는 목표는 현실적인 자동화 전략이 아니다. 실제 사용자 데이터를 근거로 "이 조합까지는 꼭 커버하고, 이건 리스크를 감수한다"는 판단을 명시적으로 내리는 QA는, 제한된 리소스로 가장 효과적인 커버리지를 만들 수 있다 — 이건 모듈 11(레슨 5)에서 배운 자동화 전략 수립의 마지막 조각이다.
실습 과제
과제 1 — 우선순위 매트릭스 만들기 (10분)
가상의 사용자 브라우저 비율(Chrome 70%, Safari 15%, Edge 10%, Firefox 5%)이 주어졌을 때, 어느 브라우저까지 자동화 스위트에 포함시킬지 결정하고 이유를 적는다.
과제 2 — 계층별 커버리지 설계하기 (10분)
"로그인", "상품 검색", "결제" 세 기능 중 크로스 브라우저 테스트를 가장 폭넓게 적용해야 할 기능과, 대표 브라우저 하나로 충분한 기능을 구분하고 이유를 설명한다.
자가 체크리스트
- 모든 브라우저·기기 조합을 다 테스트할 수 없는 이유(조합 폭발)를 설명할 수 있다
- 실제 사용자 데이터를 근거로 크로스 브라우저 우선순위를 정할 수 있다
- 핵심 흐름과 일반 기능의 커버리지 깊이를 다르게 가져가는 이유를 설명할 수 있다
- 클라우드 디바이스 팜이 왜 ROI 관점에서 합리적인 선택이 되는지 설명할 수 있다
흔한 실수
- 모든 브라우저·기기를 똑같이 중요하게 취급한다. 리소스가 분산돼 정작 사용자가 많은 환경의 검증이 얕아질 수 있다.
- 실제 사용자 통계 없이 감으로 우선순위를 정한다. 데이터 기반 판단이 근거 있는 자동화 전략의 핵심이다.
- 병렬 실행을 도입하면서 테스트 데이터 격리를 함께 점검하지 않는다. 병렬 실행 자체가 새로운 플래키 원인이 될 수 있다.
참고 자료
- BrowserStack — Cross Browser Testing 가이드 — 크로스 브라우저 전략 수립의 실무 가이드
- Playwright 공식 문서 — Test Parallelism — 병렬 실행 설정의 공식 가이드