버그 없는 업데이트를 위해 - QA 테스트 자동화
티맵 개발자 SSUL 6편 - 배포 때마다 떨리는 개발자의 맴 아시잖아요
Chap1. 테스트 자동화 적용 배경
1-1. 테스트 자동화 필요성
1-2. 테스트 자동화 목표 수립
Chap2. 테스트 자동화 환경 구성
2-1. 테스트 도구 활용
2-2. 테스트 인프라 구성
마치며
TMAP의 업데이트는 2주 단위로 이뤄집니다. 대대적인 업데이트가 있기도 하고 소소한 변화가 있기도 하죠. 중요한 건 배포 후 사용자 경험이 완벽해야 한다는 것입니다. 릴리즈 후에 버그나 장애가 발생하면 떨리는 개발자의 손.. 다들 공감하시죠? :) 오늘은 이러한 마음의 짐을 조금이나마 덜어줄 수 있는 ‘QA 테스트 자동화’를 도입하고 적용한 스토리를 들려드리고자 합니다.
Chap1. 테스트 자동화 적용 배경
1-1. 테스트 자동화 필요성
TMAP은 2주 단위 주기 배포를 목표로 프로세스를 수행하고 있습니다. 배포로 인해 실제 사용자가 크게 느낄 수 있는 기능에 변화가 있을 수도 있고, 실제 체감할 수 없는 작은 변화도 있기도 합니다.
출처: https://www.paymoapp.com/blog/project-management-terms기능 변화가 크든 작든 QA팀에서는 기존 기능들이 정상적으로 동작되는지, 신규 기능은 문제가 없는지 사용자 관점에서 테스트를 수행하고 안정적으로 서비스를 제공하는 게 목표인데요.
아무래도 한정적인 리소스로 반복적으로 테스트를 수행하다 보니 회귀 테스트에 소요되는 비용이 증가하고, 그로 인해 탐색적 테스트 수행 시간이 부족해지는 문제가 생겼습니다. 그러다 보니 Hotfix 배포 빈도 횟수는 증가하고, 결과적으로 QA팀은 매번 릴리스 후에 버그 및 장애 발생에 대한 불안감을 느끼게 되었고요.
이러한 문제를 해결하기 위해서 테스트 자동화를 적용하기로 결정했고, QA팀 내부적으로 목표를 설정해 하나씩 적용해 보기로 했습니다.
1-2. 테스트 자동화 목표 수립
앞서 언급드린 문제들을 해결하기 위해서 크게 2가지 목표를 기반으로 테스트 자동화를 적용했는데요.
1. 회귀 테스트는 최대한 테스트 자동화로 커버하자
테스트 자동화를 통해 반복적으로 수행되는 회귀 테스트 비용을 줄이고, 탐색적 테스트 수행에 좀 더 많은 시간을 투자할 수 있도록 기능 변경 및 유지 보수가 적은 테스트 케이스 항목부터 우선 자동화를 적용시키기로 했습니다.
2. 24시간 자동 테스트 수행을 통해 이슈를 빠르게 캐치하고 전파하자
TMAP은 MAU가 1,323만 명에 달할 정도로 많은 사용자가 이용하고 있는 서비스인데요. 그러다 보니 릴리즈 후 발생하는 버그 및 장애에 대한 모니터링도 매우 중요합니다.
개발팀에서는 클라우드 서비스(데이터독 등)를 활용하여 각 프론트/백엔드 레벨에서 실시간으로 모니터링을 수행하고 있지만 QA팀에서는 사용자가 체감할 수 있는 애플리케이션 레벨에서도 기능들이 정상적으로 동작되고 있는지 모니터링이 필요했기에, 이를 테스트 자동화를 통해서 해결하기로 했습니다.
Chap2. 테스트 자동화 환경 구성
2-1. 테스트 도구 활용
테스트 자동화 적용을 위해 먼저 여러 상용/오픈소스 테스트 툴들을 검토하였고, 내부적으로 각 테스트 영역별 환경에 적합하다고 생각하는 툴을 선정하여 테스트 환경을 구성하였습니다.
그중 SK C&C에서 제공하는 mTworks라는 상용 툴을 도입하여 UI 테스트에 활용하였는데요. 동시에 여러 단말기에서 테스트가 가능하고, 비개발자 직군도 테스트 환경을 쉽게 구성할 수 있다는 장점이 있어 해당 툴을 도입하기로 결정했습니다.
출처: https://mtworks.skcc.com/home.do
출처: https://skdt.co.kr/mtworksmTworks 툴을 통해서 동시에 단말기 10대에 테스트가 수행될 수 있도록 환경을 구성하였고, 현재 TMAP 애플리케이션이 새롭게 배포될 때마다 기존 기능들이 잘 동작되는지 확인하는 회귀 테스트 용도로 활용하고 있습니다.
mTworks툴 외에도 다양한 오픈소스 및 무료 테스트 툴을 활용하여 테스트 환경을 구성하였는데요. 우선 API 테스트는 Postman 툴을 활용하여 테스트 스크립트를 작성하도록 하였고, CLI 환경에서 스크립트를 실행시킬 수 있도록 Newman이라는 툴을 활용하였습니다.
출처: https://assets.postman.com/postman-docs/newman-running-in-terminal.gif그리고 mTworks툴에서 기능이 지원되지 않거나, 외부 시스템 연동이 필요한 UI 테스트를 수행하기 위해 UIAutomator2, FacebookWDA라는 오픈소스 툴을 활용하였습니다. 보통은 Appium이라는 툴을 가장 많이 사용하지만 저희는 커스텀마이징이 자유롭고, 속도가 빠른 경량화된 오픈소스가 필요하였기에 해당 툴을 사용하게 되었고, 단순 UI 동작 확인 외에도 화면 전환 속도 체크, 외부 스크립트 연계 등 좀 더 다양한 방법으로 테스트를 수행하는 데 활용할 수 있었습니다.
2-2. 테스트 인프라 구성
앞서 말씀드린 테스트 툴들을 활용하여 어떻게 테스트 자동화 인프라를 구성했는지 간략하게 설명드리도록 하겠습니다.
우선 테스트 영역별 테스트 툴들을 활용하여 CI서버를 통해 테스트가 수행될 수 있도록 각각의 환경을 구성하였고, Flask라는 웹 프레임워크를 활용하여 외부에서 슬랙이나, API를 통해 각 영역에 테스트를 수행할 수 있도록 인터페이스를 구현하여 언제든지 외부 시스템이나, 수동으로 테스트를 수행할 수 있도록 환경을 구성하였습니다.
그리고 테스트가 완료되면 슬랙과 메일을 통해 담당자들에게 결과 리포트를 전달하여 실시간으로 테스트 결과를 확인할 수 있도록 하고, 각 결과 데이터들은 DB에 적재시켜 대시보드를 구성하는데 활용하였습니다.
대시보드에서는 각 영역별 테스트 결과 추이, 애플리케이션 화면 전환 시간, API 응답 시간 등 다양한 관점에서 데이터를 시각화하여 한눈에 쉽게 결과를 모니터링할 수 있도록 적용하였습니다.
마치며
지금까지 테스트 자동화를 왜 도입하게 되었고, 어떻게 적용하여 테스트에 활용 중인지 조금은 두서없이 말씀드린 거 같은데요.
아직은 일부 서비스 대상으로 단순 반복적인 기본 기능들에 대해서만 테스트 자동화가 적용되어 있는데, 올해는 가능한 전체 서비스를 대상으로 테스트 자동화를 확장시켜 지금보다 좀 더 효율적으로 테스트할 수 있는 환경을 만드는 것을 목표로 하고 있습니다.
그리고 기존에 자동화시키기 힘들었던 TMAP의 기본 기능인 길 안내 서비스도 여러 가지 실험을 통해 가능성을 확인하여, 올해 하반기에는 필드 테스트도 지원할 수 있도록 테스트 자동화를 적용시킬 예정입니다.
지금까지 저의 긴 글 읽어주셔서 감사합니다!
티맵 개발자들의 다른 테크노트도 보고 가세요:)
