Selenium Testing at the Speed of headless
Sauce labs에서 실제 경험했던 문제를 Headless browser testing으로 해결한 사례를 공유한 세션이었습니다. 문제들은 다음과 같았다고 합니다.
- End2End 테스트 결과를 Pipeline 단계안에서 일찍 피드백을 받을 수 있다면 개발 속도를 향상시킬수 있을 것 같다
- 기존 End2End 테스트나 CI/CD 내에서의 테스트는 비용이 크다
- End2End 테스트를 가볍게 돌려볼 수 없을까?
초기 선택은 기존 Pipeline에서 End2End 테스트를 그대로 개발 직후에 수행할 수 있도록 환경을 구성해주는 것이었습니다. 하지만 다음과 같은 이유로 중단하게 됩니다.
- 개발자들이 End2End 테스트에 사용되는 언어와 친숙하지 않아 부담
- QA팀과의 리소스 공유가 필요한데, 이것이 병목 현상을 일으킴
- Pipeline의 Infrastructure를 이른 시점에 테스트가 가능하도록 조정하는데 드는 비용이 큼
그래서 Sauce labs 팀은 Headless browser testing을 초기 단계의 테스트 수단으로 고려했습니다. 장점은 다음과 같습니다.
- UI 없이 테스트를 수행합니다. 이는 테스트 속도를 빠르게 합니다
- 테스트를 경제적으로 수행할 수 있는 추가적인 옵션이 있습니다 - 병렬 수행등
하지만 단점들도 있습니다.
- Chrome과 Firefox에서만 작동합니다
- 개발자들이 E2E 테스트에 사용되는 언어와 친숙하지 않은 경우, 테스트 작성 시간이 부담이 되었습니다
이 선택은 Sauce labs에게 상황에 적절한 해답이란 점이 증명되었습니다. 제품 개발 프로세스 안에서 다음과 같은 결과를 얻을 수 있었습니다.
- 기능 코드의 품질에 대해 빠른 피드백을 받을 수 있었습니다
- QA 팀에게서 버그 피드백을 받기 이전에 먼저 수정할 수 있습니다
- 버그를 파악하기가 쉬워졌고 이를 파악하고 수정하는 비용이 절감되었습니다
그렇다면 Headless testing이 Pipeline의 어느 단계에서 추가될 수 있을까요? 다음 단계가 효과적일 수 있습니다.
- 개발 과정 내에서의 모든 Pull Request
- Sanity test
- 확장성있는 인프라스트럭쳐의 Shift left testing
그렇다면 이 테스트는 어떤 종류의 테스트가 될까요?
- 최소단위(Atomic)이며, 자동화(Autonomous)될수있으며, 짧은(Short) 테스트
- 테스트 수행이 병렬화가 쉬우며, 빠른 피드백을 받을 수 있는 것
- Integration test for components
실제로 개발 단계에서 개발자가 이 테스트를 이렇게 활용했습니다.
- 최소단위(Atomic) 테스트를 개발 작업이 완료되는 이벤트마다 수행(commit, PR)
- 새로운 코드가 미치는 영향 범위에 해당하는 부분(subset) 테스트를 수행
그렇다면 Sauce labs에서는 실제로 어떤 테스트를 해보았을까요? 아래는 브라우저별 화면 사이즈가 다른 경우의 레이아웃 구성을 확인한 예제입니다. 수동으로 확인하려면 상당한 리소스가 필요하겠지만, 자동화 코드로는 상대적으로 경제적인 테스트를 진행할 수 있겠습니다.
그리고 현장에서 실행한 데모 테스팅입니다. 병렬 수행으로 몇 초만에 원하는 결과를 확인할 수 있었습니다.
테스트 개념 중에 Shift left testing을 위한 한가지 좋은 방안을 제안한 사례였습니다. 이를 위해서는 개발자 누구나 테스트 코드에 접근해서 수행할 수 있는 방법이 필요한데요, 이를 제공해주는 Cloud testing platform이 Sauce labs이기 때문에 강연을 진행하게 되지 않았나 싶습니다. 하지만 Shift left testing은 확실히 제품개발속도와 미래 기술부채를 일찍 해결할 수 있다는 점에서 Headless testing은 가치가 있다고 봅니다.
