Quality Boosting
테스트가 없는 테스트 위하여
꿈입니다! 깨어나세요. 용사여!커버리지, 프로그레스, 패스율 100%
오늘도 열심히 테스트를 수행하는 많은 QA가 바라는 테스트 결과 리포트의 모습입니다.
혹시 알 수 없는 불안감이 느껴지십니까?
프로그래머의 딜레마당연히 QA가 테스트를 진행하며 버그가 있기를 바라는 것은 아닙니다. 하지만 프로그래머의 딜레마처럼 기존의 경험과 통계에서 오는 불안감일 수 있습니다.
이제 본론으로 돌아와서 커버리지, 프로그레스, 패스율 100%는 정말 달성이 불가능한 꿈과 같은 이야기일까요? 꿈과 같은 이야기를 목표로 테스트를 하지 않고 테스트를 끝낼 수 있는 Boosting에 대하여 한번 이야기를 해보려 합니다.
이를 위하여 우리가 진행하는 테스트를 예로 들어 보겠습니다.
Case 1.
서비스 오픈 전 빌드의 단말 설치 테스트가 예약되어 있습니다.
이후 예측 가능한 진행 과정은 Android 단말에서 테스트를 위한 APK가 발행되고 QA에게 전달될 겁니다.
이제 테스트 진행을 위해 Boosting과 Testing 영역으로 구분하여 준비와 진행을 해 보겠습니다.
단말 설치 테스트 순서도> Boosting
1. 해당 프로덕트의 서비스 대상(지역, 연령, 성별 등)을 확인합니다.
2. 해당 프로덕트의 최소 서비스 가능 단말 사양을 확인합니다.
3. 확인된 부분을 기반으로 적절한 빌드 방식(예시를 위해 AAB 방식)을 요청합니다.
> Testing
4. 배포된 빌드의 설치 테스트를 진행합니다.
위의 과정에서 Boosting은 어떠한 의미일까요?
아니 그전에 일반적인 과정으로 APK가 배포되었다면 어떠한 상황이 발생했을까요?
아마도 QA는 각 사양의 단말에서 테스트를 진행하고 설치 불가, 용량 등의 이슈를 발견 후 유관부서에 리포트를 배포하여 AAB 방식으로 재 빌드를 요청하는 과정을 수행하게 됩니다.
결과적으로 AAB 방식의 빌드가 테스트되고 라이브에 배포되기 때문에 동일할 수 있습니다.
하지만 퀄리티 관점에서도 동일한 결과일까요?
우선 우리는 Boosting 과정을 통해 한 번의 재 빌드를 방지하였습니다.
한 번의 재 빌드 방지는 한 번의 BVT 또는 BAT와 한 번의 리그레이션 테스트 방지를 의미합니다.
해당 테스트를 수행하지 않은 상태에서 테스트를 끝낸 셈입니다.
Case 2.
이번에는 추가 데이터 다운로드(CDN) 기능 관련 테스트를 진행해보겠습니다.
CDN 기능 테스트 순서도> Boosting
1. 해당 테스트 진행 방식과 필요 환경을 공유합니다.
a. 클라이언트를 실행 후 추가 데이터 A 다운로드 확인
b. 이후 추가 데이터 B 연결(교체) 요청
c. 기존 리소스 변경 및 신규 리소스 적용 확인
2. 공유 내용을 기반으로 두벌의 데이터 셋을 요청합니다.
> Testing
3. 요청한 데이터 셋을 활용하여 테스트를 진행합니다.
이번 Boosting은 어떠한 역할을 했을까요?
2벌의 리소스가 준비되어 있지 않았다면 QA는 원하던 커버리지의 테스트가 불가능하고 추가 리소스 준비 작업을 요청하게 됩니다.
Boosting 과정을 통해 QA는 1회 차 테스트 과정에서 테스트 중단 없이 커버리지와 프로그레스 상승을 기대할 수 있었습니다.
이와 함께 개발 담당자의 현재 작업(또는 현재 스프린트)이 중단되지 않기 때문에 작업 중이던 항목에서의 휴먼 에러 발생이 예방되어 버그의 사전 차단이 가능해졌습니다.
물론 QA가 아닌 프로덕트에 참여하는 누군가가 먼저 빌드 방식에 대한 의견을 제시할 수도 있습니다. 이와 함께 QA가 이러한 업무 영역까지 진행을 해야 되는가? 이는 다른 직군의 업무 영역이 아닌가?라는 생각이 들기도 합니다.
맞습니다. 굳이 QA가 이러한 역할을 수행하지 않아도 결과적으로 테스트는 완료가 가능합니다. 하지만 이를 통해 커버리지, 프로그레스, 패스율 100%를 목표로 테스트를 하지 않고 테스트를 완료하며, 프로덕트의 구성원과 넓은 커뮤니케이션을 통해 서비스의 속도를 높여 퀄리티를 높일 수 있는 방법이 아닐까 생각해 봅니다.
또한, 여기에 긍정을 한 스푼 추가해보면 자동화보다 더욱 간편한 리소스 절약이 될 수도 있습니다.
기존에 QA가 수행하는 업무에 없던 새로운 업무는 절대 아닙니다.
우리는 익숙하게 기획 리뷰, 테스트 플랜 공유를 통해 이슈를 사전에 차단하고 빌드 리턴을 줄여 프로덕트의 퀄리티를 상승시키고 있었습니다.
이에 Boosting이라는 이름으로 기존의 프로세스에 우리의 다양한 테스트 경험을 첨가하여 프로덕트를 가속시켜 나가는 과정을 만들어 나가고 싶습니다.
