안녕하세요. LINE 플러스 서비스 QA 팀에서 같은 팀 김우영 님과 오픈챗 서비스 QA를 담당하고 있는 김진희입니다. LINE 플러스에서 일한 지는 8년 정도 됐고 오픈챗 서비스 QA를 담당한 지는 4년 정도 됐습니다. 이번 글에서는 오픈챗 서비스가 무엇인지 간략하게 설명하고 오픈챗 서비스에서 진행했던 QA 프로세스에 대해 살펴보겠습니다. 그 뒤 이번 글의 주제인 듀얼 QA 프로세스에 대해서 설명하고 이 프로세스를 어떻게 오픈챗 QA에 적용했는지, 적용 후 결과는 어땠는지 살펴보겠습니다.
오픈챗 서비스란
LINE 일반 채팅이 서로 친구를 맺은 아는 사람과의 채팅 서비스라면 오픈챗은 같은 주제에 관심이 있다면 친구가 아닌 사람과도 자유롭게 대화할 수 있는 채팅 서비스라고 할 수 있습니다. 오픈챗은 일반 채팅과 거의 동일한 기능과 성능으로 제공합니다. LINE Timeline 포스트 기능도 포함하고 있고 참여하고 싶은 오픈챗을 검색하거나 추천해 주는 유입구 역할을 하는 웹 메인도 서비스하고 있습니다. 현재 iOS와 Android에 대한 QA를 지원하고 있으며 비정기적으로 서버나 웹 부분의 QA에도 대응하고 있습니다.
여담으로 LINE 오픈챗은 현재 일본과 대만, 인도네시아, 태국에서 서비스하고 있으니 해당 지역에 계시다면 오픈챗 서비스 많이 이용해 주시기 바랍니다.
오픈챗의 QA 프로세스 변천사
이제 오픈챗 QA 프로세스가 어떻게 변해왔는지 말씀드리겠습니다.
플랫폼별 담당 QA 프로세스
오픈챗 서비스를 처음 시작할 때는 LINE에 각 플랫폼별로 QA 담당자가 있었는데요. 오픈챗 초기에는 채팅 기능만 있었기 때문에 일반 채팅의 QA 담당자가 고맙게도 오픈챗 QA까지 진행해 주셨습니다. Android 일반 채팅 QA 담당자와 iOS 일반 채팅 담당자가 각 플랫폼의 오픈챗 QA까지 담당하신 겁니다.
당시에는 QA 업무가 플랫폼별로 분리돼 있었고, 테스트 조직 역시 플랫폼별로 분리돼 있었기 때문에 본인이 담당한 플랫폼의 QA 일정이나 안건에 좀 더 집중할 수 있는 환경이었습니다. 각 플랫폼별로 개성 있는 프로세스나 다양한 테스트 방법론을 시도할 수 있었고 같은 서비스를 담당하는 QA 간에 서로 스타일이 달라도 진행하는 데 크게 무리가 없었습니다. 다만, LINE 앱은 2주마다 클라이언트를 릴리스하는데요. 이런 반복된 일정에 맞추려면 현재 버전에 대한 QA를 진행하면서 다음 버전을 준비해야 했기 때문에 시간적 여유는 없었습니다.
싱글 QA 프로세스
두 번째는 싱글 QA 프로세스 방식이었습니다. 아마 많은 서비스가 지금도 이런 형식으로 QA를 진행하고 있을 거라고 생각합니다.
오픈챗 서비스는 오픈 후에 노트와 웹 메인 같은 여러 기능이 추가되면서 일반 채팅과 조금씩 차이가 발생했고 이에 전담 서비스 QA 인력이 필요하게 됐습니다. 그때부터 제가 본격적으로 진행하게 되었는데요. 싱글 QA 프로세스는 혼자서 진행하기 때문에 본인이 원하는 방향으로 프로세스를 진행할 수 있었고, 내 일정만 고려하면 되니 나만 괜찮다면 언제든지 빠르게 대응할 수 있었습니다. 다만 담당자에게 갑자기 업무가 몰리거나 담당자 부재 시에는 대체할 수 있는 인력이 없었기 때문에 서비스 측면에서도, 제 개인적으로도 불편한 점이 있었습니다.
기능별 담당 QA 프로세스
세 번째는 기능별로 담당자를 분리하는 방식이었습니다. 조금씩 기능이 늘어나던 오픈챗은 지원하는 국가가 늘어나면서 각 국가별로 기능을 차별화하는 과정을 거치며 어느 순간 굉장히 볼륨이 커졌고, 이에 대응하기 위해 QA 한 명이 추가로 투입됐습니다. QA가 추가된 뒤에는 두 명의 QA가 기능별로 업무를 나눴습니다.
그런데 이후 의도치 않게 서비스 기획이나 정책의 방향이 변경되면서 기능이 한쪽으로만 계속 개선되며 특정 QA에게 일이 몰리는 상황이 발생했습니다. 또한 업무를 기능별로 나누다 보니 같은 서비스를 담당하는데도 자신이 맡은 기능이 아니면 해당 기능의 히스토리를 제대로 파악하기 어려워서 한 명이 자리를 비우면 제대로 대처할 수 없는 상황이 발생했습니다. 리소스 관리가 효율적이지 않았던 것입니다.
듀얼 QA 프로세스
이런 와중에 안타깝게도 제 페어가 퇴사했습니다(더 좋은 곳으로…라고 하면 안 되겠죠? LINE이 제일 좋은 회사이니까요 
). 이로 인해 저는 다시 싱글 QA가 됐는데요. 이 시기는 좀 짧습니다. 얼마 지나지 않아 LINE의 QA이신 남중섭 님이 듀얼 QA 프로세스라는 것을 공개했기 때문입니다. 공개된 프로세스를 살펴보니 바로 적용해 보고 싶다는 생각이 들었고 마침 저희 팀에 새로 합류하신 우영 님과 함께 진행하게 됐습니다.
이 프로세스를 적용해 보고 싶었던 이유 중 하나는 오픈챗 서비스의 특성 때문입니다. 오픈챗 서비스는 LINE의 다른 서비스에 많은 영향을 받습니다. 대화 목록이나 대화방, 메시지와 같은 것들은 일반 채팅과 맞물려 있고, 노트는 LINE Timeline 코드 기반이라서 Timeline의 리팩토링이나 기능 추가가 자동으로 적용되고 있으며, 그 외에도 갤러리나 스티커숍, 홈 탭, LINE 인증, 계정 등 여러 서비스와 연관돼 있습니다. 이와 같이 연관된 서비스가 많고 각 서비스에서 어떤 안건을 적용할 때마다 함께 영향을 받는데요. 그 과정에서 여러 사정으로 공유가 늦을 때도 있고, 사전에 잘 공유됐더라도 막상 제가 준비할 시간이 없을 때가 있기 때문에 이와 같은 사항들을 미리 파악해서 테스트 계획과 케이스를 작성하고 테스트 환경을 구축해야 하는 업무 환경이 부담스럽고 어려웠습니다. 그때 듀얼 QA 프로세스를 적용하면 2주라는 시간을 벌 수 있다고 해서 이 프로세스를 채택하게 되었습니다.
듀얼 QA 프로세스 소개
먼저 간단하게 프로세스를 설명하겠습니다. LINE 앱 클라이언트의 릴리스 주기는 2주이고, 하나의 서비스에 담당 QA 2명이 할당됩니다. 두 명의 QA가 각자 담당 버전을 정해서 번갈아 가면서 QA를 진행하는데요. 버전 숫자를 기준으로 홀수 담당과 짝수 담당이 있는 셈입니다. 이번 버전을 QA A가 담당했다면 다음 버전은 B가 담당하는 식으로 프로세스가 흘러갑니다. 자신이 담당하는 버전의 QA가 완료되면 다음 날부터는 다른 QA가 진행하기 때문에 2주간의 시간을 얻을 수 있습니다. 이 2주 동안 자신이 진행할 버전에 적용될 기획이나 개발 안건을 리뷰하고 테스트를 준비합니다. 아래는 듀얼 QA 프로세스를 간략히 표현한 그림입니다.
위 그림에서 기획 리뷰는 다음 버전에 대한 계획과 관련 문서를 받아 리뷰하고 기능을 확인한 뒤 구체적으로 테스트 계획을 짜서 페어에게 테스트 계획을 리뷰 받는 단계입니다. 다음으로 개발 리뷰는 다음 버전의 개발 진척 사항을 확인하고 개발자들과 함께 테스트 방법을 논의하며 개발 안건의 범위와 영향, 리스크를 확인해 테스트 계획을 구체화하는 단계입니다. 또한 세너티(sanity) 테스트를 준비하고 개발 측과 일정을 협의해 수행할 수 있도록 가이드하며 개발 측의 도움이 필요한 부분이 있다면 요청해서 도움을 받기도 합니다.
위 두 리뷰는 앞서 말씀드린 다른 QA가 진행하면서 얻게 된 2주 동안에만 진행하는 것은 아닙니다. 그보다 미리 진행하게 됩니다. 듀얼 QA 프로세스에서 얻은 2주 동안에는 기획 리뷰와 개발 리뷰가 완료된 상태에서 테스트에 더욱 적합한, QA 기간에 보다 쉽고 안전하게 버그를 잘 발견할 수 있는 환경을 구축하기 위한 작업을 진행합니다. 또 한 가지 말씀드리고 싶은 점은, 듀얼 QA 프로세스를 적용하면 QA 인력은 두 명이 할당되지만 테스터 인력은 이전과 동일하기 때문에 QA가 테스트 준비를 모두 완료해야 합니다.
오픈챗의 듀얼 QA 프로세스 적용 사례
아래는 오픈챗에서 진행한 듀얼 QA 프로세스 적용 사례입니다.
앞서 말씀드린 대로 각자 담당할 버전을 정해서 번갈아 진행합니다. QA A가 짝수 버전을 담당하겠다고 결정했다면 1.0.0을 담당한 뒤 다음에는 1.2.0을 담당하게 되는 것입니다. 이때 iOS와 Android 모두를 담당하게 되며 만약 해당 기간에 서버 측에서 QA를 요청한다면 함께 진행합니다. 아래는 보다 구체적으로 업무를 나눈 모습입니다.
기본적으로 QA를 진행할 스펙에 대한 킥오프 미팅과 리뷰, 개발 협의와 같은 것이 먼저 진행되는데요. 이때는 두 QA가 함께 참여해서 같이 리뷰를 진행합니다. 이후 1.0.0 QA 기간이 되면 해당 버전의 담당자 A는 2주간 그 버전의 QA 상태를 보고하고 사인오프(QA Sign-off, QA 완료)를 진행하며, 그 사이 다른 QA B는 다음 버전의 테스트 문서를 준비합니다. B는 문서 작성을 완료한 뒤 QA A에게 리뷰를 요청하고 QA A는 1.0.0 QA를 진행하면서 QA B가 작성한 문서를 B와 함께 리뷰합니다. 이때 QA A는 이미 앞서 진행한 관련 회의에 B와 함께 참석한 상황이기 때문에 상황을 전혀 모르는 생소한 상태에서 리뷰를 하게 되진 않습니다. 이 과정을 통해서 자연스럽게 QA A는 다음 버전의 QA 목록까지 확인할 수 있고 지금 진행되고 있는 QA 안건 중 다음 버전에 영향을 줄 수 있는 안건을 실시간으로 파악할 수 있습니다.
아래는 앞서 설명한 업무 목록을 정리한 샘플입니다.
프로세스를 시작하기 전에 이번 버전과 다음 버전 담당자가 서로 어떻게 업무를 나눠야 하는지 정의하면 좋을 것 같아서 정리하고 협의한 결과입니다. 이 업무 목록은 지속적으로 업데이트하며 관리합니다.
듀얼 QA 프로세스를 도입할 때 꼭 지켜야 할 세 가지 포인트
듀얼 QA 프로세스를 도입하고 실행하면서 꼭 지켜야겠다고 생각한 세 가지가 있습니다.
산출 문서 품질 확보
먼저 두 명의 QA가 작성하는 문서의 기본적인 품질이 보장돼야 한다고 생각합니다. 하나의 서비스를 두 명의 QA가 번갈아 가면서 진행하기 때문에 산출되는 문서의 품질이나 스타일에서 많은 차이가 발생할 수도 있는데 이런 경우 리뷰할 때 시간이 많이 걸리는 등 업무에 부담이 될 수 있습니다. 또한 이슈가 발생해 제가 작성한 테스트 케이스가 다음 버전으로 연기되면서 다음 버전을 담당하는 QA가 진행할 수도 있는데요. 이때 테스트 케이스가 버전마다 너무 다르게 산출된다면 실제 테스트를 진행하는 테스터 입장에서도 문제가 될 수 있다고 생각합니다. 따라서 차이를 최대한 줄일 수 있도록 QA 문서의 템플릿을 만들어 항상 최신으로 관리하고 있습니다. 아래는 테스트 케이스 템플릿입니다.
템플릿에는 테스트 케이스 스텝과 테스트 케이스의 기존 주요 기능이 포함돼 있습니다. QA는 새로운 기능에 대한 테스트 케이스를 생성할 때 이 템플릿을 기초로 작성하기 시작하는데요. 새로운 기능이 기존 기능에 영향을 주지 않는지 또는 기존 데이터에 영향을 주지 않는지를 템플릿에 포함된 스텝을 따라가면서 자연스럽게 검토하며 체크리스트로 활용할 수 있습니다.
아래는 저희가 진행했던 회귀 테스트 계획의 일부를 가져온 모습입니다.
새로운 기능이 추가된 버전이 릴리스되고 나서 그다음 버전 QA를 진행해야 하는 사람을 위해 어떤 게 변경됐거나 어떤 의도로 추가됐는지 관리하며 항상 최신으로 유지합니다. 위와 같은 템플릿은 바로 사용할 수 있도록 별도의 대시보드를 통해 제공하고 있습니다.
페어 QA의 리뷰
다음으로 중요하다고 생각하는 것은 페어의 리뷰입니다. 페어가 QA 산출물 리뷰를 잘 해줘야 합니다. 저는 개발자들이 진행하는 코드 리뷰가 굉장히 좋은 활동이라고 생각하는데요. 개발자의 코드 리뷰처럼 QA 또한 QA 활동이나 산출 문서에 대해 서로 깊이 있게 리뷰해 주고 피드백해 주면 좋을 것 같아서 꼭 적용해 보고 싶었습니다. 그동안에는 실제로 해당 서비스를 담당하는 QA가 아니라면 테스트 케이스 문서가 어디 있는지조차 쉽게 파악하기 어렵기 때문에 깊이 있게 리뷰하는 게 어려웠는데요. 듀얼 QA 프로세스에서는 이런 리뷰가 가능했습니다.
리뷰는 시간이 많이 드는 작업입니다. 따라서 리뷰를 요청하고 완료 후 공유하는 프로세스를 최대한 쉽고 간편하게 진행할 수 있도록 노력했습니다. 아마 많은 분들이 이미 그렇게 하고 계시겠지만, 버그 트래킹 시스템의 일자 관리와 라벨, 담당자 지정 같은 기능을 최대한 활용하기도 하고 리뷰 관련 정보를 업무 캘린더 시스템에 노출시키는 등 여러 방법을 동원해 리뷰 프로세스를 최대한 쉽고 간단하게 만들어서 가용 가능한 자원은 모두 리뷰 자체에 집중할 수 있도록 진행하고 있습니다.
공유
세 번째는 자신이 맡은 버전의 히스토리를 페어에게 잘 공유하는 것입니다. 사인오프 외에도 중간중간에 페어에게 필요한 정보가 있다면 공유하는 것이 굉장히 중요하다고 생각하는데요. 잘 공유하기 위해 사용했던 두 가지 방법을 말씀드리겠습니다.
첫 번째는 공유해야 할 내용이 어떤 게 있는지 제대로 확인하는 것입니다. 예를 들어 알려진 이슈나 다음으로 처리가 연기된 이슈는 없는지, 리뷰 전에 업데이트해야 하는 테스트 케이스는 없는지와 같은 것들을 체크 리스트로 만들어서 공유할 때 놓치는 부분이 없도록 만들었습니다. 아래 이미지는 저희가 사용했던 체크 리스트입니다.
두 번째는 기능에 테스트 히스토리를 남기는 것입니다. 큰 기능의 경우에는 여러 버전으로 나누어서 배포할 수 있는데요. 이때 기능 히스토리라는 문서를 별도로 작성해서 공유하며, 테스트 방법이나 가이드와 같은 것들도 그때그때 테스터분들이나 페어를 위해서 분석하고 공유했습니다. 버전별로 간단하게 회고도 진행했고 스크럼을 통해서 공유하기도 했습니다. 아래 이미지는 여러 버전으로 나뉘었던 오픈챗 AD 기능의 히스토리를 정리한 문서입니다.
보시는 바와 같이 기능 히스토리 문서에는 담당했던 사람이나 당시 사용했던 커뮤니케이션 채널, 관련 산출물 위치, 사용한 툴과 사용법, 로그 확인법, 사용했던 API, 릴리스가 어디까지 됐는지, 남아 있는 이슈는 무엇인지와 같은 사항들을 다음 버전을 진행하는 QA가 참고할 수 있도록 모두 정리해 놓았습니다.
이미 다들 알고 계시겠지만 효율적으로 잘 공유하는 것은 쉽지 않습니다. 듀얼 QA로 진행하면 서로 공유하기 위해서 커뮤니케이션도 늘어나고 문서도 별도로 만들며 회의가 많아지기도 하는데요. 이때 최대한 효율적으로 진행하기 위해서 그때그때 문서를 줄이면서 불필요하다고 판단하면 바로 멈췄고, 별도의 자리를 마련하기보다는 스크럼을 통해서 공유해야 할 것을 그때그때 바로 공유하며 속도를 내기도 했습니다.
이렇듯 공유는 쉽지 않지만, 공유를 하며 겪었던 고생이 나중에 빛을 보기도 했습니다. 다른 서비스 QA와 협업할 때 기존에 작성한 문서를 그대로 전달하면 됐기 때문에 훨씬 편하게 협업할 수 있었고, 개발 팀에서 API를 사용할 때 저희가 정리한 문서를 활용하기도 했습니다. 개인 성과를 기록하고 관리할 때도 이미 만들어 놓은 문서의 URL을 첨부하기만 하면 되니 한결 편했습니다.
듀얼 QA 프로세스의 장점과 주의할 점
이제 듀얼 QA 프로세스를 진행하며 느꼈던 장점과 주의해야 할 점에 대해 공유하겠습니다.
장점
가장 좋았던 점은 여러 방면에서 투명성이 확보된다는 점이었습니다. 동료 리뷰에 사용되는 산출물이 투명해지면서 각 개인의 역량을 좀 더 투명하게 파악할 수 있게 됐는데요. 물론 산출물에 점수를 매기진 않았지만, 내 산출물이 어땠는지 페어의 시각으로 객관적으로 평가받을 수 있었고 이를 통해 내 역량을 다시 돌아보는 계기가 됐습니다.
또한 산출물이 주기적으로 꾸준히 개선된다는 점도 좋았습니다. 같은 서비스를 두 명의 QA가 버전별로 담당하다 보니 페어와 항상 최신 정보를 공유하면서 서로 피드백을 주고받았는데요. 그러다 보니 자연히 산출물이 지속적으로 개선됐습니다.
2주간 테스터분들과 커뮤니케이션하는 게 굉장히 많이 줄어들었다는 것도 빼놓을 수 없습니다. 히스토리를 파악해야 하니 전달된 메시지를 아예 안 볼 수는 없었지만, 적어도 제가 무언가에 집중하고 있을 때 바로 메시지를 확인하느라 방해받지는 않아도 되는 기간이 확보된다는 점이 좋았습니다.
마지막으로 말씀드리고 싶은 장점은 진정한 백업이 생긴다는 점입니다. 예를 들어 그동안에는 갑자기 이슈가 발생하면 신청한 세미나도 취소하고 대응해야 하는 경우가 많아서 미리 계획을 세우는 게 참 어려웠는데요. 이제 미뤄왔던 세미나에도 마음 놓고 참석할 수 있게 됐습니다. 담당 QA가 두 명이니 테스터분들에게 훨씬 빠르게 대응할 수 있다는 것도 장점으로 꼽을 수 있겠네요.
주의할 점
아무래도 두 명의 QA가 굉장히 밀접하게 연관돼 일을 하는 프로세스다 보니 QA 스타일이 다르거나 역량 밸런스가 맞지 않으면 듀얼 QA 프로세스를 도입하는 것은 불가능하다고 생각합니다. 매번 의견 충돌이 발생할 수도 있고 한 사람에게 업무가 몰릴 수도 있습니다. 또한 앞서 말씀드렸듯 작성해야 하는 문서와 커뮤니케이션, 회의가 늘어나는 것이 부담으로 다가올 수도 있습니다.
또 한 가지 주의해야 할 점은, 지금 저희가 처한 상황이기도 한데요. 서비스의 업무가 많아지면 듀얼 QA 프로세스를 진행하는 게 쉽지 않다는 점입니다. 듀얼 QA 프로세스는 두 명이 듀얼로 일하며 각자 번갈아 2주간의 시간을 얻어 준비 작업을 진행하는 게 핵심인 프로세스인데요. 업무가 많아지면 애써 얻은 2주간의 시간이 없어지기 때문에 듀얼 QA 프로세스의 매력이 사라져버립니다. 현재 오픈챗도 웹이나 서버 같은 비정기적 안건이 많이 늘어나고 있어서 향후 프로세스를 어떻게 설정할지에 대해 다시 검토하고 있습니다.
마치며
앞서 오픈챗 서비스의 QA 프로세스 변천사를 말씀드렸는데요. 저희가 과거에 지나쳐 온 프로세스라고 틀린 것이 아닙니다. 최근에 도입한 프로세스라고 최선이나 최고의 프로세스도 아닙니다. 모든 프로세스에는 각각의 장단점이 있고 우리 모두는 각자 상황이 다르기 때문에 자신의 서비스에 어떤 프로세스가 더 잘 어울리는지 잘 검토하고 결정해야 합니다. 특정 프로세스를 꼭 한 번에 전체 적용하지 않아도 됩니다. 먼저 일부분을 적용해 보면서 판단해도 됩니다.
지금 이 글을 읽고 계신 분들이 보다 쉽고 편하게 업무를 진행하며 좀 더 재미있게 회사 생활을 하시길 바라며 이만 글을 마치겠습니다. 긴 글 읽어주셔서 감사합니다.