Cross Browser Testing
웹 프로젝트가 다양한 사용자들에게서 잘 작동하는지 확인하는 작업으로, 모든 브라우저와 기기에서 잘 작동하는 것은 거의 불가능하므로 개발자는 지원 범위를 결정해야 한다.
브라우저 지원 범위: 어떤 브라우저들을 어느 버전까지 지원할 것인가?
하드웨어 지원 범위: 데스크탑, 랩탑, 태블릿, 스마트폰, 스마트 TV 등 어떤 기기까지 지원할 것인가?
장애인 지원 범위: 스크린 리더나 키보드만을 사용하는 사용자를 얼마나 지원할 것인가?
지원 범위의 모든 브라우저나 디바이스에서 똑같은 사용자 경험을 제공할 필요는 없지만, 핵심 기능은 사용할 수 있어야 한다. 예를 들어, 최신 브라우저에서는 애니메이션, 3D, 반짝이는 콘텐츠를 표시하지만, 구형 브라우저에서는 동일한 정보를 평면 그래픽으로 표시한다.
크로스 브라우징 문제가 발생하는 이유
브라우저 버그 또는 기능 구현 차이
1990년대, IE와 넷스케이프 진영의 경쟁이 격화되면서 시장 주도권을 잡기 위해 의도적으로 호환성을 무시한 개발을 진행했다. 지금은 주요 벤더사들이 표준을 잘 지키는 개발을 하고 있지만 여전히 구현 세부 사항이 달라서 발생하는 오류나 차이가 있다.
브라우저의 기능 지원 범위 차이
최신 브라우저에서 지원하는 기능을 구형 브라우저에서는 지원하지 않는 경우가 있으며, 이런 경우 폴리필을 사용하여 해결한다.
디바이스의 차이
데스크탑 화면에 맞춰 제작된 웹사이트는 모바일 디바이스에서 보기 불편하다. 또한 기기의 사양에 따라 애니메이션 등 많은 연산이 필요한 경우 느리거나 끊김 현상이 발생할 수 있다.
크로스 브라우징 테스트 워크플로우
크로스 브라우징 테스트의 취지는 예상치 못한 문제를 발견하고 수정하는 것이다. 프로젝트 복잡도가 높아질수록 정기적으로 테스트를 수행하여 새로운 기능이 표적 고객에게 적합한지, 코드에 새로 추가된 기능이 이전에 작동하던 기능을 손상시키지 않는지 확인해야 한다. 테스트를 초기부터 수행하면 많은 비용과 시간을 절감할 수 있다.
경우에 따라 다를 수 있지만, 테스트는 일반적으로 다음 단계를 거친다.
Initial Planning > Development > Testing/Discovery > Fixes/Iteration
Initial Planning
초기 계획 단계에서는 사이트 소유자를 비롯한 관계자들이 모여 웹사이트의 정확한 형태를 결정한다. 콘텐츠, 기능, 디자인을 구체화하며 필요한 작업 시간과 마감일, 보수를 포함한 세부사항들을 결정한다.
필요한 기능과 구현에 필요한 기술을 결정하고 나면 이 사이트의 고객이 어떤 브라우저, 디바이스 등을 사용할지 표적 고객 탐색을 시작해야 한다. 클라이언트가 미리 확보한 사전 조사 결과를 기반으로 결정하되, 없는 경우 경쟁사나 서비스 국가의 사용 통계 같은 간접 정보와 직관을 활용한다.
가령, 북미 지역 고객에게 서비스를 제공하는 전자상거래 사이트를 구축하고 싶다면, 이 사이트는 가장 많이 사용되는 데스크톱 및 모바일(iOS, Android, Windows Phone) 브라우저의 최신 버전에서 모두 작동해야 하며, Chrome, Firefox, Edge, Safari를 포함해야 한다. 또한 WCAG AA를 준수하여 액세스할 수 있어야 합니다.
표적 테스트 플랫폼을 결정하고 나면, 필요한 기능과 기술을 재검토 해야 한다. 만약 사이트 제품 페이지에 WebGL 기반의 3D 제품 투어를 내장하고 싶다면, 구형 브라우저에서 작동하지 않는 다는 점을 받아들여야 한다.
Can I Use? 사이트를 활용하면 브라우저 지원 범위를 한눈에 확인 할 수 있다.
Development
개발 단계에서는 여러 기능을 모듈로 분할한다. 예를 들어, 홈페이지, 제품 페이지, 장바구니, 결제 워크플로 등으로 분할하고 공통 사이트 헤더나 푸터, 제품 페이지 세부 정보 보기, 장바구니 위젯 구현 등으로 세분화 할 수 있다.
크로스 브라우징 개발에는 일반적인 전략이 있으며 적절하게 조합하여 문제를 해결한다.
먼저 최대한 공통적으로 작동하는 기능의 코드를 작성하고, 브라우저마다 개별 대응하는 폴리필을 사용하거나, 브라우저의 지원에 따라 백그라운드에서 다른 작업을 수행하는 라이브러리를 사용한다
동작이 다른 브라우저에서는 대체 솔루션을 제공한다, 종종 화면 크기등 기기가 가진 한계 때문에 이런 방법을 필연적으로 택하는 경우도 있다
구형 브라우저를 사용하는 사용자를 포기한다
Testing/Discovery
각 기능마다 구현이 끝나면 테스트를 진행한다.
로컬 시스템에서 주요 브라우저들에서 기능 안정성을 확인한다
접근성 테스트를 통해 키보드, 스크린 리더 탐색의 안정성을 확인한다
모바일 플랫폼에서 작동 안정성을 확인한다
테스트를 통해 검출한 오류나 버그를 수정하고, 테스트를 반복한다.
이후 테스트 브라우저 목록을 확장하여 브라우저 간 문제를 제거하는 것에 집중한다
데스크톱 환경에서 최신 브라우저를 사용하여 기능 확인
주요 휴대전화 및 태블릿 브라우저에서 기능 확인
그외 지원 대상으로 결정한 브라우저에서 기능 확인
테스트를 진행할 때 다음 관점을 고려해야 한다
테스트 기기
실제 기기를 사용하는 것이 가장 간단하고 좋은 방법이지만, 여의치않다면 가상 기기를 활용하는 대안을 선택하는 것이 좋다
사용자 그룹
친구, 가족, 사내 타부서, 지역 대학교의 수업, 주민 등을 대상으로 테스트 할 수 있다. 돈을 지불하고 전문 사용자 테스트를 설정하는 방법도 있다
자동화
프로젝트 복잡도가 늘어날수록 수작업으로 진행하기 어렵기 때문에, 테스트 자동화 시스템을 구축하는 것을 권장한다(e.g. 셀레늄)
특정 이벤트가 발생하면 성공적으로 원하는 결과가 나오는지, 서로 다른 브라우저에서 스크린샷을 찍어 레이아웃이 일관되게 표시되는지 등을 확인할 수 있다
만약 예산이 충분하다면 Sauce Labs, BrowserStack 같은 서비스를 활용하는 것도 좋은 방법이다
이런 자동화 시스템은 코드 변경을 제출할 때마다 실행되도록 CI 설정을 권장한다
Last updated