LINE Corporation이 2023년 10월 1일부로 LY Corporation이 되었습니다. LY Corporation의 새로운 기술 블로그를 소개합니다. LY Corporation Tech Blog

Blog


LINE의 QA는 어떻게 일할까?

LINE DEVELOPER DAY 2020에서 김동성 님이 발표하신 How is the difference between LINE QA and QA? 세션 내용을 옮긴 글입니다.

안녕하세요. 저는 LINE에서 서비스 QA로 근무하고 있는 김동성입니다. 이번 글에서는 LINE에서 근무하는 QA가 어떤 역할을 담당하고 있으며 어떤 목표를 세우고 어떻게 일하고 있는지에 대해서 이야기하려고 합니다. 

QA의 역할

가장 먼저 QA의 역할에 대해서 이야기하고 싶습니다. QA의 역할이 무엇인지 여러분들은 정확히 이해하고 계시나요? 혹시 아직도 QA를 이야기할 때 테스트 업무만 생각하시는 건 아닌지 모르겠습니다. 여러분도 아시는 것처럼 소프트웨어 산업이 발전해 오면서 개발뿐만 아니라 테스팅 관련 분야도 같이 발전해 왔는데요. 현재 테스터와 QA의 역할을 어느 정도 구분은 하고 있지만 각각을 정확하게 이해하지는 못하는 것 같습니다. 테스터는 개발 완료 후에 기능 테스트를 담당하는 역할이고 QA는 배포하기 위해 버그를 찾고 리포팅하는 역할이다, 대부분은 이 정도로 이해하고 있는 것 같은데요. 과연 QA의 역할이 이것이 전부일까요? 제가 QA로 일하면서 담당하고 있는 것들에 대해서 몇 가지 정리해 보았습니다.

가장 먼저 품질. 가장 중요한 역할입니다. 프로덕트 품질의 기준을 제시하고 달성하는 것을 목표로 삼고 활동하는 역할입니다. 두 번째로 커뮤니케이션과 가이드. 프로젝트 진행 중 각 단계별 담당 멤버들과 다양한 커뮤니케이션 활동을 진행하며 필요한 경우 가이드하는 역할입니다. 세 번째로 보조자(assistor) 역할입니다. 업무를 진행하는 모든 과정에서 전체 과정을 확인하며 보조하고 도와주는 역할입니다. 네 번째는 분석과 관리 역할입니다. 프로덕트 자체 또는 명세서나 개발 아키텍처, 이슈들을 분석하고 관리하는 역할입니다. 다섯 번째는 테스팅 QA 단계와 그 전후 과정에서 테스팅 활동을 수행하는 역할입니다. 마지막으로 여섯 번째는 피드백과 개선 역할인데요. 업무 과정을 평가하며 필요한 것들을 개선하는 역할입니다.

이와 같이 QA는 테스터와는 다르게 많은 과정과 절차에서 다양한 역할을 담당하고 있습니다. 테스터와 같은 단독적인 형태의 업무 진행도 물론 가능하지만, 현재는 더 나아가 제품 생산을 위한 각 단계에서 다양한 추가 활동의 필요성이 제기되고 있습니다. 간단하게 말해서 배포하는 제품이 우리가 원하는 수준의 품질에 도달하게 만드는 모든 역할이 QA의 역할이라고 정의할 수 있겠습니다.

LINE QA의 역할

서론이 조금 길었는데요. 그렇다면 LINE에서 일하고 있는 QA들은 어떤 형태로 일하고 있는지 이야기해보겠습니다. LINE에서 일하는 QA의 업무 역할은 아래와 같이 크게 네 가지로 분류할 수 있습니다.

첫 번째는 기획과 분석 단계에서의 역할입니다. 두 번째는 업무 관련자들이 서로 협업하는 과정에서 담당하는 역할과 테스팅 업무 과정에서의 역할입니다. 세 번째는 피드백을 수렴하고 개선하는 역할입니다. 배포 등 관련 업무 완료 후에 전체 과정에서의 진행 과정과 결과를 평가하고 개선하는 역할입니다. 마지막으로 네 번째는 품질 문화 조성 역할로, 조직 내 품질 수준을 높이기 위해 품질 문화를 전파하는 역할입니다.

기획과 분석 단계에서의 역할

먼저 기획 단계에서의 역할입니다.

킥오프 미팅에는 프로젝트를 진행하기 전에 프로젝트 개요와 필요한 정보를 습득하기 위해 반드시 참가하며, 미팅 후에는 로드맵이나 마일스톤 등을 작성자와 함께 확인합니다. 이와 관련된 문서들은 대부분 관련 부서에서 작성하는데요. 각 항목의 영향도를 제대로 고민하지 않고 작성하는 경우가 있어서 관련된 사람들에게 예상 가능한 리스크나 비용, 특히 단계별 배포 일정과 같은 것을 고려할 수 있도록 세부적으로 가이드하는 역할을 하고 있습니다.

다음으로 스펙과 스토리를 리뷰합니다. 기획 단계에서 작성한 요구 사항을 리뷰하고 개발 진행 전에 시나리오가 가능한 한 모든 항목들을 구현할 수 있도록 완성됐는지 확인하는 역할을 담당합니다.

마지막으로 신규 기능 요구 사항과 같은 모든 피처에 대한 정리가 완료되고 개발 단계에 진입했을 때, 전체 개발 업무 진행 사항을 모든 멤버가 쉽게 확인할 수 있도록 애자일 보드와 같은 형태로 작성해서 공유하는 역할을 하고 있습니다.

다음으로 분석 단계에서의 역할입니다.

킥 오프 미팅에서 공유된 새로운 기능에 대해 프로덕트 전체 관점에서 리뷰를 진행하고 결과를 공유합니다. 이때 비즈니스 가치가 있는지와 중복된 기능은 없는지, 아직 시기상 이른 기능은 아닌지, 경쟁사와 비교해서 어떤 장단점이 있는지를 함께 확인하며 특히 잘못 정의했거나 모호한 부분이 없도록 리뷰합니다.

다음으로 새로운 기능을 확인하기 위해서 QA 관점에서 어떤 테스트가 필요한지 확인합니다. 코드를 통합한 후에 API 테스트가 필요한지, 자동화할 수 있는 부분은 없는지, 테스트하기 위해서 어떤 조건이나 환경을 마련해야 하는지 등을 클라이언트와 서버 등 모든 멤버들과 함께 협의해서 개발 단계 때부터 대응할 수 있도록 가이드하는 역할을 합니다.

마지막으로 릴리스하기 위한 조건을 확인하고 공유합니다. 특히 단일 기능이 아니라서 여러 서비스의 도메인을 확인해야 하는 경우에는 전체 담당자들과 함께 세부적인 논의를 별도로 진행합니다.

LINE QA의 차이점

아마도 다른 QA분들도 동일한 역할을 수행하고 있을 거라고 생각하는데요. LINE의 QA는 어떤 차이점이 있는지 간략하게 이야기해보겠습니다. LINE QA에서는 업무를 진행할 때 세 가지 기준을 두고 있습니다.

첫 번째로 모든 것을 사용자 기반으로 판단합니다. 기획 방향이 사용자 시나리오에 적합한지 사용자 스토리를 생성해서 검증합니다. 두 번째로 검증할 때 항상 데이터에 기반해서 판단합니다. 가정이 아니라 정확한 데이터에 기반해 진행합니다. 그렇기 때문에 LINE QA 담당자들은 필요한 정보를 수집하고 관련 데이터를 직접 정리하고 있습니다. 마지막으로 검증 내용이 실제 업무에 반영될 수 있도록 리뷰하며 항상 피드백 단계를 거쳐서 최종 스펙으로 흡수될 때까지 관리하는 역할을 담당합니다. 이런 점들이 LINE QA의 차별점이라고 생각합니다.

협업과 테스트 과정에서의 역할

협업과 관련된 첫 번째 역할은 리뷰어입니다. 기획 관련 문서나 개발 아키텍처 등에 대해서 자세하게 확인한 뒤 질문하며 피드백을 제공하는 역할입니다. 이때 부정적인 내용이라도 다양한 측면에서 도움이 된다면 가감 없이 검토할 수 있도록 피드백하고 있으며 인스펙션이나 워크 쓰루 혹은 인터뷰와 같은 형태로 진행하고 있습니다. 이러한 활동은 복잡성을 줄이고 의미가 모호한 부분을 제거하는 등 기획한 기능이나 피처에 대해서 명확하게 정리할 수 있는 기회를 제공합니다.

두 번째는 개발 보조 역할입니다. 개발할 때 고려해야 하는 항목을 케이스별로 정리해서 제공합니다. 여러 가지 예측 가능한 케이스를 제공하거나 이전 기능과 새로운 기능의 스펙을 비교하는 등 기능에 대해서 다시 한 번 정리할 수 있는 기회가 됩니다. 특별한 테스트가 필요한 경우에는 단위 테스트 진행을 요청하기도 하고 관련 정보에 대해 조언하는 역할도 담당합니다.

세 번째는 트레이닝 역할입니다. 개발 진행 중 개발자가 스스로 테스트를 진행할 수 있도록 지원합니다.

어느 과정을 확인해야 하는지 정의하고 어떤 테스트 방법이 있는지 확인하며 테스트 관련 프로세스를 명확하게 정리합니다. 개발자가 담당한 세션이나 기능에만 초점을 맞추지 않고 전체적인 관점에서 진행할 수 있도록 가이드하는 것을 중요하게 생각하고 있습니다.

다음은 테스트 과정에서의 역할로 많은 분들이 알고 계시는 역할입니다.

먼저 테스트 케이스를 디자인합니다. 앞 단계에서 진행한 리뷰나 분석에 대한 결과와 함께 문서 형태의 모든 요구 사항을 분석하고 다양한 유스케이스를 고려해 테스트가 가능하도록 디자인하고 있습니다. 마인드 맵과 같은 도구를 사용하기도 하면서 전체 시나리오를 확인하고 빠지는 부분이 없는지 확인합니다.

디자인을 완료했다면 테스트 목적과 환경, 방법 등을 정리해 테스트 계획을 작성합니다. 특히 새로운 작업이거나 대규모 작업인 경우에는 기획과 서버, 클라이언트 등 모든 멤버에게 공유해 리뷰를 받으며 완성도를 높이고 있습니다.

테스트 계획과 테스트 디자인을 완료한 후에는 테스트 케이스를 만듭니다. 테스트 케이스는 작업을 완료한 후 요구 사항대로 동작하는지 검증하고 필요한 경우에는 개발자 본인을 위한 테스트 케이스를 제공하기도 합니다. 또한 실제 테스트를 담당하는 테스트 엔지니어를 위해 테스트 계획과 테스트 케이스 기반으로 교육을 진행하는데요. 테스트를 진행하기 전에 리뷰와 피드백을 받으며 테스트 엔지니어들이 테스트 대상을 정확하게 이해할 수 있도록 준비하고 있습니다.

LINE QA의 차이점

협업과 테스트에서 또한 다른 QA분들도 비슷한 역할을 담당하고 계실 텐데요. LINE QA의 차이점을 정리해 보았습니다.

LINE에서 QA는 테스트를 하지 않습니다. 물론 세부적으로 필요한 몇몇 테스트는 진행하지만 테스트보다는 전체 업무 진행 과정에서 각 담당자와 함께 목표와 업무 방향을 동기화하는 역할에 더 초점을 맞추고 있습니다. 진행 과정과 테스트 프로세스의 정의, 개발 기획 등 담당자와 테스트 세션 페어링, 테스트 방법과 결과에 대한 브리핑과 디브리핑 등의 활동을 통해 각 멤버가 자신이 담당하는 세션에만 초점을 맞추는 것이 아니라 전체 품질을 이해하며 전체 관점에서 판단할 수 있도록 만드는 역할에 중점을 두고 있습니다.

즉, LINE에서 QA 업무의 가치는 테스트를 직접 수행하는 활동에 있지 않고 품질 자체에 대한 활동 측면으로 이동하고 있다고 말할 수 있습니다.

피드백 수렴 및 개선 역할

세 번째는 피드백을 수렴하고 개선하는 역할입니다. 제품을 배포하거나 진행 중인 업무를 완료하는 시점에서 업무 진행 과정 혹은 결과에 대해 여러 기준에 따라 평가하고 개선하는 단계가 필요합니다. 개발된 코드의 품질을 평가하거나 제품 배포 이후 발생한 이슈에 대응하는 절차를 확인하는 등 전체적으로 제품의 품질을 평가하는 과정이 꼭 필요합니다. QA는 회고를 통해 전체 피드백을 수렴하고 각 담당자에게 필요한 개선 사항을 도출해 냅니다.

QA는 회고 미팅에 조력자의 역할로 참가합니다. 프로세스와 같은 여러 항목에 대한 피드백을 정리해서 우리의 강점과 약점에 대해서 서로가 잘 인식할 수 있도록 도와주는 역할을 하며 개선해야 하는 것들이 무엇인지 적극적으로 참여해 의견을 도출합니다.

LINE QA의 차이점

전체 프로세스에 대해 잘 이해하고 있는 QA가 회고 방향이 실수나 잘못을 비난하는 쪽으로 흐르는 것을 방지하는 역할을 해야 합니다. 또한 정확하게 문제를 제기하고 해결 솔루션을 도출해 개선 방향을 잡을 수 있도록 적극적인 참여를 유도하는 역할도 합니다. 회고 후에는 회고에서 나온 여러 아이템들을 액션 아이템으로 정리해서 작성하는데요. 특히 각 액션 아이템의 담당자를 지정해서 프로젝트에 올바르게 반영되는지 확인하는 역할까지 담당하고 있습니다.

품질 문화 전파 역할

마지막으로 조직 내에 품질 문화를 전파하는 역할입니다. 다들 아시는 것처럼 품질은 QA만의 책임이 아닙니다. 제품의 품질은 프로젝트에 참가하는 모든 사람의 공통 책임이라고 생각합니다. LINE의 QA는 앞서 말씀드린 것처럼 각 단계별 활동을 지속적으로 이어나가서 모든 멤버가 품질 관련 활동을 할 수 있도록 가이드하고 이끌어야 합니다. 이를 조직 내에서 하나의 문화로 형성해 나가는 활동을 하고 있으며 이것 또한 QA의 가장 큰 역할 중 하나라고 말할 수 있습니다.

QA가 갖추면 좋은 역량들

지금까지 네 가지 역할에 대해 설명했는데요. 글을 마무리하기 전에 한 가지 제안하고 싶은 내용이 있습니다. 저는 제품의 품질이 제품을 만드는 모든 멤버의 능력과 역량에 의존한다고 생각합니다.

따라서 각 과정에 참여하는 QA는 기획 분석 단계에서 수행하는 데이터 수집과 수집된 데이터를 해석할 수 있는 역량, 협업 단계에서 개발 멤버와 협업할 수 있는 최소한의 기술, 즉 서비스 아키텍처에 대한 이해와 코드를 이해하는 역량, 프로세스 개선과 관련된 테스트 관리 역량, 각 담당자들과 원활히 소통할 수 있는 커뮤니케이션 역량 등이 필요하다고 생각하며, 이런 역량을 강화하는 것 또한 QA의 역할 중 하나로 만드는 것이 어떨까 제안하고 싶습니다.

마치며

애자일 방법론을 사용하는 조직에서 소프트웨어의 결함을 조기에 발견하고 예방하기 위해 조기(early) 테스트나 '시프트 레프트(shift left)' 등의 프로세스 과정을 강조했는데요. LINE의 QA는 거기서 만족하지 않습니다. LINE의 QA는 현재 QA만의 특정 업무 영역을 정의하지 않고 업무와 관련된 모든 조직과 협업하고 최신 정보를 공유하며 더 높은 품질을 달성하기 위해 노력하고 있으며, 더 나아가서 이러한 과정들을 전파하고 책임질 수 있는 애드보케이터(advocator)의 역할까지 수행하려는 계획을 갖고 있습니다.

이상으로 글을 마치겠습니다. 아래에서 발표 영상도 확인하실 수 있습니다. 긴 글 읽어주셔서 감사합니다.