QA팀의 프로세스 정립기 Part2

들어가며

안녕하세요 노머스 QA팀의 이진솔입니다. 이전에 ‘제로에서 시작해 QA 프로세스를 구축해간 사례’를 한 차례 공유드린 바 있습니다. (이전 내용은 QA팀의 프로세스 정립기 를 클릭해주세요!)

QA 프로세스를 이야기하다 보면 흔히 “QA 프로세스는 정말 어렵다”라는 말을 듣곤 합니다. 실제로도 정답이 정해져 있지 않고, 조직의 상황과 도메인의 특성에 따라 수없이 달라질 수 있기 때문입니다.

저희 팀 역시 처음에는 시행착오를 많이 겪으며 프로세스를 하나씩 만들어갔습니다. 그 이후 여러 프로젝트를 수행했고 팀원들과 함께 QA 컨퍼런스에 다녀오기도 했습니다. 다양한 기업들의 사례를 접하며 느낀 점은, 저희가 만들어온 프로세스가 업계 전반에서 보편적으로 추구하는 방향과 크게 다르지 않다는 것이었습니다. 사용하는 도구나 표현 방식은 달랐지만, 큰 틀에서의 접근법은 유사했습니다.

상반기에는 실제 업무에 저희 QA 프로세스를 본격적으로 적용하면서 많은 개선이 있었지만, 동시에 여전히 보완해야 할 부분들도 확인할 수 있었습니다. 팀 내부와 프로젝트 담당자분들로부터 받은 피드백을 토대로 기존 방식을 다시 검토하고, 한층 더 견고하게 다듬게 되었습니다.

이번 글에서는 저희의 새로운 QA 프로세스 Part2 를 공유드리고자 합니다.

프로젝트 단위로 정해진 QA 프로세스의 한계

새로운 프로젝트가 생기면 QA 담당자가 배정되고, 매주 월요일에 정식 QA가 시작됩니다. 하지만 프로젝트 단위로 진행되는 QA 외에도, 이미 등록된 기능을 추후 수정하는 경우, 핫픽스, 혹은 팀 내부의 인프라 개선과 같이 정식 QA 프로세스를 타기에는 규모가 작거나 긴급한 이슈들이 자주 발생했습니다.

이런 QA 요청들은 매번 슬랙 IT 부서 전체 채널에 공지되다 보니 일정 관리가 어렵고, 다른 정보와 섞여 혼선이 생기는 문제가 있었습니다. 특히, 다른 논의 속에 묻히거나 담당자가 명확히 지정되지 않는 경우도 있었습니다.

이 문제를 해결하기 위해 저희 팀은 슬랙 QA 요청 전용 채널을 만들었습니다. 이제는 프로젝트 QA뿐만 아니라 핫픽스나 비교적 작은 QA 요청도 한 곳에서 관리할 수 있게 되었고, 요청자와 담당자가 명확히 연결되면서 커뮤니케이션 효율이 크게 개선되었습니다.

DevQA에서 Sanity Test로

저희는 정식 QA 이전에 ‘DevQA’ 단계를 두고, 메인 시나리오를 검토하면서 크리티컬한 이슈를 사전에 잡아내는 방식으로 진행해 왔습니다. 이 과정 덕분에 큰 이슈가 정식 QA 단계까지 넘어가지 않도록 어느 정도 걸러낼 수 있었습니다.

하지만 최근 들어 DevQA 단계에서 프로젝트 진행 구성원과 QA 담당자 모두가 비효율을 겪고 있다는 피드백이 지속적으로 접수되었고 TC 작성과 환경 준비, 이슈 관리까지 모든 과정이 시간이 많이 소요되면서 개선의 필요성을 느꼈습니다.

이에 따라 저희는 정식 QA 이전 단계에서 핵심 기능을 빠르고 효율적으로 확인할 수 있도록 DevQA 프로세스를 전면적으로 개선하기로 했습니다. 그리고 그 결과, 기존의 DevQA를 Sanity Test라는 개념으로 재정의하게 되었습니다.

진행 방식

1. 테스트 케이스 작성

기존에는 QA 담당자가 모든 테스트 케이스를 작성하고, 시나리오별 담당자를 일일이 지정했습니다. 이 방식은 시간이 오래 걸릴 뿐 아니라, 문서화 작업에 치중되는 문제가 있었습니다.

새로운 방식에서는 QA가 메인 시나리오와 핵심 엣지 케이스 중심의 체크리스트만 제공하며 테스트의 주체는 PO와 기획자가 담당하고, QA는 진행을 지원하는 역할을 맡습니다. 검증은 해피 케이스와 주요 실패 케이스 위주로 진행되며, 세부 사례의 포함 여부는 프로젝트 특성에 따라 PO·기획자가 직접 결정합니다.

2. 테스트 환경 준비

QA가 직접 시나리오별 계정과 굿즈를 생성해 공유했던 기존 방식과는 다르게 앞서 소개한 QA 요청 전용 채널에 계정·굿즈 생성을 위한 워크플로우를 마련해, 필요 시 누구나 요청할 수 있도록 구성했습니다.

3. 이슈 처리 방식

기존 DevQA 단계에서는 발견자가 이슈를 등록하고, 정식 QA 단계에서 QA 담당자가 다시 확인하는 절차를 거쳤습니다. 새로운 방식에서는 이슈 등록 과정을 생략합니다. 발견자가 담당 개발자와 즉시 소통해 수정하고, 수정 사항은 자체 재확인 후 필요 시 스쿼드 내 크로스 체크를 진행합니다.

마무리하며

이번 개선을 통해 다시 한번 느낀 점은 QA 프로세스에는 정답이 없다는 것입니다. 상황과 도메인에 맞게 계속 다듬어가야 하며, 실제 프로젝트 속에서 부딪히고 피드백을 받아 가며 발전시키는 과정 자체가 바로 QA 팀의 역할이라고 생각합니다.

또한 저희 팀은 자동화 작업도 꾸준히 이어가고 있습니다. 앞으로도 프로세스 최적화와 자동화를 통해 더 효율적이고 안정적인 품질 관리 방식을 만들어 가며, 그 과정 속에서 저 역시 더 나은 QA 엔지니어로 성장할 수 있기를 기대합니다.