웹 서비스가 다양해지고 브라우저도 Chrome, Safari, Firefox, Edge 등등 종류가 많습니다. 게다가 모바일 기기를 위한 반응형 디자인을 더해 웹 서비스는 더 다채로워집니다. 그렇다 보니 기능이 잘 동작하는지, 해당 요소가 잘 위치해있는지, 요소 내 텍스트가 예상 값과 일치하는지 등 웹 테스트에 대한 중요도가 많이 올라오게 되었죠.

웹 테스트의 가장 간단한 방법은 자신의 컴퓨터 혹은 모바일 기기에서 브라우저를 통해 손으로 직접 테스트해보는 Manual testing일 것입니다. 하지만 앞서 말했듯이 브라우저의 종류가 많고, 모바일에서 잘 보이는지 확인도 하려면 웹 서비스가 복잡할수록 테스트 시간도 증가합니다. 게다가 사람이 진행하다 보니 테스트 중 실수가 간혹 나기도 하죠.

그래서 다양한 브라우저에서 웹 테스트를 사람이 아닌 컴퓨터로 자동화 할 수 있는 방법이 점차 나오게 되었고, 그 결과 현재 웹은 자동화 생태계가 잘 갖추어진 상태입니다.

🧑‍💻
들어서기 전에, 웹 테스트 자동화는 HTML에 대한 이해도가 있다면 쉽게 할 수 있습니다. HTML은 W3schools, MDN 가이드 등을 통해 학습하실 수 있습니다.

크로스 브라우저 테스트

우리 주변에는 다양한 브라우저들이 있습니다. Chrome, Safari, Firefox, Edge, Opera 등등 종류가 엄청 많습니다. 웹 브라우저는 간단히 말하면 HTML, CSS, JavaScript를 통해 웹 페이지를 유저에게 보여줍니다.(실제로는 더 많은 동작을 하지만 생략할게요) 그런데 음식 하나에 여러 레시피가 있듯이, 5대 브라우저라고 불리는 Chrome, Safari, Firefox, Edge, Opera가 웹 페이지를 보여주는 방식이 조금씩 다릅니다. Chrome, Edge, Opera는 Chromium 기반이고, Safari는 Webkit, Firefox는 Gecko 기반으로 만들어진 브라우저이기 때문이죠. 따라서 만들어진 웹이 Chrome에서는 잘 동작하지만 Safari에서는 동작하지 않거나, 어느 브라우저에 가면 요소의 스타일이 다르게 보이는 현상이 종종 발생하곤 합니다.

그래서 5대 브라우저, 또 모바일 대응을 해야 한다면 iOS Safari, Samsung Internet 등의 브라우저에서도 기능이 잘 동작하는지 등에 대한 테스트를 진행하게 되고, 이렇게 여러 브라우저에서 같은 동작을 하는지 등을 테스트하는 것을 크로스 브라우저 테스트라고 합니다.

그럼 '위에서 말한 모든 브라우저에서 테스트를 해야하는 건가요?' 라고 질문하실 수 있는데요, 저는 그러면 좋긴 하지만 필수는 아니라고 생각합니다.

위와 같이 브라우저 점유율을 참고하거나, 어느 나라에서 서비스를 하는지, 모바일 지원 여부 등 웹 서비스의 방향에 따라 유동적으로 할 필요가 있습니다. 예를들어 통계에 따르면 Opera 브라우저의 점유율이 2%대인데 어느 관리자는 이정도면 과감히 무시해도 된다고 판단할 수도 있고, 만약 미국 내에서 서비스를 한다면 Safari 브라우저에 대한 테스트를 꼭 해보는 방향으로 테스트를 진행해볼 수 있겠습니다.

Selenium은 무엇인가요?

Selenium
Selenium automates browsers. That’s it!

Selenium은 브라우저를 제어할 수 있도록 하는 2004년부터 개발되고 있는 오래되고 잘 알려진 오픈소스 기반 도구입니다. 이를 통해 크로스 브라우저 테스트가 가능합니다. 그리고 회귀 테스트, E2E 테스트, 기능 테스트, 컴포넌트 테스트, 도메인 주도 테스트 등 여러 테스트 기법을 사용해 테스트 할 때에도 Selenium을 사용할 수 있습니다.

테스트를 자동화 하려면 우선 코드로 작성된 테스트 스크립트의 작성이 필요합니다. Selenium은 Java, Python, JavsScript, Ruby 등 많은 언어를 지원하고 있고, Jest, JUnit, Cucumber과 같은 테스트 프레임워크와 결합이 쉽습니다.

Selenium 4.0이 나온지는 대략 5년이 지났지만, Stable 버전으로 채택된지는 2년정도 되어갑니다. 4.0 업데이트에서 크게 Selenium에서 브라우저를 제어하기 위해 사용하던 JSON based protocol에서 W3C protocol로 바뀌었다는 점이 있습니다. 거의 모든 브라우저들이 W3C 스탠다드를 따름으로써 Selenium 또한 W3C protocol을 사용하게 되었습니다.

selenium webdriver architecture
Selenium WebDriver Architecture

여기서 브라우저 드라이버는 Selenium과 같은 웹 자동화 도구가 브라우저를 제어하고 웹 페이지와 상호 작용하는 데 사용되는 일종의 소프트웨어입니다. 드라이버는 특정 브라우저와 호환되며(ex. ChromeDriver - Chrome), 웹 자동화 도구는 이 드라이버를 통해 브라우저를 조작하고 웹 페이지를 조작합니다.

Selenium의 구성 요소

Selenium 공식 문서를 보면 Selenium WebDriver, Selenium IDE, Selenium Grid로 크게 나뉘어진 것을 볼 수 있습니다. 이 3가지 구성 요소들을 간단히 짚고 넘어가볼게요.

selenium hompage

Selenium WebDriver

Selenium WebDriver는 웹 기반 애플리케이션 테스트를 자동화하여 예상대로 작동하는지 확인하는 데 사용되는 도구입니다. 브라우저 드라이버를 제공하고 실제 브라우저와 상호작용을 합니다.

selenium webdriver architecture
Selenium WebDriver Architecture

여러 언어를 지원하는 Selenium Client(테스트 스크립트)에서 보내는 메시지(ex. findElement)를 W3C protocol을 이용해 브라우저 드라이버에 전달하고, 브라우저 드라이버는 실제 브라우저와 HTTP를 통해 서로 커뮤니케이션 합니다.

Selenium IDE

Selenium IDE는 Chrome, Firefox의 브라우저 익스텐션으로 버튼 요소 클릭, 폼 입력 등 액션을 녹화하고 녹화된 행동을 테스트로 저장하고 실행할 수 있도록 합니다. 테스트 스크립트를 만들지 않고도 간단히 액션 녹화 기반으로 테스트를 수행할 수 있다는 장점이 있습니다.

Selenium Grid

Selenium Grid는 Router라고 불리는 서버 장비를 통해 클라이언트 명령을 전달받고, 원격 브라우저 인스턴스에 전달하여 테스트를 진행합니다. 환경 구성에 난이도가 낮지 않은 편이지만, Grid를 이용하면 여러 브라우저를 여러 장비에서 동시에 실행이 가능합니다.

selenium grid architecture
Selenium Grid 아키텍쳐(from Selenium Grid)

지금까지 Selenium에 대해 알아보았습니다. 이제 어떤 도구를 써야할지 명확해진 것 같네요. 하지만 이제 여러분들은 궁금해 하실수도 있습니다.

"어떤 방법으로 테스트하죠?🤔"

이제 그 물음에 답할 차례입니다. 웹 테스트에도 다양한 테스트 기법들(ie. 컴포턴트 테스트, 기능 테스트, UI 테스트, end-to-end 테스트...)을 사용해볼 수 있습니다. 저는 이중에서 end-to-end 테스트를 설명하고 진행해보려고 합니다

End-to-end(E2E) 테스트

E2E 테스트는 유저가 애플리케이션(웹, 모바일 앱 등)을 처음부터 끝까지 사용하듯이 전체적인 플로우를 유저 관점에서 테스트하는 방법입니다. 따라서 E2E 테스트는 유저 시나리오에서 애플리케이션 내의 요소, 기능들이 예상대로 잘 동작하는지를 보장합니다.

웹 서비스, 특히 프론트엔드 영역에서 E2E 테스트라면 대부분 UI를 통해 입력에 대한 출력이 예상하는대로 이루어지는지 중점적으로 테스트해보는 것을 말하기도 합니다. 만약 벡엔드 영역이라면 E2E 테스트는 클라이언트의 요청에 대한 응답이 예상값과 일치하는지를 중점으로 진행됩니다.

E2E 테스트에서 자동화 영역을 얹었을 때, 서비스 카테고리, 제품의 크기, 제품의 완성도, 사내 조직 등 기준에 따라 E2E 테스트 자동화가 괜찮은 방법이 될 수도 있지만, 오히려 독이 되기도 합니다.

E2E 테스트 자동화를 고려해볼만한 케이스들은 다음과 같습니다.

  • 쇼핑, 금융 등 유저 시나리오에서 테스트가 필수적인 서비스 카테고리인 경우
  • 서비스가 어느정도 시장에서 자리를 잡아 커진 상태인 경우
  • Micro-service architecture 기반으로 만들어진 서비스에서 유저 관점에서 유기적으로 동작하는지 테스트할 때

반면, E2E 테스트 자동화가 효율적이지 못할 때에는 다음과 같습니다.

  • 빈번하게 UI가 변경될 서비스인 경우: UI가 바뀌면 테스트 스크립트가 동작하지 않을 수도 있는데요, 스크립트 수정 과정에서 비용이 소모되기 때문입니다.
  • 초기 서비스 단계 또는 작은 조직: 대부분의 초기 서비스 단계는 서비스적으로 불확실성이 높고 많이 변경됩니다. 그리고 소규모 조직에서는 QA가 없는 조직이 많고, 제품 개발에 더 초점을 맞추게 됩니다. 이때는 자동화 테스트 보다는 Manual testing이 더 효율적일 수도 있습니다.

마치며

이번 글에서는 크로스 브라우저 테스트의 중요성, Selenium에 대해 알아보고, E2E 테스트가 어떤 테스트인지에 대해 알아보는 워밍업을 했습니다. 다음 글부터 테스트 자동화를 위한 환경을 구성하고 테스트를 실행해 보도록 하겠습니다!