초보 기획자 혹은 PM을 위한 QA 가이드
Test Case는 작성했는데 그래서 어떻게 해야 하죠?
Previously....
1. 세부 시나리오에 따라 Test Case를 작성한다
2. 한계도 있지만 어쨌든 Test Case 내에서 세밀하고 명료하게 확인할 수 있는 장점이 있다
앞선 글에서 프로덕트 팀에 Test Case를 도입한 후기에 대해 공유했는데, 이번 글에서는 QA를 할 때의 간단한 노하우 몇 가지를 공유하고자 한다.
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 연동이 안되었다면, 당연히 개인 정보 입력 부분은 검증이 무의미하다. (물론 때에 따라, "했다 치고" 하는 경우도 있지만, 온전하진 않다)
A라는 서비스를 위해 기능 A-1, A-2, A-3이 모두 구현되어야 하지만 A-2에서 멈췄다면 A-3은 QA가 무의미할 수도 있다이런 경우 단순히 특정 날짜에 힘들게 몰아서 시나리오 1~30번을 모두 테스트해두고, 며칠 후 31번부터 50번까지 테스트한 뒤에 배포하면, 분명 테스트해서 이상이 없었다고 믿은 1~30번에서 이슈가 생기는 수가 있다. 위와 같이 서로 의존성이 없어야 하는데 의존성이 있어 생했거나, 의존성이 당연히 있는 부분을 거꾸로 놓칠 수가 있기 때문이다.
그래서 이런 경우를 방지하기 위해 아래 그림과 같이 누적 QA를 진행한다.
의존성 요소를 고려한 누적 QA. 이전에 QA를 진행했던 부분도 다시 QA를 하면서 의존성 요소에 의해 이슈가 생기거나 혹은 검수하지 못했던 부분을 놓치지 않게 된다5. 프로덕트 팀이라면 당연히 참여하자 & 프로덕트 팀 외에도 참여시키자
QA 전담 부서나 담당자가 없다면 QA는 결국 PM/기획자가 주로 진행하게 된다. 그러나, 비단 QA는 PM/기획자만의 일이 아니라고 생각하는데, PM/기획자가 아닌 이들이 함께 QA를 진행할 경우의 효용은 아래와 같다.
1) PM/기획자 입장에선 놓친 부분 등을 다른 이들이 교차 확인해주어 안심이 된다.
2) 개발자 : 본인이 작성한 코드 너머, 서비스의 실제 구동, 운영 차원에서 이해하게 되는 계기가 된다.
3) 디자이너 : 퍼블리싱이 잘못된 부분이 없는지 한 번 더 살펴보게 되고 + 디테일한 정책도 한 번 더 확인하게 된다.
4) 조직 내 이해관계자-요청자 : 요청한 기능이 잘 들어갔는지 직접 확인할 수 있다.
5) VOC 담당자 또는 운영 인력 : 서비스가 실제로 어떻게 구동, 운영되는지 확인하고 + 고객 문의가 생김 직한 부분에 대해 미리 파악, 답변을 준비하게 된다.
