서비스 완성도 높이기
병아리 기획자, 첫 미션은 QA
IT 회사에 입사 후 처음 맡은 일 중 하나는 QA 서포트였다. 서비스의 모바일웹 화면의 개발 언어를 php에서 java로 변경하는 프로젝트였고, 그 말미에 QA 부서 담당자의 일을 지원하는 게 내게 주어진 미션이었다.
사수가 보여준 'TC'라고 불리는 포맷을 보고 따라서 메뉴별로 체크해야 할 항목을 리스트업하고 기기 여러 대를 테스트하며, 개발자와 이슈사항을 해결하는 것. QA가 무엇을 하는 것인지 잘 알지 못하면서 버그 찾기에만 열과 성을 다하던 시기의 이야기다.
이후 PC, 모바일웹, 모바일앱을 모두 지원하는 신규 프로젝트에 참여하기 시작하면서 지금까지 제법 여러 가지 일을 거치면서 이제는 조금 그게 뭔지 알게 된 것 같다.
모든 결과물이 단번에 완벽하게 나오기는 어렵다.
시나리오는 효율적인 업무 커뮤니케이션과 기능 명세 관점에서 작성되어 주요 플로우 위주로 작성될 가능성이 높고, 디자인이 나오고 개발에 들어가면서 조금씩 바뀌거나 스펙이 변경되는 부분도 있다. 일정이 촉박했거나 의도치 않게 놓친 부분이 생기기도 하고, 고려하지 않았던 변수가 알게 모르게 영향을 주는 경우도 있다.
그렇기 때문에 서비스에 적용하기 전 QA(Quality Assurance)라는 과정을 거쳐 기획에서 의도한 대로 정상 작동하는지, 예상치 못한 케이스는 없는지, 이후 기능적으로나 UX적으로나 개선이 필요한 부분이 있을지 확인한다. 그 결과 프로덕트의 안정성이 확보되고 퀄리티가 높아지는 것이다.
QA, 어떻게 할까?
어느 정도 개발이 마무리되어가는 단계에 이르면 QA 준비를 시작한다. 현재 서비스하고 있는 조직에서 내가 QA를 진행하는 방식이다.
1. 테스트 항목 드래프트 작성
'TC (Test Case)'라고 부르고 대개 Google docs나 Excel, Numbers 등의 시트에 아래처럼 구성한다.
메뉴 트리 (복잡도에 따라 많게는 3-depth까지도 구분)
조건, 상황에 대한 'Case'
케이스별로 기대하는 결과가 나오는지 확인하는 'Checklist'
테스트 결과 기록을 위한 열 (빈칸)
작성 예시시안 기준으로 최종 업데이트를 해둔 시나리오, 그리고 작업 진행 중 추가 협의 또는 변경된 내용에 대한 회의록을 훑어본 뒤, 주요 메뉴 트리(대개는 화면 단위)를 짠다. 메뉴별로는 화면 전체 포괄 > 좌상단 > 우상단 > ... > 우하단 순으로 요소마다 노출되는 조건, 동작시키는 상황에 대해 'Case'를 정의하고, 그에 따라야 하는 'Checklist'를 작성한다.
Case는 "-한 경우", "-click 시"와 같은 형태가, Checklist는 빈칸을 O/X로 체크할 수 있도록 "-한가?"와 같은 형태가 누구나 이해하기 좋다.
(eg)
Case : 글 뷰에서 '구독하기' 버튼 클릭 시
Checklist : 작가를 구독 중인 상태로 바뀌는가
2. 1차 테스트
QA라고 부르기에는 조금 민망한 단계다. 완벽하진 않아도 어느 정도의 형태는 갖춘 프로덕트가 나온 상태라면 작성한 드래프트 TC를 바탕으로 개발자와 함께 1차 테스트를 진행한다. 물론 그전에 개발자가 자체적으로 테스트를 하며 개발을 진행한 상태지만 차근차근 리스트업 한 항목으로 러프하게나마 한 바퀴를 돌아보면 간혹 기본적인 걸 놓친 경우도 발견된다.
스펙이 큰 프로젝트의 경우 (1) 테스트 서버 브랜치 > (2) 기본 테스트 서버 > (3) 스테이지 서버의 순으로 3회 이상의 테스트를 거치는데 이 1차 테스트는 대개 (1)의 환경에서 이루어진다.
1차 테스트를 거치면서 계정 활성 상태나 권한 상태를 세세하게 구분하여 살펴보고 빈 페이지 처리나 에러 대응 등 일반적이지 않은 케이스에 대해서도 꼼꼼히 챙기게 된다.
(eg)
Case : 글 뷰에서 '구독하기' 버튼 클릭 시
Checklist
ㄴ (로그인 & 타인) 작가를 구독 중인 상태로 바뀌는가
ㄴ (로그인 & 작가 본인) 해당 없음
ㄴ (비로그인) 로그인 화면으로 연결되는가 (현재 창)
그 외에도 구현 상태를 살피며 TC를 보충하면서 내비게이션 바, 툴바, 커스텀 팝업 등 공통 UI 가이드를 사용하는 영역이라든가 동일한 데이터를 사용하는 다른 페이지 등, 이번 작업으로 인해 영향을 받을 수도 있는 부분에 대해서도 함께 체크한다.
추가로, 1차 테스트를 해보면 프로젝트 초기에 세팅한 QA 기간이 실현 가능한 스케줄인지 판단할 수 있다.
개발이 아직 끝나지 않은 상태에서 QA를 병행하다 보면 혼란이 생긴다. 이미 테스트해서 'O'를 쳐둔 게 다시 보면 정상 작동하지 않거나, 아예 테스트할 수 없는 항목이 줄줄이 이어져서 이걸 하고 있는 게 맞나 싶을 때도 있다. 개발자 입장에선 일은 남았는데 QA 이슈는 끊임없이 날아오니 스트레스는 쌓이고 집중력은 자꾸 떨어진다. 그러니 일정은 이때 한 번 더 체크해보면 막판에 초조해질 일이 덜 하다.
3. 테스트 환경 설정
브런치는 PC와 안드로이드 앱, 아이폰 앱, 그리고 (풀 스펙은 아니지만) 모바일웹까지 지원하고 있다. 이러한 경우에는 서비스에 접속하는 유저들이 사용하는 환경이 천차만별일 수밖에 없다. 하지만 모든 환경을 대응하는 것은 전문 QA가 담당하더라도 불가능에 가까운 일이다. 그러므로 주력으로 대응할 환경을 어느 범위로 가져갈 것인지 선택해야 한다.
서비스에서 플랫폼별로 호환되는 OS 환경을 최저선을 기준으로 OS 버전별
활성 유저수가 많은 디바이스
디바이스 제조사별
해상도별
PC나 모바일웹의 경우 브라우저 종류와 버전
위 조건을 믹스 매치하여 테스트 환경을 세팅한다. 그 외에도 노치나 하드키 내장 여부 등의 특이 케이스 대응 여부도 결정한다. (이때 태블릿에서 웹 브라우저 터치 처리나 모바일웹 브라우저 가로모드 UI 분기가 들어가면 TC 항목은 또 늘어난다.)
모든 걸 다 테스트할 수는 없다. 플랫폼별로 3-4개 정도의 디바이스나 브라우저를 테스트한다고 생각하고 최적의 조합을 찾는 것이 효율적이다.
4. QA 진행
본격적으로 집중하여 QA에 돌입할 시기다. 완성도가 one and only 목표가 된다. 기획자(그리고 존재한다면 QA 담당자)는 기기와 충전기를 데스크에 열 맞춰 깔아놓고 수시로 꼬이는 케이블을 풀어가며 TC에 O/X를 치고, 개발자는 리포트된 QA 이슈를 실시간에 가깝게 처리한다.
QA 중 발생한 버그를 리포트할 때는 아래와 같이 상세하게 기재해야 한다. 이때 재현 경로와 발생 빈도에 대해서 함께 적어두면 "이거 어떻게 재현해요?"라는 대화 과정을 줄일 수 있다.
발생 환경 (environments) : iPhoneX, iOS 12.1.4
테스트한 개발 버전 (version) : v2.2.3-RC01
재현 경로 (reproduction steps)
1. 비로그인 상태로 글 뷰 진입
2. 하단의 프로필 영역 확인 > '구독하기' 버튼 tap
3. 로그인 화면 노출 > 로그인 완료 > 글 뷰 랜딩
4. 다시 '구독하기' 버튼 tap
증상 (actual results) : 반응 없음 (간헐적으로 발생)
기대하는 결과 (expected results) : 구독 상태로 전환되어야 함
5. 마무리
QA 과정에 발생한 이슈 중 크래시 이슈 등 중요도가 높은 것은 일정을 조정하는 결정을 하더라도 수정한다. 하지만 그 외에 중요도나 대응 우선순위가 떨어지는 이슈, 또는 버그보다는 개선 제안에 가까운 것들도 있다. QA 기간이 종료될 즈음에는 개발자를 포함한 프로젝트 담당자들과 함께 남은 이슈의 처리 범위에 대해 의사결정한다.
물론, 배포 후에도 버그는 생긴다. 죽었다 깨어나도 유저는 겪지 못할 것만 같은 상황의 스트레스 테스트까지 하고 배포해도 버그는 생긴다. 잘 동작하면 잘 동작하는 대로 '왜 이렇게 X가 없지...' 하고 찜찜해하는 마음이 괜히 드는 게 아니다.
하지만 배포까지 잘 마무리했다면! 그다음에는 잔여 QA 이슈를 대응하면서 에러 리포트, 그리고 CS 접수되는 것에 촉을 세우고 있으면 된다. QA는 완성도를 높이는 과정이지, 완전무결한 무언가를 만드는 수단이 아니니까.
끝 끝 끝
작년에 진행했던 한 프로젝트는 TC 리스트가 430여 개였다. 쓰면 쓸수록, 꼼꼼하게 챙기면 챙길수록 손도 많이 가고 어렵다. 배포 때마다 같이 살펴봐야 하는 서비스 전반의 기본 기능 테스트라든가, 주요 기능에 해당하는 에디터 테스트만 해도 300개는 거뜬히 넘어간다. 조금만 무거운 프로젝트가 붙으면 QA 한 턴 도는 데만도 1,000가지는 봐야 하는 것이다.
그래도 그렇게 QA를 거쳐 무사히 배포를 끝내고 나면 턱턱 막히던 숨이 좀 가벼워진다. 이번에도 서비스와 조금 더 친해졌구나 하는 생각이 든다. 아, 개발자와 조금 더 가까워진 것 같은 기분은 덤이다.
내일은 아직 함께 작업한 경험이 몇 차례 없는 개발자 Meryl과 간단한 QA를 시작한다. 두근두근.
