초보 기획자 혹은 PM을 위한 QA 가이드

앞선 글에서 프로덕트 팀에 Test Case를 도입한 후기에 대해 공유했는데, 이번 글에서는 QA를 할 때의 간단한 노하우 몇 가지를 공유하고자 한다.

Previously

1) 세부 시나리오에 따라 Test Case를 작성한다

2) 한계도 있지만 어쨌든 Test Case 내에서 세밀하고 명료하게 확인할 수 있는 장점이 있다

1. 시나리오별 계정 미리 세팅하기

가령 Test Case에서 구매자와 판매자의 [my홈]을 확인해야 한다고 가정해보자. 그리고 해당 화면에서 구매자는 최근 주문내역을 확인할 수 있어야 하고, 판매자는 최근 등록한 상품 내역을 확인할 수 있어야 한다고 가정해 보자. 그렇다면 이 경우 계정은 최소한 아래와 같이 미리 분류하여 세팅하는 것이 좋다.

1-1) 구매 내역이 없는 구매자 → 출력할 값이 없는 케이스

1-2) 구매 내역이 있는 구매자 → 구매 내역이 출력되는지 등등…

2-1) 판매 중인 상품이 없는 판매자 → 출력할 값이 없는 케이스

2-2) 판매 중인 상품이 있는 판매자 → 판매 상품 내역이 출력되는지 등등...

이렇게 시나리오별로 계정을 분류하여 세팅하는 이유는, 시나리오에 맞지 않는 계정으로 QA를 진행한 후 엉뚱한 결과를 남겨두는 경우를 방지하기 위함이다.

가령 판매자 계정으로 로그인하여 구매자 시나리오를 확인한 뒤 "000님, 방금 구매내역에 들어갔는데 아무것도 안 떠서요 ㅠㅠㅠ"라고 한다면 여러분의 동료 개발자는 조용히 미간을 찌푸릴지도 모른다.

물론 서비스에 따라 구매자가 판매자로 전환될 수 있는 시나리오가 존재하거나, 구매∙판매 내역이 있더라도 개수에 따라 시나리오가 달라지는 경우가 있다면, 이 경우를 고려한 계정을 분류해서 세팅하는 것도 가능하다.

1-1) 구매 내역이 없는 구매자

1-2) 구매 내역이 있는 구매자

1-3) 구매 내역이 N개 이상인 구매자 → 출력 순서, [더 보기] 등등...

2-1) 판매 중인 상품이 없는 판매자

2-2) 판매 중인 상품이 있는 판매자

2-3) 판매 중인 상품이 N개 이상인 구매자 → 출력 순서, [더 보기] 등등...

3-1) 구매자에서 판매자로 전환된 사용자 → 출력값이 전환되는지 등등...

2. 혹시 테스트 서버와 실서버가 연동된 건 없는지 확인하기

이 부분은 팀, 조직에 따라 말도 안 되는 상황일 수도 있다. 그러나 상황에 따라 어째서인지 테스트 서버에서의 활동이 실서버에 영향을 주는 경우가 있다. (서버가 분리되지 않았다든가, 서버가 분리되지 않았다든가, 서버가 분리되지 않았다든가) 따라서 QA를 위한 테스트 서버에서 해야 하는 활동 중 혹시나 실서버에 영향을 줄 수 있는 활동이 있는지 미리 살펴보자.

P.S. 내가 합류한 팀의 경우, QA 서버에서 실제 사용자가 남긴 게시글에 댓글을 다는 경우, 실서버의 유저에게 실제로 알림이 발생하는 경우가 있었다!

3. 시나리오의 한계를 극복하기 위한 랜덤 QA

Test Case는 어디까지나 사람이 작성한다. 아무리 기획자, PM이 서비스의 전체 맥락을 이해한다고 해도 사람인 이상 어디에서는 케이스를 누락하거나, 혹은 애초에 케이스로 확인할 수 없는 경우가 있다.

애초에 Test Case는 ‘의도한 것이 의도한 대로 구현되어 작동하는가?’를 확인하는 문서이기에 의도한 것만 작성되어 있다. 즉, 의도하지 않았음에도 실제 서비스에서 발생 가능한 경우는 Test Case로 발견하고, 검수할 수 없다.

• 정말 말도 안 되는 케이스를 만드는 유저
• 기획이랑 상관없는 각종 요소들

이를 고려해 할 수 있는 게 바로 랜덤 QA다.

1) 시나리오 A를 확인하러 진입한 화면, 구간에서 일부러 다른 요소 B, C, D, E 진행해 보기

• 원래 시나리오: 회원가입 화면에서 아이디를 입력
• 회원가입 화면에서 대뜸 [메뉴] 버튼 출력되는지 확인하기
• 회원가입 화면에서 대뜸 뒤로 가기 눌러보기
• 회원가입 화면에서 대뜸 헤더의 로고 눌러보기
• 기타 등등...

2) 일부러 틀린 값 만들기

• 원래 시나리오: 회원가입 화면에서 규칙에 맞는 아이디 입력 (6~12글자, 영문/숫자/특수문자)
• 30글자 넣어 보기
• 윈도 + ; 로 이모티콘 넣어 보기
• 한자 넣어 보기
• 기타 등등...

3) 내가 특정 유형의 고객이라고 생각하고 써보기

• 내가 최근 구매한 내역 중 가장 최신의 상품 상세 정보를 확인하고 싶은 구매자라고 생각하고 해당 시나리오∙플로우 쭉 진행해 보기
• 내가 최근 판매 등록한 상품 중 가장 많이 팔린 상품의 통계 내역을 확인하고 싶은 판매자라고 생각하고 해당 시나리오∙플로우 쭉 진행해 보기
• 기타 등등...

이와 관련해서 조금 더 자세히 설명한 아티클이 있으니 시간될 때 보는 걸 추천한다.

4. 의존성 요소를 고려한 누적 QA

이론상, 그리고 기획의도상 어떤 기능들은 서로 상관이 없어야 한다. A를 한다고 해서 B가 진행되거나, A를 안 한다고 해서 B가 진행되지 않는 일이 없어야 한다. 그런데, 최종 배포가 아닌 '개발이 진행되는 과정'에서는 A와 B가 상관이 있을 수도 있다.

또는 B를 하기 위해선 A부터 먼저 해야 하는 수도 있다. 가령 본인인증을 요하는 회원가입의 경우, (A-1) 회원가입 페이지가 구현되고 → (A-2) 그 안에 다날 등을 통해 PASS를 연동하고 → (A-3) 본인인증이 완료된 후에 개인 정보 입력 화면으로 넘어간다. 그런데 만약 아직 다날 가입 및 PASS 연동이 안되었다면, 당연히 개인 정보 입력 부분은 검증이 무의미하다. (물론 때에 따라, "했다 치고"하는 경우도 있지만, 온전하진 않다.)

이런 경우 단순히 특정 날짜에 힘들게 몰아서 시나리오 1~30번을 모두 테스트하고, 며칠 후 31번부터 50번까지 테스트한 뒤에 배포했을 때 분명 테스트상 이상이 없었던 1~30번에서 이슈가 생기는 수가 있다. 위와 같이 서로 의존성이 없어야 하는데 의존성이 있는 걸 생략했거나, 의존성이 당연히 있는 부분을 거꾸로 놓칠 수가 있기 때문이다.

그래서 이런 경우를 방지하기 위해 아래 그림과 같이 누적 QA를 진행한다.

5. 프로덕트 팀이라면 당연히 참여하자 & 프로덕트 팀 외에도 참여시키자

QA 전담 부서나 담당자가 없다면 QA는 결국 PM과 기획자가 주로 진행하게 된다. 그러나 비단 QA는 PM과 기획자만의 일이 아니라고 생각하며, PM과 기획자가 아닌 이들이 함께 QA를 진행할 경우의 효용은 아래와 같다.

1) PM/기획자 입장에선 놓친 부분 등을 다른 이들이 교차 확인해 주어 안심이 된다.

2) 개발자: 본인이 작성한 코드 너머, 서비스의 실제 구동, 운영 차원에서 이해하게 되는 계기가 된다.

3) 디자이너: 퍼블리싱이 잘못된 부분이 없는지 한 번 더 살펴보게 되고 + 디테일한 정책도 한 번 더 확인하게 된다.

4) 조직 내 이해관계자-요청자: 요청한 기능이 잘 들어갔는지 직접 확인할 수 있다.

5) VOC 담당자 또는 운영 인력: 서비스가 실제로 어떻게 구동, 운영되는지 확인하고 + 고객 문의가 생김 직한 부분에 대해 미리 파악, 답변을 준비하게 된다.