개발자 주도 통합 테스트의 매운맛 보기

안녕하세요! 원티드랩 QA팀 김명관입니다.
이번에는 스프린트의 후반에 많은 버그가 발견되는 문제를 해결하기 위해 같은 팀의 김소희님과 함께 시도했던 "개발자 주도 통합 테스트"와 그 결과에 대해 이야기해 보려고 합니다.
새로 개발한 기능을 배포하기 전에 개발자 분들이 스스로 자신이 만든 제품을 테스트하도록 하는 과정에서 이론으로만 알던 내용을 직접 경험할 수 있었습니다. 그리고 이 방법은 생각보다 매운맛이었어요! 테스트를 넘어 더 많은 것을 배울 수 있는 좋은 기회가 되었습니다.

---

문제 발견

스프린트를 진행하며 공통적으로 버그의 개수가 굉장히 많다는 것을 알게 되었습니다. 버그를 많이 찾아 수정했다는 것은 배포 전에 리스크를 제거했다는 의미이기도 합니다. 그러나 찾아낸 버그를 살펴보니 정작 그 많은 버그들 중 심각도가 높은 버그는 10% 미만으로 굉장히 적었습니다.
심각도가 낮은 버그를 찾는데 시간을 많이 쓴다면 더 중요한 버그를 찾고, 수정하는데 집중할 수 없다는 문제가 발생합니다. 그리고 스프린트 후반에 버그를 찾게될수록 놓치는 버그가 발생하기 쉬워 버그는 유저에게 전달될 가능성이 높아집니다.

낮은 심각도의 버그가 테스트 단계까지 지속된다.
버그 발견 시점이 너무 늦어 유저에게 전달될 위험이 높다.
나중에 발견된 버그를 수정하는데 많은 리소스가 소비된다.

 
소희님과 저는 이런 문제들을 인식하게 되었습니다.

---

버그 거름망

저희가 생각한 솔루션은 중요도가 높지 않은 버그를 배포 전에 미리 걸러내는 것이었습니다. 테스팅 원칙에는 조기에 테스트를 시작하라는 말이 있죠. 가능한 빠른 시점에 테스트를 수행하라는 것입니다. 이미 개발이 완료된 제품보다 개발을 시작하기 전에 미리 버그를 찾아내 수정하는 것이 훨씬 저렴하게 버그를 수정할 수 있기 때문입니다.
그러나 이번에는 QA가 직접 테스트를 하는 것이 아닌 제품의 개발자 분들의 도움을 받아보았습니다. 문서로 작성된 요구사항을 구현하는 과정에서 구현된 제품을 가장 먼저 접할 수 있는 것은 제품을 직접 구현하는 개발자 분들일겁니다. 따라서 개발자 분들이 제품을 테스트 해주신다면 제품이 구현된 이후의 시점에서 가장 빠르게 테스트가 진행될 수 있을 거에요.

체크리스트의 추가 활용

기존에 저희는 기능 요구사항과 디자인 요구사항을 간단하게 정리한 체크리스트를 개발자 분들께 제공하고 있었습니다. 해당 체크리스트를 참고하여 기능을 구현하실 수 있도록 활용했습니다. 이미 잘 정리된 체크리스트가 제공되고 있었으니 체크리스트를 기반으로 한발 더 나아가 테스트를 요청드렸습니다.
 

구현된 기능이 체크리스트와 동일한지 테스트 한 뒤 배포해 주세요.

 
마침 개발자 분들도 체크리스트를 기반으로 테스트 하는 것에 익숙한 상태였습니다. 테스트 시점을 조금 더 앞당긴 것 뿐이죠. 몇달 간 체크리스트를 기반으로 개발자 주도 통합 테스트를 진행했습니다. 그리고 며칠 전 그 결과를 정리해 보았는데요, 아주 놀라운 결과를 보게 되었습니다.

---

이 차트는 해당 팀의 월간 버그 추이입니다. 개발 작업이 완료된 후 공식 테스트 일정 내에 발생한 버그의 개수를 확인해 보았는데요 1일 당 3개 이상의 버그가 발생했던 1월에 비해 8월에는 0.3개 수준으로 약 90% 감소했습니다.
체크리스트를 이용해 개발자 주도 통합 테스트를 시작한 시점은 6월이었는데요. 차트에서도 6월을 기점으로 발견된 버그 개수가 확 줄어든 것을 볼 수 있었습니다.
QA가 제공하는 간단한 체크리스트를 따라서 개발자 분들이 배포 전에 점검을 한번씩만 해주셔도 이렇게 확실한 효과를 볼 수 있었습니다. 이 이상을 바라는 것은 욕심이다 싶을 정도로요.

이 차트는 해당 작업에서 발견한 버그 중 심각도가 높은(P2 이상) 버그 비율의 추이입니다. 1월에는 약 2%에 불과했지만 8월에는 약 81%로 비율 상 약 4000% 상승하게 되었습니다. 4000%라는 높은 숫자는 해당 시기에 진행했던 프로젝트의 난이도나 구성원들의 상태 등 살펴볼 요인이 더 많겠지만 어쨌든 심각도가 높은 버그를 더 많이 찾게 되었다는 것을 알 수 있습니다.
버그 개수 차트와 마찬가지로 개발자 주도 통합 테스트를 시작한 6월부터 심각도가 높은 버그의 비율이 높아지고 있습니다.

---

레슨 런

이른 시점에 테스트를 시작해야 한다거나 개발자 분들이 테스트를 한 뒤에 공식 테스트 프로세스가 시작되어야 한다거나 하는 얘기들은 QA 분들이라면 모두 알고 계실겁니다. 저와 소희님도 알고 있었구요. 하지만 정신없이 돌아가는 스프린트 안에서 이것을 직접 시도해 보기란 쉽지 않았습니다. 기존 프로세스에 손을 대서 실험해볼 정도로 가치있는 일인지 확신이 없기 때문이죠. 그러나 이론으로만 알고있던 내용을 저희가 직접 실무에 적용해본 결과 효과가 좋다 못해 아주 매운맛이었음을 알게 되었습니다.
어떤 개발자 분들은 테스트의 중요성을 알고 있지만 개발 작업하기도 바쁘기 때문에 테스트까지 할 시간은 없다고 하기도 합니다. 하지만 배포 전에 마지막 점검을 해주신다면 개발 일정동안 발생하는 버그 개수 자체가 줄어들게 됩니다. 수정해야 할 버그 자체가 없으니 수정 비용이 줄어들게 되겠죠. 결국 개발 작업 시간을 더 벌 수 있게 된다는 것을 알게 되었습니다.
QA의 입장에서도 그동안 우리가 찾아냈던 버그의 상당수는 발생하지 않을 수 있는 버그였다는 사실을 깨달았습니다. 그리고 수많은 심각도가 낮은 버그를 처리하느라 정작 중요한 지점이 충분히 테스트 되지 못하고 있었다는 것도 알게 되었습니다. 

---

마무리

며칠 전 다 함께 노력해주신 덕에 버그 추이가 굉장히 좋아졌다는 소식을 소희님께서 해당 팀에 전달해 주셨고 다들 좋아해 주셨다는 얘기를 들었습니다. 개발자 테스트의 중요성과 효과를 알 수 있는 좋은 기회가 되었으리라 생각됩니다. 이런 경험으로부터 조직 전반에 걸친 좋은 품질 문화가 퍼져나가기를 바랍니다!
그리고 전체적인 버그의 개수가 줄고 그 중에서 심각도가 높은 버그의 비율이 높아지는 것이 저희의 목표였습니다. 그런데 혹시나 싶어 시도해본 첫번째 방법으로 확실한 효과를 볼 수 있어서 너무 다행입니다. 더불어 흔쾌히 협조해주신 개발자 분들께도 너무 감사드립니다.
같이 고민하고 직접 실행해주신 소희님도 고생 많으셨고 좋은 결과를 볼 수 있도록 주도해주셔서 너무 감사드려요!