🚀 QAing의 오픈채팅방에 참여하세요! 프로덕트팀을 위한 인사이트를 공유하고 소통할 수 있어요! [참여하기]
기업별 QA 업무 진행 사례
지난 아티클을 통해 QA라는 직무와 관련한 역량 등을 알아봤다면, 이번에는 각 기업별로 어떻게 QA 실무를 진행하는지, 실제 QA 업무를 수행하는 과정과 문화에 대해 살펴보고자 합니다. 실제 현업에서 QA업무가 어떤 의미를 가지는지 조금 더 입체적으로 조망해본다면, QA가 기업에서 가지고 있는 중요한 역할에 대해서 조금 더 심층적으로 이해할 수 있기 때문입니다. 국내의 대표적인 IT 기업 세 곳을 위주로 살펴보도록 하겠습니다.
LY Corporation (구 LINE Corportation)의 QA 프로세스 및 문화
먼저 Line Corporation을 살펴보도록 하겠습니다. 라인QA 팀에서 수행하는 업무 흐름은 다음과 같이 크게 네 가지 단계로 구분할 수 있습니다. 각 단계별 스텝에서 어떤 주안점을 두고 QA업무를 진행하고 있는지 알아보도록 하겠습니다.
- 기획과 분석
- 협업과 테스트
- 피드백 수렴 및 개선
- 품질 문화 정립
먼저, 기획과 분석 단계에서 LINE QA팀에서는 세 가지 기준 하에 기획과 분석 업무를 진행하고 있습니다.
“첫 번째로 모든 것을 사용자 기반으로 판단합니다. 기획 방향이 사용자 시나리오에 적합한지 사용자 스토리를 생성해서 검증합니다. 두 번째로, 항상 데이터에 기반해서 검증하고 판단합니다. 가정이 아니라 정확한 데이터에 기반해 진행합니다. 그렇기 때문에 LINE QA 담당자들은 필요한 정보를 수집하고 관련 데이터를 직접 정리하고 있습니다. 마지막으로, 검증 내용이 실제 업무에 반영될 수 있도록 리뷰하며 항상 피드백 단계를 거쳐서 최종 스펙으로 흡수될 때까지 관리하는 역할을 담당합니다.”
이러한 세 가지 기준 설정과 이 기준에 입각한 QA업무 진행이야말로 LINE QA만의 차별점이라고 할 수 있습니다.
그 다음은, 협업과 테스트 단계입니다. QA라는 업무의 특성상 타부서와의 긴밀한 협업은 필수적인 요소이기도 하죠. 이같은 협업에 임하는 QA팀의 자세와 역할을 라인은 세 가지로 정의하고 있습니다.
”협업과 관련된 첫 번째 역할은 리뷰어입니다. 기획 관련 문서나 개발 아키텍처 등에 대해서 자세하게 확인한 뒤 질문하며 피드백을 제공하는 역할입니다. 이때 부정적인 내용이라도 다양한 측면에서 도움이 된다면 가감 없이 검토할 수 있도록 피드백하고 있으며 인스펙션이나 워크 쓰루 혹은 인터뷰와 같은 형태로 진행하고 있습니다. 이러한 활동은 복잡성을 줄이고 의미가 모호한 부분을 제거하는 등 기획한 기능이나 피처에 대해서 명확하게 정리할 수 있는 기회를 제공합니다.
두 번째는 개발 보조 역할입니다. 개발할 때 고려해야 하는 항목을 케이스별로 정리해서 제공합니다. 여러 가지 예측 가능한 케이스를 제공하거나 이전 기능과 새로운 기능의 스펙을 비교하는 등 기능에 대해서 다시 한 번 정리할 수 있는 기회가 됩니다. 특별한 테스트가 필요한 경우에는 단위 테스트 진행을 요청하기도 하고 관련 정보에 대해 조언하는 역할도 담당합니다.“
그 다음은 트레이닝 역할입니다. 이 단계에서 QA팀은 직접 테스트를 진행하지 않고, 개발 진행 중 개발자가 스스로 테스트를 진행할 수 있도록 지원하는 역할을 담당합니다.
“LINE에서 QA는 테스트를 하지 않습니다.”
물론 세부적으로 필요한 몇몇 테스트는 진행하지만, 라인 QA 팀은 테스트보다는 전체 업무 진행 과정에서 각 담당자와 함께 목표와 업무 방향을 동기화하는 역할에 더 초점을 맞추고 있습니다. 진행 과정과 테스트 프로세스의 정의, 개발 기획 등 담당자와 테스트 세션 페어링, 테스트 방법과 결과에 대한 브리핑과 디브리핑 등의 활동을 통해 각 멤버가 자신이 담당하는 세션에만 초점을 맞추는 것이 아니라 전체 품질을 이해하며 전체 관점에서 판단할 수 있도록 만드는 역할에 중점을 두고 있습니다. 즉, LINE에서 QA 업무의 가치는 테스트를 직접 수행하는 활동에 있지 않고 품질 자체에 대한 활동 측면으로 이동하고 있다고 말할 수 있을 것 같습니다.
이어서, 피드백 수렴 및 개선 단계입니다. 제품을 배포하거나 진행 중인 업무를 완료하는 시점에서 업무 진행 과정 혹은 결과에 대해 여러 기준에 따라 평가하고 개선하는 단계가 필요합니다. 개발된 코드의 품질을 평가하거나 제품 배포 이후 발생한 이슈에 대응하는 절차를 확인하는 등 전체적으로 제품의 품질을 평가하는 과정이 꼭 필요하죠. QA는 회고를 통해 전체 피드백을 수렴하고 각 담당자에게 필요한 개선 사항을 도출해 냅니다.
전체 프로세스에 대해 잘 이해하고 있는 QA가 회고 방향이 실수나 잘못을 비난하는 쪽으로 흐르는 것을 방지하는 역할을 해야 합니다. 또한 정확하게 문제를 제기하고 해결 솔루션을 도출해 개선 방향을 잡을 수 있도록 적극적인 참여를 유도하는 역할도 합니다. 회고 후에는 회고에서 나온 여러 아이템들을 액션 아이템으로 정리해서 작성하는데요. 특히 각 액션 아이템의 담당자를 지정해서 프로젝트에 올바르게 반영되는지 확인하는 역할까지 담당하고 있습니다.
마지막으로, 품질문화 정립 단계입니다. LINE의 QA는 각 단계별 활동을 지속적으로 이어나가서 모든 멤버가 품질 관련 활동을 할 수 있도록 가이드하고 이끌어야 합니다. 이를 조직 내에서 하나의 문화로 형성해 나가는 활동을 하고 있으며 이것 또한 QA의 가장 큰 역할 중 하나라고 말할 수 있습니다.
애자일 방법론을 사용하는 조직에서 소프트웨어의 결함을 조기에 발견하고 예방하기 위해 조기(early) 테스트나 '시프트 레프트(shift left)' 등의 프로세스 과정을 강조하곤 하는데, LINE의 QA는 거기서 만족하지 않습니다. LINE의 QA는 현재 QA만의 특정 업무 영역을 정의하지 않고 업무와 관련된 모든 조직과 협업하고 최신 정보를 공유하며 더 높은 품질을 달성하기 위해 노력하고 있으며, 더 나아가서 이러한 과정들을 전파하고 책임질 수 있는 애드보케이터(advocator)의 역할까지 수행하려는 계획을 갖고 있습니다.
쏘카(SOCAR)의 QA 프로세스 및 문화
같은 QA 업무라 하더라도, 회사마다 각기 다른 프로세스로 업무를 진행합니다. 기획과 개발이 다 완료된 상태에서 QA가 투입되는 경우도 있고, 주제만 정하고 기획을 만들어 가는 과정에서 QA가 투입되는 경우, 기획서가 만들어진 후 QA가 투입되는 경우 등 다양한 단계에서 참여가 이루어지고 있습니다.
쏘카에서는 QA 요청서가 발의되었을 때부터 QA가 프로젝트에 참여합니다. QA 요청서는 JIRA를 통해 만들어지며 QA팀 내부에서 정의한 양식에 맞춰 프로젝트 리더가 작성하여 요청합니다. 이 요청서에는 기획서가 포함되어 있고 기획, 개발, 디자인 일정이 포함됩니다. 프로젝트에 관련된 자료들 또한 함께 첨부됩니다. QA 요청서가 발의되면 QA팀 내에서 담당자를 정하게 되고 본격적으로 프로젝트에 투입되어 업무를 하게 됩니다.
배정된 담당자는 킥오프(Kick-off) 회의에 참여하여 프로젝트의 규모와 목적을 파악하고 다음 내용들을 기준으로 QA Plan을 구체화합니다.
- 프로젝트 정보
- QA 일정
- 테스트 데이터
- 테스트 기준
- 테스트 범위
- 테스트 환경
QA Plan을 작성할 때 보통 QA 요청서를 참고하고 QA를 진행하면서 필요할 사항들을 수집하고 정리합니다. 프로젝트를 진행하기에 앞서 필요한 전제 조건들과 검증 시 반드시 확인해야 될 사항들, 그리고 검증 진행 방법들도 회의를 통해 확인하고 기록합니다. 쏘카의 QA Plan은 초기에 한번 적고 끝나는 것이 아니라 테스트 케이스를 작성하거나 테스트를 수행하면서도 새로운 내용이나 참고할 사항들을 꾸준히 업데이트하게 됩니다. 프로젝트에 관해 설명이 더 필요한 부분이나 의견이 있다면 PM, 개발자, 디자이너 등 프로젝트에 참여하는 인원들과 소통하여 빠르게 문제를 해결합니다.
프로젝트에 대해 파악되었다면 테스트 케이스 혹은 체크리스트를 작성합니다. 프로젝트의 규모가 크지 않거나 빠르게 확인해야 프로젝트의 경우, 확인해야 될 주요 항목을 간략하게 적어서 정상적으로 수행이 되는지를 판단하기 위해 체크리스트를 작성하게 됩니다. 체크리스트와 다르게 테스트 케이스의 경우에는 전제조건과 수행하는 절차 그리고 수행함으로 인해 기대되는 결과가 포함되기 때문에 체크리스트보다 더 세밀하게 기능을 테스트를 진행할 수 있습니다. 쏘카에서는 테스트 케이스 관리를 웹 기반 테스트 관리 시스템인 Testlink로 하고 있습니다.
테스트 케이스는 작성하는 사람에 따라 다르겠지만 주어진 형식은 맞추되 작성하는 건 본인 성향에 따라 작성하고 있습니다. 어떤 사람은 오타와 띄어쓰기 하나까지 세세하게 테스트 케이스로 작성할 수 있고 어떤 사람은 기능만 위주로 작성하여 차이가 나지 않을까 우려할 수 있지만 테스트 케이스를 작성한 후 팀 내에서 리뷰를 진행하고 피드백을 통해 맞춰가고 있습니다. 또한 필요에 따라 팀 내에서 테스트 케이스 리뷰가 진행된 후 프로젝트 내에서도 테스트 케이스 리뷰를 진행합니다.
개발이 완료되고 나면 개발 환경에서 테스트를 수행할 수 있게 테스트 서버를 띄워 QA를 수행합니다. 작성한 테스트 케이스를 바탕으로 테스트를 수행하는 데 프로젝트에 따라서 앱 또는 웹 테스트를 진행합니다. 데이터를 확인해야 되는 프로젝트라면 DB를 조회해서 테스트를 진행할 수도 있고 실제 차량에 들어가는 장비를 가지고 테스트를 진행하기도 합니다. 또한 일정에 따라 실제 차량으로 테스트를 진행하는 등 다양한 테스트 활동을 추가로 진행하기도 합니다. 테스트를 수행하면서 발견되는 이슈들은 JIRA에 등록합니다.
QA가 완료된 후에 팀과 프로젝트 내에 프로젝트가 종료되었다는 의미로 Sign off를 합니다. 프로젝트 수행 내용을 간략하게 전달하고 서버나 웹 관련 프로젝트라 배포까지 완료되었다면 모니터링에 대한 내용도 포함하여 공유합니다. 그 후에는 프로젝트를 수행하면서 알게 된 내용이나 공유할 내용, 남겨야 되는 주요 토픽 등에 대해 자유롭게 문서 정리를 합니다. QA Plan에 내용을 추가하여 정리하는 경우도 있지만 규모와 히스토리가 긴 프로젝트의 경우엔 컨플루언스에 따로 페이지를 만들어서 작성합니다.
프로젝트별로 QA가 완료되고 나면 하나의 버전으로 배포하기 위해 검토를 한 후 빌드 요청을 합니다. 빌드 된 앱의 회귀 테스트(Regression test)를 진행한 후 앱 심사를 요청하고 심사가 완료되고 난 뒤 QA 팀에서 마켓 배포를 수행합니다.
카카오 엔터프라이즈의 QA 프로세스 및 문화
효율적인 QA를 위해 ISO/IEC/IEEE 29119-2 표준의 동적 테스트 프로세스(Dynamic Test Processes)를 기반으로 주어진 자원(일정 및 인원) 내에서 단계별 테스트 계획을 철저히 실행할 수 있다면, 적어도 이론적으로는 이상적인 QA 활동을 수행할 수 있습니다. 하지만 현실에서 이런 이상적인 QA 활동을 수행하기는 그리 쉽지 않습니다. 프로젝트 구성원으로 참여하다 보면 여러 종류의 예기치 못한 변수들이 발생하게 되기 때문입니다. 예를 들어 테스트 계획에 포함되지 않은 기능 요구사항들이 갑자기 추가되거나, 개발과 테스트 환경 구축에 예상보다 많은 시일이 소요되어 테스트 일정을 준수하지 못하게 되는 상황 등에 직면하게 됩니다. 이런 상황에 대처하기 위해 카카오 엔터프라이즈는 조직 레벨에서의 테스트 전략과 그에 부합하는 테스트 계획을 최대한 상세하게 수립하는 동시에 프로젝트 단위별로 변경점이 발생할 때마다 테스트 계획을 유연하게 수정하는 전략을 취합니다. 이러한 전략의 일환으로 QA 구성원 모두가 Quality Accelerator의 역할을 수행하며, Test Case 설계 및 수행 등의 단순한 ‘테스트 활동’ 보다는 효율적이고 이상적인 ‘테스트 방법’을 끊임없이 탐색하고 고도화시키는 전략을 취하고 있죠. 이런 전략은 한정된 자원을 효율적으로 활용하여 시간과 인적 자원 등을 절감하는 고효율 테스트를 수행하는데 목적이 있습니다. 이런 전략의 방법론으로서 카카오 엔터프라이즈는 ‘리스크 기반 테스팅’, ‘RST(Rapid Software Testing) 방법론’, 그리고 테스트 자동화 등을 프로젝트에 유연하게 적용하고 있습니다.
리스크 기반 테스팅
리스크 기반 테스팅(Risk-based Testing)은 리스트 척도 평가를 통해 높은 아이템과 낮은 아이템에 따라 자원을 효율적으로 활용하는 테스트 방식으로 크게 리스크 아이템 식별, 리스크 분석 및 테스트 전략 수립 단계로 구성됩니다. 카카오엔터프라이즈에서는 프로젝트 단위별로 자원을 분배하여 QA 활동을 하고 있는데 한정된 자원으로 모든 프로젝트를 동일한 수준으로 대응하기는 매우 힘든 상황입니다. 이런 이유로 리스크 평가 절차에 맞추어 프로젝트별 조건에 따라 과제나 기능 단위로 리스크 아이템을 식별하는 작업을 수행합니다. 그 후, 식별된 리스크 아이템들을 대상으로 사업 및 마케팅 등 다양한 내부 조건에 맞추어 중요도를 평가하고 테스트 우선순위를 부여하여 그에 맞는 테스트 전략을 수립합니다.
- 리스크 식별 : 대응하는 과제 혹은 기능 단위로 리스크 아이템을 식별합니다.
- 리스크 분석 : 식별된 아이템을 내부 기준에 맞추어 평가하여 중요도에 따라 테스트 우선순위를 부여합니다.
- 테스트 전략 : 수립부여된 우선순위에 따라 테스트 전략을 수립하고, 해당 테스트의 범위와 프로세스, 산출물 등과 같이 상세한 테스트 계획을 작성합니다.
테스트 전략을 수립할 때에는 SDLC(Software Development Life Cycle)의 전체 범위를 대상으로 한 ‘Full Cycle 프로세스’와 제한된 일정 혹은 자원에 대한 대응이 필요할 때 테스트 차터(Test Charter)2를 활용하는 ‘경량화된 프로세스’로 구분하여 업무에 활용하고 있습니다. 하지만 앞에서도 언급했듯이, 실제 업무에서는 여러 예기치 못한 변수가 발생하기 때문에 테스트 프로세스 중 하나를 선택하여 완벽히 준수하기는 쉽지 않습니다. 따라서 테스트 리드는 정의된 테스트 기법과 프로세스를 준수하되, 프로젝트별 환경(일정, 인프라, 협업 조직 구성 등)과 변수 등을 면밀히 파악하여 더욱 효율적인 방식으로 테스트 계획과 프로세스를 유동적으로 조정하며 테스트 업무를 수행하는 것을 목표로 합니다.
RST(Rapid Software Testing)
리스크 기반 테스팅 외에도 카카오 엔터프라이즈는 정해진 리소스를 효율적으로 운용하는 방식을 꾸준히 연구하며 적용해보고 있는데, 그중 하나가 제임스 바흐(James Bach)가 제안한Rapid Software Testing(이하 RST) 입니다. RST 방법론은 제품이나 소프트웨어가 가지는 다양한 정황(Context)에 대한 이해를 바탕으로 상세하게 수립된 미션을 수행하고(Mission-Focus), 예산과 시간이 정해져 있는 상황에서 한정된 자원을 효율적으로 활용하는 것에 집중하는 접근 방식입니다. 카카오엔터프라이즈에서는 일부 프로젝트에 RST 방법론을 적용하여 테스트를 수행 중이며 프로젝트별 일정과 제한된 자원, 환경 등의 여러 정황을 고려하여 테스트 리드의 판단하에 공식화된 테스트와 탐색적인 테스트 방식을 적절히 편성하여 업무를 수행하고 있습니다. 이는 RST 방법론이 가지는 목적과 동일하며, 문서나 산출물의 유지 보수 비용을 최소화하여 절감된 자원을 통해 테스트 가치를 극대화하는 데 그 목적을 두고 있습니다.
테스트 자동화
이 밖에도 한정된 자원을 효율적으로 활용하기 위해 반복되는 테스트 범위에 대한 커버리지를 확보할 수 있는 목적으로 테스트 자동화도 좋은 접근 방식이 될 수 있습니다. 현재 카카오 엔터프라이즈에서는 Sanity Test 용도로서 공통 범위를 대상으로 하는 UI 테스트 자동화와 카카오 i에 탑재된 다양한 도메인에 대한 발화 테스트 용도로 API 자동화 등을 적용했으며, 가능한 전체 서비스에 이런 테스트 자동화를 도입하는 것을 목표로 하고 있습니다.
UI 테스트 자동화를 조금 더 설명하자면, 웹이나 애플리케이션 영역을 대상으로Selenium과 Appium 기반으로 스크립트를 작성하여 업무에 활용하고 있습니다. 유지 보수가 최대한 적게 발생하는 공통 영역을 선정한 후, 해당 영역에 대한 테스트 시나리오를 기반으로 스크립트를 작성하고 적용하고 있습니다. 이는 유지 보수에 드는 비용을 최대한 줄여 리소스에 대한 부담을 줄이려는 목적으로, 테스트 스크립트는 키워드 중심(Keyword-driven) 구조로 설계되며 다양한 용도에 맞추어 필요한 기능들만 수행하는 것도 가능합니다. 하지만 테스트 자동화 영역은 QA 리소스를 대체하는 용도로 접근하기보다는 QA 활동의 일부분을 대체하여 활용하는 것을 목표로 하는 것이 이상적이며, 적용 커버리지 역시 현실적인 수치를 목표로 잡는 것이 중요합니다. 또한 테스트 자동화에만 너무 집중하면 다양한 영역에서의 활동에 제약이 발생할 수 있고, 오히려 매뉴얼로 테스트하는 것보다 효율이 떨어질 수 있기 때문에 이런 점도 유의해야 합니다.
서비스의 근간이 되는 QA 업무의 의미와 가치
QA라는 동일한 업무를 진행함에 있어서 각 기업마다 각 조직의 특성을 고려하며 조금 더 나은 QA 방식을 고민합니다. LY의 경우 QA라는 업무를 ‘실행’관점에서 접근하기보다 ‘조망’과 ‘흐름’의 관점으로 접근하고 있으며, 쏘카는 프로젝트 단위별로 마치 특정 분야의 엔지니어와 같이 기확과 개발 사이에서 QA적 사고와 그에 입각한 보완점과 개선점을 찾아내려 하죠. 카카오 엔터프라이즈는 단편적인 테스트를 넘어 테스트 방법론에 대한 고민과 더 효과적인 QA 방안을 거시적 관점과 함께 끊임없이 찾고 개선하려 합니다.
이처럼 기업에서 QA는 전면에 드러난 역할은 아니지만, 기획과 개발, 운영과 고객과의 접점에 이르는 전과정을 매끄럽게 연결시켜주며 서비스와 시스템의 안정을 꾀하는 아주 중요한 기능을 담당합니다. 앞선 세 가지 기업의 사례에서 살펴보았듯이, QA라는 업무를 보다 효율적이고 효과적으로 진행하기 위해 QA 담당자는 끊임없이 전략을 짜고 그것을 수정, 개선시키며 서비스의 품질 향상을 위해 노력하죠. 그런 의미에서 각 기업마다 세부적인 프로세스와 접근 방식은 미묘하게 다를지라도, 그 안을 관통하는 핵심 가치는 사실 동일하다고 할 수 있습니다. 바로, 전체 서비스를 조망하는 전략적인 업무라고도 할 수 있겠죠.
오늘 소개해드린 각 기업별 QA 업무 흐름을 통해, QA 라는 직무와 업무를 바라보는 폭넓은 시각과 함께 보다 깊이 있는 이해에 도달하시기를 바라겠습니다.
Share article
