- 매주 배포하는 스타트업 환경에서 어떻게 일해야 효율적일까?
- 헤이딜러에서 QA팀이 일하는 방식을 소개합니다.
안녕하세요.
피알앤디컴퍼니 QA Engineer 이동언입니다.
헤이딜러는 고객용, 딜러용, 평가사용, 폐차, 딜러 콜, 평가사 콜 6가지 서비스를 운영하고 있습니다.
PRND에서는 1주일 간격으로 배포를 진행하고 있는데요, 이러한 짧은 배포 주기를 유지하기 위해서는 효율적으로 일하는 방식이 매우 중요합니다. 그래서 오늘은 저희 팀의 QA 업무 프로세스를 소개해 드리려고 합니다.
대부분의 QA팀에서는 기획 공유 후 QA 버전을 전달받기 전까지 Test Case를 준비 후 테스트를 진행하는 방식을 메인 테스트 기법으로 활용하고 있지만, PRND는 스타트업 특성상 빠른 배포 주기로 운영되고 있어 기획 공유 단계부터 앱이 스토어에 배포되기까지 빠르면 하루 만에 완료되어야 하는 상황도 발생될 수 있기에 Check List를 활용한 탐색적 테스트(Exploratory Test)를 적극 활용하고 있습니다.
탐색적 테스트는 도메인 지식과 경험을 활용하여 테스트를 설계하고 실행하는 방법으로 모든 프로덕트의 기능과 UX/UI를 모두 인지하고 있어야 테스트 기법을 효율적으로 활용할 수 있습니다. 그래서 작은 변경으로 개선되는 피쳐라도 기획 공유 회의를 QA팀 모두가 참석하고 있습니다.
[ Work Flow ]
전체적인 업무의 흐름은 위 이미지와 같이 진행됩니다.
각 단계마다 수행되고 있는 일들에 대해서 설명드리겠습니다.
[ 기획 공유 ]
기획 공유 전 기획서와 시안을 기반으로 사용자(User) 관점에서 어색하다고 느껴지는 부분과 리스크를 분석하고 추가/수정/삭제가 필요한 케이스와 예외 케이스가 발생했을 때 어떻게 결과가 동작하고 보여야 하는지 사전에 확인합니다.
기획이 확정되고 시안이 완성되면 기획 공유(kick-off) 회의를 진행합니다.
주요 내용은 피쳐의 목적 / 문제 / 목표 / 해결 방안과 변경 및 추가 / 수정 / 삭제되는 기능에 대해 논의하고 있습니다. 이 과정이 정상적으로 이루어지지 않는다면 사전에 충분히 알 수 있는 내용들을 QA 진행 단계에서 질문하고 답변 받는 불필요한 커뮤니케이션 비용이 발생되어 예정된 기간 안에 QA를 완료하지 못하여 배포가 미뤄지는 상황까지 발생할 수 있습니다.
[ Test Plan 준비 ]
기획 공유(kick-off)가 완료되면 팀 내에서 담당자를 선정하고 담당자는 Test Plan을 수립합니다. 기획서와 시안을 기반으로 하여 요구사항을 확인하고, 이를 기반으로 Test Case나 Check List를 작성합니다. 형식에 맞춰 최소한의 내용으로 명확한 테스트 절차와 기대 결과를 작성하여 프로젝트에 참여하지 않는 구성원도 이해할 수 있게 Figma(시안) 이미지도 같이 첨부하고 있습니다.
테스트 케이스를 작성하다 보면 작은 기능 단위부터 디자인 요소까지 확인하는 과정이 이루어지기에 예상하지 못한 예외 케이스를 발견하고 있습니다.
새롭게 추가되는 이벤트 로그 / 푸시 / 알림톡을 통해 추가되는 앱/딥링크가 있는지를 확인하며, 기획서의 요구사항을 명확하게 이해하고 누락된 케이스가 없는지를 점검합니다. 작성이 완료되면 팀 내부적으로 리뷰를 진행하고, 프로젝트를 담당하는 다른 직군(PO, PM, 개발자, 디자이너)의 담당자들에게 공유하여 누락된 케이스나 고려하지 못한 예외 케이스가 있는지 피드백을 받아 커버리지를 높이고 있습니다.
[ QA ]
개발이 완료되면 준비한 테스트 케이스를 QA 환경에서 수행합니다. 진행 중에 발생하는 크리티컬한 서버 이슈는 Slack을 통해 신속하게 전달하여 대응하고, 클라이언트 이슈는 JIRA에 티켓을 생성하여 전달합니다. 모든 피쳐는 에픽 단위로 관리되고 있습니다. 마이너한 이슈가 발생해도 개발자와 QA 엔지니어는 모든 유형(작업, 개선, 기능-품질 보증, 기획 변경)을 관리하기 쉽게 하위 이슈로 등록하고 있습니다.
[ 기획/디자인 QA ]
QA 단계가 완료되면 피쳐를 진행한 담당자들에게 테스트 결과를 공유한 후 기획자, 디자이너에게 인수 테스트(Acceptance Test) 요청합니다.
(우리는 이 과정을 기획/디자인 QA라고 부르기로 했습니다)
QA가 완료됐지만 추가적으로 기획/디자인 QA를 왜 요청하는 걸까요?
처음 기획된 내용과 동일한 기능과 디자인으로 구현되어 있더라도 보다 좋은 개선안이 있다면 초기 기획한 내용에서 기능과 요구사항이 추가 및 개선될 수 있어 기획/디자인 QA는 배포 전에 꼭 확인이 필요한 단계입니다.
기획/디자인 QA 담당자는 어떤 관점으로 테스트를 진행할까요?
- 기획자 : 사용자 관점에서 완성된 피쳐를 먼저 사용해 보고 의도한 방향으로 구현됐는지 확인 후 프로덕션 배포 적합 여부를 판단한다.
- 디자이너 : 실 단말로 확인했을 때 기대한 디자인으로 구현됐는지, UX/UI가 디자인 시스템에 어긋나지 않는지 확인한다.
[ Release QA ]
결과를 공유하고 QA가 완료되면 매주 금요일에 Release QA를 진행합니다.
내부적인 코드 개선과 마이너한 수정과 배포 트레인에 포함되는 PR(Pull Request)들이 병합되면서 사이드 이슈가 발생할 수 있습니다. 또한, 공통으로 사용되는 UX/UI가 예상치 못한 화면에서 큰 영향을 줄 수 있기 때문에 전체적인 프로세스를 확인하는 과정은 꼭 필요합니다.
헤이딜러에서 차량을 판매하는 고객은 self 경매와 zero 경매 중 어떤 판매 방법을 선택하는지, 판매자가 사업자라면 개인/간이/법인 사업자인지, 또한 리스 차량인지에 따라 요청하는 서류와 화면이 달라집니다. 이처럼 다양한 조건에 따라 요구되는 정보를 직접 확인하려면 많은 인력 리소스가 필요합니다.
위와 같은 문제에서 리소스를 효율적으로 관리하기 위해 변경이 자주 발생되지 않아 유지 보수 비용이 적게 발생하는 경매 프로세스를 appium으로 시나리오를 구축하여 자동화 테스트로 진행하고, 릴리즈 트레인에 포함되는 피쳐(B안)들은 수동 테스트로 진행하고 있습니다.
- 자동화 테스트
- 변경이 자주 발생되지 않는 전체 프로세스를 시나리오로 구축하여 확인하는 테스트 - 수동 테스트
- 배포되는 버전에 추가/수정/제거되는 기능 및 UX/UI를 실제 단말로 직접 확인하는 테스트
자동화 테스트가 완료되면 Slack bot으로 테스트 결과가 공유됩니다.
[ 배포 ]
Release QA가 완료되면 Android/iOS 담당자는 스토어에 심사를 요청합니다. 심사가 완료되면 안정적인 배포를 위해 점진적으로 배포를 진행하고, 오류가 발생하는지 모니터링한 뒤 문제가 없을 경우 전체 배포를 진행합니다.
- Android
- 금요일 오전: 릴리즈 테스트 진행
- 금요일 오후: 심사 요청
- 월요일 오후: 앱 점진적 배포(50% 점진적 배포)
- 화요일 오전: 앱 전체 배포
* 물론, 일정이 정해져 있는 피쳐이거나 긴급하게 배포해야 하는 예외 case일때는
배포데이가 아니라도 배포를 진행합니다.- iOS
- 금요일 오후: 심사 요청
- 월요일 오후:
1. 릴리즈 테스트 진행
2. 앱 점진적 배포 (1%, 2%, 5%, 10%, 20%, 50%, 100%)
- 수요일 오전 : 앱 전체 배포
* 물론, 일정이 정해져 있는 피쳐이거나 긴급하게 배포해야 하는 예외 case일때는
배포데이가 아니라도 배포를 진행합니다.[ A/B 테스트 ]
앱이 배포되면 Slack Reminder를 통해 A/B 데이터가 정상 수집되고 있는지 확인하고 있습니다.
A/B 테스트는 두 가지 이상의 시안 중 최적 안을 선정하기 위해 시험하는 방법입니다.
여러분은 아래 두 개의 버튼 중 어떤 버튼을 선택하고 싶으신가요?
- A (AS-IS) : 리뷰 남기기
- B (TO-BE) : 이야기 남기기
정답은 테스트하기 전까지 알 수 없습니다.
그래서 우리는 A안의 리뷰 남기기 버튼과 B안의 이야기 남기기 버튼 중 어떤 버튼이 고객의 선택을 유도할 수 있는지 특정 기간 동안 테스트를 진행하여 데이터를 비교한 후 선호도가 높게 나온 최적 안을 확정합니다.
[ 회고 ]
우리는 KPT(Keep, Problem, Try)를 회고에서 이야기하고 있습니다.
Keep: 좋았던 것, 잘한 것, 계속 유지했으면 하는 것, 만족스러웠던 것Problem: 문제가 있던 것, 잘 되지 않았던 것, 개선되었으면 하는 것, 부정적인 요소들Try: Problem에 대한 구체적인 해결/실천 방안, 잘하고 있는 것을 더 잘하기 위한 방안
마치며
지금까지 PRND에서 QA팀이 일하는 방법을 공유드렸습니다.
일하는 방식에는 정해진 규칙이나 정답이 없습니다. 작은 규모의 팀이든 큰 규모의 팀이든, 상황에 맞게 최선의 방법을 고민하고 실행한다면 지속적으로 발전하는 팀이 되리라고 생각합니다.
여러분들은 어떻게 일하고 계시나요?
댓글로 공유해 주시면 더 좋은 업무 환경을 만들어가는데 도움이 될 것 같습니다 👍
