Dev-QA, 원티드랩 전체 팀 테스트 문화
안녕하세요, 원티드랩 QA팀 이승훈입니다.
원티드랩에서는 매 스프린트의 시스템 통합 테스트 과정에서 Dev-QA라는 활동을 수행합니다. 스쿼드/팀 구성원 모두가 함께 하는 일종의 테스트 세션인데요. 원티드랩만의 전체 팀 테스트(Whole Team Test) 문화를 이끄는 주요한 활동으로 자리잡은 이 세션에 어떠한 테스트 전략과 절차가 담겨있는지 소개드리도록 하겠습니다.
Dev-QA라는 것은 제가 아는 한 어느 테스트 이론에 명시된 그런 개념이나 용어는 아닙니다. 제가 원티드랩에 입사하기 이전부터도 우리 조직에서 쓰여오던 우리만의 용어입니다. 그 단어에 테스트 전략과 절차를 담아 지금과 같은 형태의 테스트 액티비티가 되었는데요.
2주 기반의 스프린트를 예를 들어봤을 때…
- 기획과 디자인 작업이 스프린트 이전부터 선행되어 들어가고 스프린트 초반까지 보정, 상세화해 가는 과정이 진행되게 됩니다.
- 개발은 개발 검토 작업부터 본격적인 개발 작업, 그리고 정도의 차이는 있지만 단위테스트를 붙히고 개발자 테스트를 완료해서, 보통 둘째주 수요일 또는 목요일 쯤에 개발완료를 하게 됩니다.
- 테스트는 스프린트 시작과 동시에 분석/조사하는 정적 테스트 과정 거치고 테스트 설계(테스트맵, 체크리스트를 만드는 작업) 및 부분적인 기능 테스트부터 시스템 통합 테스트까지 하게 됩니다.
- 시스템 통합 테스트 과정에서 발견된 버그는 수정, 확인 테스트하는 과정까지 거치게 됩니다.
이런 일련의 과정을 통해서, 매 스프린트마다 최종적으로 즉시 배포 가능한 상태의 개발 산출물을 만들어 내는데요. Dev-QA는 개발이 완료되고, 시스템 통합 테스트가 시작되는 시점에 일어나는 테스트 활동입니다.
조금 더 구체적으로 Dev-QA는 다음과 같이 진행됩니다.
왜 이렇게 하는지를 이해하기 위해선 먼저 완료기준 (Definition of Done)에 대한 이해가 필요합니다.
앞서 하나의 스프린트를 통해서 즉시 배포 가능한 상태의 개발 산출물을 만들어 낸다라고 했는데요. ‘즉시 배포 가능한 상태의 개발 산출물’이라 함은 다음과 같은 완료기준을 만족하는 것으로 우리 조직에서는 약속되어있습니다.
스프린트의 결과물이 이러한 완료기준을 만족하기 위해서, 테스트 관점에서는 두 가지 목표를 세울 수 있을 것입니다.
기능 & 비기능 영역의 테스트 커버리지 ↑
버그 해결 완료율 ↑
중요한 것은 개발 완료일정을 감안하면 이것을 최대 3일 이내에 완수해야한다는 것이죠.
기본 테스트 케이스 혹은 시나리오에 OS/브라우저별 호환성 검증까지 감안하면 한 명의 역량으로는 주어진 기간 내에 이 모두를 수행하기는 어렵습니다. 설령 완료한다고 하더라도 버그 수정, 확인 테스트에 필요한 골든 타임을 놓칠 가능성이 큽니다.
그렇기 때문에 우리는 빠른 시간 안에 중요한 영역부터 테스트 커버리지를 확보하기 위해 모두가 참여하여 테스트를 합니다.
※ 모든 구성원들이 온라인/오프라인 상으로 함께하기 때문에 발견된 이슈에 대한 즉각적인 논의가 가능해집니다. 이슈 여부/원인을 확인하는데 핑퐁게임을 덜하게 되고 이는 ‘시간’ 곧 ‘버그 수정 비용’을 줄일 수 있다는 것입니다.
※ 테스트를 함께한다는 것은 테스트 아이디어를 전파하기 위한 목적도 있습니다. 조직 구성 상 그리고 프로세스 상, 모든 개발 산출물을 QA가 혼자 검증하기에는 한계가 있습니다. 그렇기 때문에 구성원 모두가 테스트 아이디어를 가지고 각자의 영역에서 품질을 스스로 쌓아갈 수 있는 역량이 필요합니다. 모두가 함께하는 Dev-QA 세션을 통해서 QA가 가진 테스트 아이디어와 방법들이 전파될 수 있습니다.
※ 테스트의 영역을 나눌 때, 본인의 개발물을 본인이 검증하지 않도록 하는 이유는 개발자가 자기의 개발물을 테스트할 때 생길 수 있는 확증편향, 무주의 맹시와 같은 심리적인 요인을 최소화하기 위함입니다.
확증편향 : 원래 가지고 있는 생각이나 신념을 확인하려는 경향. 흔히, “보고싶은 것만 보고 믿고 싶은 것만 믿게되는” 경우
무주의 맹시 : 특정한 것에 너무 집중하여 다른 것들을 보지 못하는 경우
※ 다함께 테스트한다는게 개발자 입장에서는 자신의 결과물을 공개적으로 평가받는 것으로 느껴져 부담스러울 수도 있지만, 버그로 누군가를 평가하거나 비난하지 않는 건전한 문화를 가졌기 때문에, 이런 부분까지도 책임감을 고취시킬 수 있는 심리적 장치로 이용합니다.
※ 애자일에서는 스프린트의 생산물을 이해관계자와 데모하는 인수 테스트라는 단계가 있습니다. 보통 사업부를 대표하여 PO가 최종 승인자의 역할을 맡게 되는데요. PO가 Dev-QA에 함께 참여함으로써 인수테스트의 효과까지도 함께 기대할 수 있습니다.
마치며
생각해 보면, 지금과 같은 Dev-QA가 자리잡히기 전에는 QA가 없는 경우에 테스트를 어떻게 진행해야할지 몰라 검증과정이 허투루 진행되는 경우가 많았고, 배포 테스트 과정에서 뒤늦게 발견된 버그를 대응하느라 스프린트 작업 시간을 다 뺏기는 경우도 잦았습니다. 그리고 이런 과정이 쳇바퀴 돌듯 계속 반복됐었습니다.
이제 Dev-QA는 원티드랩 제품실 안에서 QA가 있든 없든 주체적으로 이끌어갈 수 있는 활동으로 자리잡았습니다. 덕분에 빠른 시간 안에 품질을 확보할 수 있고 / 버그 수정비용을 낮출 수 있고 / 좀 더 마이너한 시나리오나 비기능 영역까지도 챙길 수 있게 됐고 / 자동화와 같은 테스트 고도화 영역까지 고려해 볼 수 있는 상황이 되었습니다.
품질과 생산성을 높일 수 있는 원티드랩 만의 전체 팀 테스트 문화를 대표하는 활동이라고 얘기할 수 있습니다.
