Grab의 Shift-left 테스트 전략

협업 프로세스의 변경을 통해 테스트 비용을 낮추고, 소프트웨어 품질을 향상한 사례입니다. 테스트 단계를 왼쪽으로(앞으로) 가져오는 것만으로도 생산성과 품질의 향상을 가져올 수 있다는 게 너무나 인상깊었어요. 새로운 기술에 돈을 쓴 게 아니라 함께 일하는 방식을 바꿔보는 것만으로도 우리 제품이 좋아진다는 거잖아요.

Grab의 성장과 함께 급증한 테스트 비용

• Grab은 모빌리티 뿐만 아니라 음식 배달 등 아시아의 슈퍼 앱이 되어가며 많은 서비스들이 생겨났고, 테스트 비용이 증가하기 시작했습니다.

• 이전에는 통상적인 방식(Planning - Design - Development - Testing - Release - Monitoring - Analysis)으로 개발 완료 후 QA에서 테스트하고 sign-off를 통해 앱을 릴리즈했어요. 하지만 오히려 많은 버그를 일으키고 테스트에 오랜 시간이 소요된다는 것을 발견했습니다.

• Shift-left 테스트 전략을 적용해 개발이 완료된 후 테스트를 하는게 아니라, 초기단계인 플래닝과 디자인 단계부터 테스팅을 접목했어요. 아래 3가지 방법을 통해 업무 프로세스에 적용했습니다.

  
  

1. 개발자가 인수 테스트(Acceptance Test) 수행

• 인수테스트는 개발이 완료된 후 QA에 의해 시행되었는데, 이때 버그가 발견되면 수정하는 비용이 훨씬 비쌌어요. 특히 대부분이 불분명한 요구사항, 부족한 테스트 케이스로 인한 것이었습니다.

• 이를 개선하여, 개발이 시작되기 전에 QA가 테스트 케이스를 작성하고 개발자들이 인수 테스트를 수행하며 개발을 완료하게 됩니다.

• 일종의 TDD와 비슷하다고 느꼈는데요. 개발자가 단위 테스트를 작성하고 비즈니스 로직을 구현하는 게 코드 레벨의 TDD라면, 제품 주기의 레벨에서 QA가 먼저 인수 테스트 케이스를 작성한 후 개발자가 이를 만족하는 개발을 수행해요. 코드 레벨이 아닌 협업 레벨에서도 TDD를 적용한 것 같아서 정말 신선했어요.

• 인수테스트가 먼저 작성되고 나면, 불분명한 요구사항이 더욱 명확하게 정의될 수 있고(테스트 케이스를 작성해야하니 명확하게 정의될 수 밖에 없다!) 테스트 단계에 돌입하기 전에 개발자들이 스스로 버그를 찾아내 수정했습니다. 개발자 입장에서도 컨텍스트 스위칭 없이 바로 버그를 수정할 수 있으니 훨씬 빨리 해결할 수 있게 되었죠.

2. DoR(준비 정의)과 DoD(완료 정의)

• Shift-left 테스트를 업무 프로세스 상에 녹이는 방법으로 DoR(Incorporate Definition of Ready)과 DoD(Definition of Done)를 정의했습니다.

• DoR은 스프린트가 승인되기 전에 티켓(에픽/스토리/태스크)에 충족해야 되는 명시적인 기준입니다. DoD은 티켓이 완료 또는 상태가 변경되기 전에 충족되어야할 기준입니다.

• 이 2가지는 애자일 표준 프로세스의 일부인데요. Grab에서는 여기에 품질과 테스트에 대한 기준을 구체적으로 정의했다는 의미같아요. 글로 예측해보건데, DoR은 품질 기준을 명확하게 세운다, DoD로 모든 인수테스트가 성공해야 한다가 될 수 있을 것 같습니다.

• 이 프로세스를 채택한 팀의 경우 릴리즈 속도와 품질이 향상되어 계획했던 기능의 90%를 포함할 수 있었고, 수동 테스트 시간이 단축되었습니다.

3. 테스트 전략의 밸런스

• QA의 작업을 효율화하는 전략도 함께 적용했어요. UI 테스트를 자동화하고, 백엔드 통합 테스트, E2E(End to End) 테스트를 개선하는 등 수동 테스트를 최소화하기 위해 노력했습니다.

Shift-left 테스트 적용 이후

• Grab에서는 Shift-left 테스트를 실행한 이후 릴리즈 속도는 보장된 상태로 앱의 품질을 향상시킬 수 있었어요. 릴리즈 후 발견되는 Major/Ciritical 버그들은 60% 줄었고, 개발 단계에서 발견되는 Major/Critical 버그들은 40% 줄었습니다.