안녕하세요 원티드랩 QA팀 김명관 입니다.
원티드랩 에서는 QA가 스쿼드(목적조직)에 참여해 애자일한 개발환경에서 기획부터 배포에 걸친 스프린트 단위의 프로젝트를 수행합니다.
하지만 제가 원티드랩에 합류할 때 만 해도 팀의 인원이 부족해 스쿼드에 참여하지 못하고 있었죠. 차츰 인원이 충원 되고, 스쿼드에 하나 둘 합류하게 되면서 QA팀의 목표를 세우게 되었습니다.
QA가 스쿼드에 합류하기 전에는 개발 환경 테스트는 개발자 분들이 진행해 주셨고, QA는 스테이징 환경부터 참여하여 테스트를 진행하였습니다. 그렇다 보니 자연스럽게 스테이징 환경에서 버그 검출률이 높았죠.
문제는 QA가 스테이징 환경에서 테스트를 진행하는 기간에 개발자 분들은 이미 다음 프로젝트의 개발을 진행하고 있다는 점입니다. 스테이징 환경에서 많은 버그가 발견되면 다음 프로젝트의 개발과 이전 프로젝트의 버그 대응을 동시에 해야 합니다. 개발자 분들은 프로젝트 아이템 개발에 온전히 집중할 수 없게 되고 프로젝트의 지연, 부족한 개발 시간으로 인한 퀄리티 저하 등의 연쇄적인 문제들이 발생할 수 있습니다.
따라서 QA는 스쿼드에 합류하여 개발 환경에서 버그 검출률을 높이고 그것을 수정하도록 하여 이후 환경에서는 버그 검출과 수정에 대해 투자하는 시간을 최대한 줄여나가 현재 프로젝트에 더욱 집중할 수 있는 환경을 제공하는 것을 목표로 활동하게 되었습니다.
이를 위해 QA팀에서는 JIRA 버그 티켓 데이터, Python, Google Spread Sheet, Google Datastudio를 이용해 테스트 환경 별 버그 발생 현황을 추적할 수 있는 **‘버그 트렌드 대시보드’**와 프로젝트 별 개발 및 싸이클 타임을 추적할 수 있는 **‘스프린트 생산성/품질 분석 리포트’**를 활용하고 있습니다.
지난 1년 간 QA팀은 개발 환경에서 버그 검출률을 꽤 높일 수 있었습니다. QA가 스쿼드에 합류하기 전 후로 비교해 보자면 개발 환경에서 발견되는 버그 비율이 대략 20%대에서 60%대로 약 3배 정도 늘어나게 되었습니다.
이후, 저희는 두번째 목표를 세우게 되었습니다.
팀 내부에서는 ‘Insprint-QA Phase 2’ 라고 부르는 두 번째 목표입니다.
개발 환경에서 버그 검출률을 높였다 하더라도 버그 자체가 너무 많다면 버그에 대응하기 위한 시간 또한 여전히 많이 필요합니다. 그러므로 프로젝트 기간 동안 발생하는 버그 개수 자체를 감소 시킬 수 있는 버그 예방 활동에 집중해 보기로 했습니다.
먼저 우리 프로젝트의 버그 발생 양상을 파악하고 있어야 합니다. JIRA 버그 항목에 ‘버그 속성’ 값을 추가하고 버그가 발생한 원인을 대략 몇 가지 기준으로 나누어 보기로 했습니다.
1. 요구사항 미비 : 요구사항 검토, 리뷰가 미비하여 발생하는 버그 또는 케이스의 누락. 2. 요구사항 미준수 : 개발 결과물이 요구사항을 충족하지 않아 발생한 버그. 3. 인티그레이션 버그 : 개발 산출물, 서비스의 통합 단계에서 발생한 버그. 4. 그 외 기술적 오류 : 구문 오류, 예외 처리 미비, 설정 오류 등으로 인해 발생한 버그. 5. 리그레션 버그 : 이전에 정상 동작 하던 영역이 기능 수정 또는 추가의 영향으로 발생한 버그.