리멤버 QA팀이 하는 일

안녕하세요. 드라마앤컴퍼니 QA팀 곽수민입니다. 이번 포스팅에서 드라마의 QA팀은 어떠한 업무를 하고 있는지 소개하려 합니다. 

삐까뻔쩍한 최신형 휴대폰을 사용해보았더니, 막상 전화 거는 방법도 모르겠고, 키보드를 사용하는 방법도 어렵고, 기본으로 설치된 애플리케이션이 강제 종료되어 작업 중인 내용이 사라진다면 어떨까요? 소비자들로부터 품질 관련 불만이 봇물처럼 터져나오고 아무도 그 휴대폰을 구매하려고 하지 않을 것입니다. 그래서 개발 결과물에 대한 QA 검수가 매우 중요합니다.

QA 검수 단계에서는 크게 다음 두 가지 관점으로 검수를 진행합니다.

• 기능적 관점: 버그 없이 기능이 잘 동작하는지
• 사용자 UI/UX 관점: 각종 버튼/텍스트/화면 레이아웃 등 UI가 올바르게 표시되는지

UX가 잘 설계되었는지 여부는 기획자 분들도 이미 많은 고민을 하신 이유로 QA 검수를 넘어서 판단하기 조심스러운 영역인 것 같습니다.

QA 검수는 정확성이 생명이기 때문에 최대한 효율적이고, 넓은 테스트 Coverage를 가지고 진행되어야 합니다. 검수가 제대로 이루어지지 않는다면 서비스의 품질과 사용자 Retention은 낮아지고, 결국 사용자에게 사랑받지 못하는 서비스가 되고 맙니다. 따라서 드라마 QA팀에서는 더 정확하고 꼼꼼한 검수를 위해 다양한 방법을 사용하고 있습니다.

– QA의 꽃 : 기능 / UI 테스트

안드로이드 디바이스는 이슈에 따라 디바이스 또는 OS 환경에 영향을 받는 경우가 매우 많습니다. (저는 그래서 iOS 검수를 좋아하는 편입니다.) 정확히 추산할 수 없지만, 리멤버의 구글 플레이 스토어 배포 단계에서 설치 가능한 디바이스들을 조회해보면 약 11,500개 정도의 디바이스들이 보여집니다. 그러니 전세계의 안드로이드 디바이스들을 모두 전수 테스트한다는 것은 말도 안되는 일이죠. 그래서 사용자들이 많이 사용하는 디바이스들을 고려하여, 비교적 넓은 Coverage를 가진 범용적인 디바이스들로 테스트 기기를 선정하는 것이 매우 중요합니다. (다행히 한국은 삼성에서 나온 디바이스들의 점유율이 높아 어렵지는 않았습니다.)

테스트 기기 선정을 마쳤다면, 테스트 시나리오도 준비합니다. 보통 모든 기능을 테스트하는 전수테스트(Full 테스트)와 각 기능별 주요 요소를 빠르게 점검하기 위한 기능테스트(Simple 테스트)가 있습니다. 그 외 배포 후 빠르게 UI 요소들을 점검할 수 있는 테스트 시나리오, 테스트 환경 (QA 검수 환경, Staging 환경, 운영 환경 등)에 따른 테스트 시나리오도 있습니다. 다양한 상황에서 다양한 목적으로 테스트할 수 있도록 여러 테스트 시나리오를 만들고, 이를 상황에 맞게 적절히 조합하여 활용하는 것이 중요합니다.

이제 테스트를 진행합니다. 구현된 기능은 문제가 없는지, 다양한 환경에서 앱이 잘 구동되는지의 여부, 레이아웃이나 워딩 등에 문제는 없는지, 입력된 데이터는 정상적으로 등록되어 앱에 표시되는지 등의 사용자 케이스를 충분히 고려하면서 검수를 진행하게 됩니다.

사실 위에서 언급한 QA 검수는 모든 QA 조직에서 잘하고 계신 부분입니다.  그러나 드라마 QA팀에는 다른 조직과는 구별되는 여러 특징들이 존재합니다. 그 중 첫 번째는 바로 서버 API를 QA검수와 버그 원인 추적에 매우 잘 활용한다는 것입니다.

– 최고의 보조 도구 : API

서비스마다 차이가 있지만, 리멤버에서는 로컬에서만 동작 가능한 기능도 있고, API 라는 서버와의 통신을 통해 앱을 조종하는(?) 녀석이 있습니다. 저도 이 API 영역이 처음에는 매우 어렵고, 개발자들만 아는 기술인 줄 알았습니다.

보통 테스트 업무를 하기 위해서 테스트용 더미 데이터를 쌓거나, 수십개의 계정이 필요한 경우들이 있습니다. 또한, 버그의 내용 파악을 위해서 ‘노가다’로 재현단계에 필요한 데이터를 쌓거나, 부족한 정보들로 파악해볼 수 밖에 없습니다. 저도 역시 그러한 과정을 통해서 많은 시간을 날려(?)보았던 경험이 있습니다. 더 나은 프로세스를 만들기 위해서 여러가지 방법을 찾아본 끝에 내부 API를 활용해보기로 하였고, 결과는 상상을 초월할 정도로 QA 업무에 많은 도움이 되었습니다.

보통 식당에서는 손님이 메뉴판에서 원하는 메뉴를 골라 직원에게 주문을 합니다, 그러면 주방에서는 요리를 하고, 음식이 완성되면 직원이 손님에게 가져다줍니다. 이를 API 개념에 빗대어보면 다음과 같습니다.

‘손님’ = ‘클라이언트’,

‘메뉴’ = ‘서비스가 제공하는 기능’,

‘주방’ = ‘서버’,

‘직원’ = ’API’

손님(클라이언트)은 주방(서버)에서 메뉴(기능)가 어떻게 만들어지는지 모르고 또 알 필요도 없습니다. 다만, 손님은 직원(API)을 통해서 요청(주문)을 보낼 수 있고, 요청의 결과(직원이 내가 주문한 메뉴를 가져다주는지)가 정상인지 확인할 수 있습니다. 예를 들면 우리는 서비스에 로그인을 하기 위해, 로그인 버튼을 누릅니다. 그러면 사용자 입장에서는 그냥 ‘로그인’ 버튼만 눌렀다고 인지하게 됩니다. 하지만 실제로 우리가 주목해야 될 내용은

• ‘화면에서 보이는 버튼 중 로그인 버튼을 누름’  = ‘로그인 요청 API를 서버로 전송‘

입니다. (당연히 ‘로그인’ 버튼을 눌렀는데, ‘회원가입’ API가 호출되면 안 됩니다. 식당에서 부대찌개를 시켰는데, 김치찌개가 나오면 안되잖아요?)

API를 활용할 줄 알면 단순히 화면을 보고, 테스트 시나리오대로 검증하는 역할을 넘어서, 다양한 QA 업무를 더욱 단순하고 빠르게 해결할 수 있습니다. 드라마 QA팀은 팀명함첩 결제 기능처럼 복잡하거나, 반복적으로 이루어지는 테스트에 API를 활용하고 있습니다. 대량의 테스트 데이터를 만들 때도 사용합니다. 프로세스에 대한 고도화가 점점 되어가면서 테스트 API 서버가 여러 번 뻗기도 하였고, 생각지도 못한 기능들의 문제들도 발견할 수 있었습니다. (때문에 서버 개발팀이 고생 많이 하셨죠..) 그 외에도 사용자 혹은 사내에서 보고되는 버그들의 원인 파악에도 유용하고 쓰고 있습니다. 그 결과 노가다성 업무들은 60%이상 줄게 되었습니다.

<회원가입_인증번호 전송을 위한 API 호출>

위 이미지에서와 같이 API 호출 시 파라미터에 유효한 값, 유효하지 않은 값 등 다양한 값을 입력하고, 서버의 응답 결과를 확인합니다. 이를 통해 기능 요구사항에 맞는 API가 호출되는지, 앱에서는 API 응답을 화면에 잘 보여주는지 등을 확인해보면 실제로 소스 코드에 버그가 있는지, 그 원인은 무엇인지 파악할 수 있습니다.

<내부에서 신고된 버그를 해결해나가는 과정>

테스트 중 발견되거나 사용자에게 제보된 버그들을 전달할 때, “이거 안되는거 같아요”라고 단순하게 전하기 보다는 “API 호출을 해보니 서버에서는 정상적으로 잘 처리가 되는 걸 보면 앱에 문제가 있는 것 같아요”하고 더욱 구체적인 내용을 전달해줄 수 있습니다. 덕분에 버그의 원인을 빠르게 잡아내고, 사용자의 불편함을 원활하게 해결하고 있습니다.

개발팀 외 다른 팀이 서버 API의 내용을 잘 숙지하고 활용하면 조직 전체에 매우 큰 도움이 되는 것을 보여주는 사례이기도 합니다.

자체 TASK

1. 기능별 시나리오 분할과 Function-Tree

드라마앤컴퍼니 QA 팀은 현재에 안주하지 않고 ‘일이 되게하는 방향’을 찾기 위해서 계속해서 시도하고, 빠르게 변화하는 업무 방식을 추구하고 있습니다. 예를 들면 과거 기능별 TF (하나의 기능 개발을 위해 기획, UI/UX, 개발, QA가 하나의 임시 팀을 이루는 것) 체제로 일을 한 적이 있었습니다. 이 때 여러 기능별 TF에서 각 기능 개발이 동시다발적으로 진행되면 QA팀의 리소스가 매우 부족했었습니다. 모든 기능을 매번 ‘전수 테스트’ 한다는 것은 말도 안되는 엄청난 양이기도 하고, 매일 밤늦게까지 고생하면서 업무를 진행하기에는 팀원들의 사기도 매우 걱정이 되었습니다. 또한, 서비스에 기능이 계속 추가되면서 테스트 시나리오는 나날이 늘어만 가는 와중에 일정 수준의 테스트 Coverage를 만족시키는 것도 매우 부담스러웠습니다. 그에 더해 배포 주기도 점점 짧아지면서 기존의 시나리오로 매번 검증하는 방법은 너무 비효율적이었습니다.

그래서 이를 해결해보고자 TF체제에 적합한 테스트 시나리오 관리 방법부터 고민했습니다. 우선 기존 전수테스트의 모든 Test Case들을 ‘기능’ 단위별로 분할했습니다. 새롭게 추가되는 기능들도 같은 방식으로 모두 분할하여 관리하기 시작했습니다. (당연히 전수 테스트 시나리오에도 함께 반영이 되었고요.)

이후에 각 TF에서 QA 검수를 요청하면 미리 검수용 시나리오를 분할해 둔 덕분에 해당 기능 및 연관된 기능만 테스트할 수 있었습니다. 이를 통해 테스트 범위를 대폭 축소시키면서도 일정한 수준의 Coverage를 확보할 수 있었습니다. QA 검수 효율이 매우 좋아지는 게 눈에 보였고, 더불어 팀의 리소스도 충분히 확보할 수 있었습니다.

하지만 그 행복은 길지 않았습니다. 각 TF별로 단일 기능이 개발된 빌드의 검수가 필요할 때는 매우 적합했지만, 각 TF에서 개발한 여러 기능을 합친 빌드를 검수할 때가 문제였습니다. 분할된 기능의 테스트 시나리오를 일일이 찾아서 취합시켜야 하는 번거로움이 뒤따랐고, 테스트 결과의 History 관리가 매우 힘들다는 문제점이 있었습니다.

사실상 테스트 시나리오를 일일이 찾아본다면 대응 가능하기도 하고, 여러 기능들이 합쳐져 검수해야 할 범위가 복합적이라면 전수 테스트를 돌려버리면 그만일수도 있습니다. 하지만 그만큼 코드 수정이 일어나지 않은 부분을 포함하여 불필요한 테스트를 반복하게 되면 아까운 테스트 리소스가 소모됩니다. 또, 광고, PR이나 마케팅 일정 등이 맞물려 배포 일정이 중요한 시기에 배포 타이밍을 놓치게 된다면 회사에 큰 손실을 입히게 됩니다. (여담이지만.. 그래서 QA팀은 정말 좋은 판단력을 지녀야 합니다. 어떻게 해서든 배포하기 전 완벽한 컨디션을 가진 서비스를 세상에 내놓아야 하니까요.)

리멤버에서는 어떠한 기능을 수정 한다면, 똑같은 기능을 제공하는 다른 뷰, 또 다른 진입 Point, 숨어있는 관련 뷰 등이 많이 있습니다. 그래서 최소한의 Coverage를 유지하면서 모든 기능을 빠르고, 완벽하게 검수하는 방법을 찾아야 했습니다. 고민 끝에 서비스의 모든 기능과 기능 간 영향도를 한눈에 파악할 수 있도록 Function-Tree를 제작했습니다. (서비스의 기능이 추가/변경/삭제되면서 끝없는 현재 진행형입니다.)

<Function-Tree 사용 예시>

이렇게 간단하게 기능만 나열해놓은 것 같지만, 위의 사용 예시처럼 ‘이메일’에 대한 앱 내 모든 위치와 함께 코드 수정에 따른 영향도가 있을 만한 기능들을 한눈에 검색하여 파악할 수 있습니다. 이를 통해 테스트 범위를 정확하고 효율적으로 판단할 수 있음은 물론이고, 과거에 놓치고 있었던 부분까지 검증할 수 있었습니다.

2. 테스트 자동화(Test Automation)

시간이 흐름에 따라 서비스의 기능이 점점 늘어나면 테스트 범위도 함께 늘어납니다. 그런데 빡빡한 일정에 맞춰서 검수를 마치려면, 시간이 없다는 이유로 전체적인 Test Coverage를 타협해야 하는 경우도 많습니다. 하지만 이렇게 하면 문제를 발견하지 못할 확률이 높아지고 최상의 컨디션을 가진 제품을 보장하지 못합니다.

드라마의 QA팀에서는 이러한 문제를 해결하고자 테스트 자동화를 도입하여 Appium 서버와 Selenium Library에 기반한 자동화 스크립트를 개발하고 있습니다.

<자동화 스크립트가 작동되는 모습.gif>

테스트 시나리오 중 굳이 사람 손을 타지 않아도 되는 기능들을 테스트 자동화하면 테스트에 소요되는 리소스를 절감하고 테스트 속도를 크게 향상시킬 수 있습니다. 또한 QA 직무의 특성상 같은 시나리오로 테스트를 반복하다보면 지루해지기 쉽고, 그러면 실수할 수 있는 확률이 높아집니다. 그러나 스크립트는 사람과 달리 지루함을 느끼지도 않고, 실수하지도 않기 때문에, ‘일관성’ 있는 테스트 결과를 받아볼 수 있습니다. 또한, 자동화 스크립트가 점점 쌓여가면서 컴퓨터가 할 수 있는 Test Coverage가 점점 더 늘어나면, QA 엔지니어의 리소스를 테스트 시나리오 고도화 등 다른 더 가치 있는 작업에 사용할 수 있다는 장점이 있습니다.

반면, 테스트 자동화의 단점은 기능의 추가/수정이 일어나면 관리해야 될 소스 코드의 양도 늘어난다는 것입니다. 추후에 대규모 UI 또는 기능 변경이 일어난다면 관련 코드를 수정해야 하므로 예상치 못한 큰 Cost가 발생할 수 있습니다. 따라서, 어떤 부분을 자동화하고, 어떤 부분을 하지 말아야 할 지 잘 판단해야 합니다.

<실제 리멤버 앱에서 테스트가 수행되는 Step을 구현한 소스 일부>

스크립트는 ‘기본 기능 검증’ 위주로 작성해야 합니다. ‘기본 기능 검증’ 은 여러가지 의미가 있을 수 있지만 저희는 보통 ‘Happy Path’(예외 또는 오류의 발생 없이 정상적으로 수행되는 기본 시나리오)로 설정하고 있습니다. 기획 내용을 바탕으로 예상한 대로 잘 동작하는지, 특정 상황에서 정의된 에러 메시지(ex. ‘비밀번호를 잘못 입력하셨습니다.’ 등의 메시지(API의 경우 200 OK 응답))가 잘 보여지는지 확인합니다. (참고로 예상치 못한 404, 500 등의 API 에러가 발생하는 경우는 ‘Happy Path’가 아닙니다.)

‘Happy Path’ 위주의 검증 방법을 채택한 이유는 모든 테스트 시나리오에 대해 코드를 작성하면, 무수히 많은 Case들을 고려해야 하므로 결국은 사람이 직접 손으로 테스트를 하는 것보다 훨씬 더 비효율적이기 때문입니다. 너무 많은 테스트 케이스로 인한 스크립트 관리/유지보수의 부담과 Code Quality의 저하로 인해 사람의 손을 더 타게 된다면 배보다 배꼽이 더 큰 상황을 초래할 수 있습니다. 또한, 서비스 기능별로 ‘단위 테스트’ 방식 기반으로 스크립트를 작성하였고, 때때로 전체 테스트가 필요하면 모든 단위 테스트를 한번에 모아서 ‘통합 테스트’를 실행하도록 시스템을 구축하였습니다. 이렇게 하면 마이너한 앱 기능 수정(전체 테스트가 필요 없는 코드 수정)이나 빠르게 해결되어야 하는 hotfix(긴급패치) 대응을 위한 테스트를 빠르게 진행하기 쉽습니다. 

이렇게 만들어진 Script는 마치 사람이 실제 앱을 사용하는 것처럼 클라이언트를 조작할 수 있고, 정의된 시나리오대로 앱의 기능 테스트를 수행하게 됩니다.

마무리

다음에는 위에 소개한 내용 중 드라마 QA팀이 자동화 시스템을 구축하면서 겪은 시행착오와 구축방법을 본격적으로 소개해보려고 합니다.