버그 분석을 통해 버그를 예방하기

 

안녕하세요 원티드랩 QA팀 김명관 입니다.

원티드랩 에서는 QA가 스쿼드(목적조직)에 참여해 애자일한 개발환경에서 기획부터 배포에 걸친 스프린트 단위의 프로젝트를 수행합니다.

하지만 제가 원티드랩에 합류할 때 만 해도 팀의 인원이 부족해 스쿼드에 참여하지 못하고 있었죠. 차츰 인원이 충원 되고, 스쿼드에 하나 둘 합류하게 되면서 QA팀의 목표를 세우게 되었습니다.

 

 

Phase 1. 개발 환경에서 버그 검출률 높이기

QA가 스쿼드에 합류하기 전에는 개발 환경 테스트는 개발자 분들이 진행해 주셨고, QA는 스테이징 환경부터 참여하여 테스트를 진행하였습니다. 그렇다 보니 자연스럽게 스테이징 환경에서 버그 검출률이 높았죠.

문제는 QA가 스테이징 환경에서 테스트를 진행하는 기간에 개발자 분들은 이미 다음 프로젝트의 개발을 진행하고 있다는 점입니다. 스테이징 환경에서 많은 버그가 발견되면 다음 프로젝트의 개발과 이전 프로젝트의 버그 대응을 동시에 해야 합니다. 개발자 분들은 프로젝트 아이템 개발에 온전히 집중할 수 없게 되고 프로젝트의 지연, 부족한 개발 시간으로 인한 퀄리티 저하 등의 연쇄적인 문제들이 발생할 수 있습니다.

따라서 QA는 스쿼드에 합류하여 개발 환경에서 버그 검출률을 높이고 그것을 수정하도록 하여 이후 환경에서는 버그 검출과 수정에 대해 투자하는 시간을 최대한 줄여나가 현재 프로젝트에 더욱 집중할 수 있는 환경을 제공하는 것을 목표로 활동하게 되었습니다.

이를 위해 QA팀에서는 JIRA 버그 티켓 데이터, Python, Google Spread Sheet, Google Datastudio를 이용해 테스트 환경 별 버그 발생 현황을 추적할 수 있는 ‘버그 트렌드 대시보드’와 프로젝트 별 개발 및 싸이클 타임을 추적할 수 있는 ‘스프린트 생산성/품질 분석 리포트’를 활용하고 있습니다.

지난 1년 간 QA팀은 개발 환경에서 버그 검출률을 꽤 높일 수 있었습니다. QA가 스쿼드에 합류하기 전 후로 비교해 보자면 개발 환경에서 발견되는 버그 비율이 대략 20%대에서 60%대로 약 3배 정도 늘어나게 되었습니다.

이후, 저희는 두번째 목표를 세우게 되었습니다.

 

Phase 2. 프로젝트 간 전체적인 버그 개수 감소

팀 내부에서는 ‘Insprint-QA Phase 2’ 라고 부르는 두 번째 목표입니다.

개발 환경에서 버그 검출률을 높였다 하더라도 버그 자체가 너무 많다면 버그에 대응하기 위한 시간 또한 여전히 많이 필요합니다. 그러므로 프로젝트 기간 동안 발생하는 버그 개수 자체를 감소 시킬 수 있는 버그 예방 활동에 집중해 보기로 했습니다.

먼저 우리 프로젝트의 버그 발생 양상을 파악하고 있어야 합니다. JIRA 버그 항목에 ‘버그 속성’ 값을 추가하고 버그가 발생한 원인을 대략 몇 가지 기준으로 나누어 보기로 했습니다.

1. 요구사항 미비 : 요구사항 검토, 리뷰가 미비하여 발생하는 버그 또는 케이스의 누락.
2. 요구사항 미준수 : 개발 결과물이 요구사항을 충족하지 않아 발생한 버그.
3. 인티그레이션 버그 : 개발 산출물, 서비스의 통합 단계에서 발생한 버그.
4. 그 외 기술적 오류 : 구문 오류, 예외 처리 미비, 설정 오류 등으로 인해 발생한 버그.
5. 리그레션 버그 : 이전에 정상 동작 하던 영역이 기능 수정 또는 추가의 영향으로 발생한 버그.

 

 

위 기준에 따라 Sprint A에서 발생한 버그를 분류해본 결과 요구 사항 미준수로 인한 버그가 51%에 달했습니다.

버그 분류를 통해 현재 우리 스쿼드의 상황을 알 수 있게 되었고, 어떤 조치를 해야 할 지 알게 되었습니다.

요구 사항만 잘 준수 되어도 버그의 개수는 50% 감소시킬 수 있다!

저희 스쿼드 에서는 Insprint-QA Phase 2를 위해 ‘요구사항 미준수로 인한 버그를 최대한 줄여보자!’ 라는 활동에 집중하기로 했습니다.

요구사항이 지켜지지 않는 원인

우리는 요구사항을 잘 따라 개발 했다고 생각하지만, 요구사항이 불완전 하거나 기술적으로 불가능 하거나 요구사항을 오해 하거나 잊어 버리는 등의 이유로 개발 시 요구사항을 완벽하게 준수하지는 못하게 됩니다.

따라서 저희는 꾸준한 프로세스 개선을 통해 요구사항에 대한 이해를 맞춰보고, 생각을 모으려 하고 있습니다. 싱크업 미팅을 통해 기획, 디자인, 개발, QA가 모여 기획에 대한 기술적 검토와 더 좋은 아이디어를 논의합니다. 그리고 요구사항을 오해하지 않도록 QA가 작성한 테스트맵 리뷰를 통해 우리 모두 기획을 제대로 이해 했는지 검토하며 추가적으로 수정되어야 할 부분들을 체크하죠. 요구사항을 잊지 않기 위해 기획문서와 유저스토리 JIRA 티켓에는 Acceptance Test가 작성되어 있습니다.

다양한 리뷰 활동 중 싱크업 미팅과 테스트맵 리뷰를 통해 구성원 모두 한 자리에서 이해를 모으고 확인, 논의하는 절차를 거칩니다. 하지만 유저스토리 별로 JIRA 티켓에 작성 된 Acceptance Test는 개발 산출물이 따라야 할 최소한의 가이드를 제공하고 있음에도 이것에 대해 검토, 논의, 수행하는 시간을 별도로 가지지 못했습니다.

P1 Checklist 도입

 

Acceptance Test에서 놓치는 부분을 보완하기 위해 P1(Priority) Checklist를 만들어 유저스토리 티켓 별로 산재되어 있는 Acceptance Test를 하나의 시트에 모으고, 좀 더 상세하며 우선순위가 높은 항목을 추가로 작성하여 개발 중에 확인해야 할 사항들을 기재한 리스트를 제공하게 되었습니다.

P1 Checklist로써 개발자 분들께 바라는 점은 이렇습니다.

1. 체크리스트를 테스트 수행 대상으로 생각하지 않았으면 좋겠습니다.
2. 가볍게 내가 놓친 부분이 없는지 확인하는 용도로 활용해 주셨으면 좋겠습니다.
3. 개발 기간에 걸쳐 언제든 와서 체크리스트를 확인해 가며 개발이 되면 좋겠습니다.
4. P1 Checklist를 도입한 결과로 요구사항 미준수로 인한 버그가 줄어들었으면 좋겠습니다.

P1 Checklist 도입 결과

 

Sprint B에서 처음으로 P1 Checklist를 공유 드렸고, 제가 바라는 몇 가지 사항을 안내해 드렸습니다.

체크리스트는 테스트 대상이 아닙니다. 개발 기간 전체에 걸쳐 언제든 와서 확인해 보시고 빠뜨린 부분이 없는지 확인하는 용도로 사용해 주시면 됩니다.

도입 결과 요구사항 미준수로 인한 버그 비율이 오히려 4% 증가하게 되었습니다. P1 Checklist는 처음 시도해본 방법이고, 작업 영역의 특성에 따라 이슈 발생 양상에 차이가 있음을 염두에 두고 몇 번의 스프린트를 더 진행해 보았습니다.

하지만 크게 달라지는 점 없이 여전히 요구사항 미준수 버그 비율은 50% 초반을 유지했습니다.

 

P1 Checklist 수행 방법의 변화

개선되지 않는 방식을 계속 유지한다면 P1 Checklist를 작성하는 제 시간과 의도가 무의미 해지고 문서가 존재할 이유가 없습니다.

저는 아직 P1 Checklist를 잘 활용한다면 요구사항 미준수 버그를 줄일 수 있을 거라는 기대가 있었고 더 활용해 보고 싶었기에 원인을 파악하기로 했습니다. 개발자 분들께 P1 Checklist를 어떻게 활용하고 계신지 여쭤보았습니다.

개발자 분들의 답변을 정리해보면

개발 중에 Checklist를 확인 하기 위한 짬을 내기 어려웠고, 사실상 개발이 끝난 뒤 1일~1.5일 정도 체크리스트를 확인하는 방식으로 활용하고 있었습니다.

답변에 기반하여 P1 Checklist의 수행 방법을 바꿔보기로 했습니다.

저희 스쿼드에서는 보통 스프린트의 마지막 3일 동안 DevQA(개발 환경 통합 테스트)를 진행하고 있습니다. 그 중 DevQA의 첫 번째 날을 개발자 분들이 각자 개발하신 영역에 대해 P1 Checklist를 수행하며 요구사항에 대한 완성도를 높이는 날로 활용할 수 있도록 변경해 보았습니다.

개발 일정이 하루 늘어나고, DevQA 일정이 하루 줄어들게 되는 방법이지만 개발자 분들이 P1 Checklist로써 효과를 보게되 나중엔 습관적으로 P1 Checklist를 찾고, 수행하게 될 수 있도록 하기 위해 의도적으로 날짜를 조정하였습니다.

새로운 P1 Checklist 수행 방법에 대한 결과

 

Sprint C에서 처음으로 새로운 방식을 도입하여 결과를 살펴 보았습니다.

요구사항 미준수 비율은 36%로 기존 스프린트에 비해 약15% 이상 감소하게 되었습니다. 버그의 비율 뿐 아니라 스토리 점수 별 버그 발생 개수 또한 약 4% 감소하였습니다.

 

가장 마지막에 진행했던 Sprint D에서는 요구사항 미준수 비율이 26%로 이전 방식에 비해 무려 20% 가량 줄었으며, 전체적인 버그 개수 또한 준수하게 줄어들게 되었습니다.

Sprint D를 진행하며 얻게 된 결과가 한가지 더 있었습니다. 개발자 분들께 P1 Checklist를 수행한 결과를 Pass, Fail로 표시해 달라고 요청 드렸는데요, 모든 체크리스트 항목에 수행 결과를 적어주신 개발자 분의 플랫폼에서는 요구사항 미준수 이슈가 0건 이었으며, 가장 적은 양의 결과를 적어주신 개발자 분의 플랫폼에서는 요구사항 미준수 비율이 가장 높았습니다.

약간은 조삼모사 같은 방법을 활용했지만 결과적으로 P1 Checklist가 적극적으로 활용된다면 버그 개수와 요구사항 미준수 비율을 줄일 수 있다는 것을 약 4.5개월에 걸쳐 트래킹 하여 확인할 수 있었습니다.

또한 같은 체크리스트라도 얼마나 꼼꼼히 수행 되었는지에 따라 결과에 확실한 차이를 보이고 있다는 점도 재미있었습니다.

 

마치며

지금 당장은 개발자 분들이 어떻게든 체크리스트를 수행하실 수 있도록 유도하는 방식을 취하고 있습니다. 하지만 최종적으로는 개발자 분들이 스스로 체크리스트를 찾고, 리뷰하며, 수행하실 수 있는 개발 환경을 조성하도록 해야 할 것이라고 생각됩니다. 그리고 아마 그것이 제 다음 과제가 되지 않을까 라는 생각을 하고 있습니다.

QA 업무를 하며 제가 해결해야 할 다양한 문제에 맞닥뜨렸을 때, 저 혼자 해결하려 했다면 좋은 결과를 얻을 수 없었을 것입니다.

우리 스쿼드의 현황을 파악할 수 있도록 버그 속성을 추가해 주신 원티드랩 QA팀 팀장 승훈님, P1 Checklist 도입, 변경 과정에서 귀찮게 해드렸음에도 흔쾌히 응해주시고 체크리스트 도입에 적극적으로 도와주신 UGC 스쿼드 메이커스 분들 모두 감사드립니다.

UGC SQ의 기둥이었던 지영님 수고 많으셨습니다. 앞으로도 계속 여러분들이 최대한 귀찮지 않을 방법들을 찾아 더 좋은 제품을 위한 노력을 계속 하겠습니다.

감사합니다.