
여러분들께 조금이나 간단하게 마이리얼트립 제품 기획실 구성원을 소개 드리고 싶어서 구성원을 야구 포지션에 비유해 보겠습니다.
팀을 진두지휘하는 감독(PM), 감독을 보좌하며 전술을 구상하는 수석코치(Designer), 가장 먼저 상대 타자를 맞이하는 선발 투수(Front-End Dev & Mobile Dev), 선발 투수 다음으로 마운드에 등판하는 중간 계투(Back-End Dev), 경기를 마무리 짓기 위해 마지막으로 등판하는 마무리 투수(QA)가 있습니다.
네, 그렇습니다. 이번 이야기는 마이리얼트립에서 마무리 투수를 맡고 있는 ‘QA’ 이야기를 해보려 합니다.
Speed or Perfection
시작부터 뜬금없지만 여러분의 시간은 소중하니 지루한 소개는 생략할게요. 우선 마이리얼트립은 무슨 일이든 빠르게 시도하는 것을 지향합니다. 고민보다는 빠르게 실행하고 빠른 시도를 통해 다양한 성공과 실패를 경험하자는 뜻이 담겨있죠. QA 관점으로 실패(버그로 인한 사용자 경험 저해)는 고객중심 서비스에서 전혀 가치 있는 일이 아닙니다. 하지만 우리는 안타깝게도 매번 ‘완벽하진 않지만 빠르게?’ or ‘빠르진 않지만 완벽하게?’를 선택해야 하는 상황에 놓이곤 합니다. 예시를 한번 들어보겠습니다.
회사 매출과 직결된 이슈이기 때문에 긴급하게 서비스 배포가 진행되어야 하는 상황입니다. 저도 다급한 상황임을 인지하고 있습니다만.. 수정된 부분만 확인하고 배포하기엔 자꾸만 Side-Effect 발생이 마음에 걸립니다. 우선 Side-Effect에 대해 말씀드리기 전 레거시 코드에 대해 간단하게나마 알아볼 필요가 있습니다.
레거시 코드란 유산이라는 뜻을 가진 Legacy와 Code가 합쳐진 합성어로 타인이 작성해 놓은 오래된 개발 코드로 이해하시면 편합니다. 오랜 시간을 거쳐 서비스가 성장하는 과정 속 개발 코드 또한 점점 방대해져 갑니다. 시간이 지나 퇴사자들이 생겨나면서 자연스럽게 퇴사자들이 작성했던 개발 코드, 즉 레거시 코드가 생겨납니다.
이러한 레거시 코드는 작성자 이외에 다른 사람이 개발 의도를 파악하기 쉽지 않기 때문에, 레거시 코드를 지우거나 수정했을 때 프로그램에 어떠한 영향을 미칠지는 그 누구도 확신할 수 없게 됩니다. 그렇게 아무 곳에도 쓰이지 않을 법한 A 코드를 삭제했더니 숨어있던 B 코드에서 남모르게 A 코드를 사용하고 있는 상황이 발생하면서 오류가 발생합니다.
Regression Test를 통한 테스트 커버리지 확보
속도감 있게 서비스 배포를 진행하고자 한다면 보다 안정적인 서비스를 제공하기 위한 안전장치가 필요합니다. 우리는 Regression Test(회귀 테스트) 기법을 통해 빠르게 배포되는 일정 속 최대한의 테스트 커버리지를 확보활 수 있습니다.
Regression Test란 개발자가 수정한 소스 코드가 다른 부분에 영향을 미치지 않는지 테스트하여 소스 코드의 수정이 또 다른 오류를 발생시키지 않도록 검증하는 테스트 기법입니다. 또한 Test Case의 분량이 30분~1시간 내외이기 때문에 테스트에 소요되는 시간도 매우 짧은 편입니다. 검증 마지막 단계에서 Regression Test까지 진행한다면 배포되는 서비스의 Side-Effect 이슈에 대한 갈증을 해소할 수 있을 겁니다.
검증 방식에 정답은 없습니다. 수많은 테스트 기법이 존재하듯이 다양한 테스트 기법을 활용해 사용자들이 더욱 건강한 서비스를 사용할 수 있도록 노력하는 것만큼 가치 있는 일이 있을까요?
테스트 자동화를 통한 리소스 확보
어느 곳이든 소규모 QA는 항상 바쁩니다. 개발팀의 경우 각 파트마다 담당하는 플랫폼이 분산되어 있기 때문에 각자가 맡은 작업에만 집중하면 됩니다. 그러나 이 모든 작업들이 끝이 나면 산발적으로 QA에게 넘어오게 되죠. (이곳은 마치 옥천 hub..?) 적은 인원으로 업무를 골고루 분배하기 위해선 리소스 관리는 필수입니다.
Regression Test는 서비스 검증의 마지막 단계에서 진행되어야 하는 고정적이고 반복적인 업무입니다. 아무리 30분~1시간 분량의 빠르게 진행되는 테스트라고 해도 서비스 배포가 다수의 플랫폼에서 동시에 진행되어야 한다면? 검증이 필요한 플랫폼마다 여러 차례 Regression Test를 수행한다고 가정했을 때 하루에 주어진 업무 시간의 거의 절반을 차지하게 됩니다. Regression Test는 분명 테스트 커버리지를 높여주고 속도감 있는 배포를 위한 테스트인데, 이런.. 양날의 검이 되어버렸습니다. 이때 등장해야 하는 것이 바로 테스트 자동화입니다.
테스트 자동화란 무엇일까요? 이름만 들어보면 ‘자동화’라는 단어 때문에 기계 혼자서 알아서 짠! 하고 테스트하는 것처럼 들리는데요. 기본적으로 테스트 자동화는 테스트 커버리지를 높여주는 목적으로 사용됩니다. 그 밖에도 사람이 수행하는 단순하고 반복적인 QA 업무를 소프트웨어의 도움을 받아 일관성 있는 테스트를 도와주는 테스트용 소프트웨어입니다. 그렇기 때문에 사람이 직접 테스트 코드를 작성하여 프로그램이 대신 테스트를 수행하는 것으로 이해하시면 됩니다.

이제 저희도 개발의 힘을 빌려봅시다. 혹시라도 프로그래밍 언어를 다뤄야 한다고 해서 겁먹을 필요는 없습니다. 개발자분들처럼 서버를 구축하고 앱을 개발하고, 이런것들은 잠시 넣어두세요. 우리는 테스트 자동화에 필요한 기본적인 지식들만 배워나가면 됩니다.
Selenium을 활용한 테스트 자동화
테스트 자동화에는 다양한 소프트웨어 프레임 워크가 있지만 그중 Selenium을 선택하였습니다. Selenium은 가장 대중적인 프레임 워크로써 참고할 만한 다양한 예제와 문제 해결 방안을 찾기에 용이하며, 다양한 서비스를 제공하지만 모두 오픈소스라는 장점이 있습니다. 또한 Python을 가뭄에 콩 나듯 공부해봤던 저에게 Selenium은 Java, Python, C#, Ruby 등 다양한 언어로 테스트 코드 작성이 가능하기 때문에 Selenium을 선택하게 되었습니다.
테스트 자동화가 실행되는 동안 다른 업무에 집중할 수 있고 그에 따른 리소스 확보가 가능하니 프로덕트의 변경점에 대한 테스트 코드의 유지 보수만 이루어진다면 얼마든지 QA 리소스 확보의 큰 도움이 될 수 있습니다.

Selenium Grid를 활용한 Parallel Test
Selenium에서 제공하는 Selenium GRID를 활용한다면 웹 브라우저, 모바일 앱의 Parallel Test가 가능하기 때문에, 다양한 웹 브라우저(IE, Chrome, FireFox 등) 테스트와 안드로이드 디바이스의 제조사(Samsung, LG, Google 등) 또는 OS 버전 별 다수의 플랫폼에서 동일한 테스트를 여러 환경에서 동시에 테스트가 가능하니 4번의 테스트를 한차례에 진행한다면 4배 빠른 테스트가 이루어지는 셈이죠.

Jenkins CI 빌드 스케줄러 활용한 서비스 모니터링
조금 더 응용해서 테스트 자동화와 Jenkins CI 빌드 스케줄러를 통해 주요 기능의 대한 서비스 모니터링도 가능합니다. 테스트 스크립트를 원하는 시간대를 설정하여 주기적으로 테스트 결과에 대한 내용을 Slack Bot으로 받아볼 수 있습니다.

'QA' 카테고리의 다른 글
[QA] Web 어플리케이션 테스트 자동화 - Jenkins Install (0) | 2018.07.26 |
---|---|
[QA] Web 어플리케이션 테스트 자동화 - Python Unittest (0) | 2018.06.27 |
[QA] Web 어플리케이션 테스트 자동화 - Virtualenv (0) | 2018.06.27 |
[QA] Web 어플리케이션 테스트 자동화 - Selenium Webdriver (0) | 2018.06.26 |
[QA] Web 어플리케이션 테스트 자동화 - What is Selenium? (0) | 2018.06.26 |