요즘IT
위시켓
최근 검색어
전체 삭제
최근 검색어가 없습니다.

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

회원가입을 하면 원하는 문장을
저장할 수 있어요!

다음

회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!

확인

기획

초보 기획자 혹은 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 연동이 안되었다면, 당연히 개인 정보 입력 부분은 검증이 무의미하다. (물론 때에 따라, "했다 치고"하는 경우도 있지만, 온전하진 않다.)

 

서비스 QA 의미
A라는 서비스를 위해 기능 A-1, A-2, A-3이 모두 구현되어야 하지만
A-2에서 멈췄다면 A-3은 QA가 무의미할 수도 있다

 

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

 

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

 

누적 QA 진행
의존성 요소를 고려한 누적 QA. 이전에 QA를 진행했던 부분도 다시 QA를 하면서
의존성 요소에 의해 이슈가 생기거나 혹은 검수하지 못했던 부분을 놓치지 않게 된다

 

 

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

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

 

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

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

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

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

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

좋아요

댓글

공유

공유

댓글 1
ibocon
            좋은 글 감사합니다~
          
2024.03.18. 오후 14:48
그로스PM
78
명 알림 받는 중

작가 홈

그로스PM
78
명 알림 받는 중
사수 없이 고군분투하며 깨닫고 배운 것들을 기록하여 공유합니다. 저의 어제의 발버둥이 누군가의 오늘에 도움이 되길 바랍니다.
함께 스크랩한 콘텐츠
같은 분야를 다룬 콘텐츠
인기 있는 콘텐츠

좋아요

댓글

스크랩

공유

공유

지금 회원가입하고,
요즘IT가 PICK한 뉴스레터를 받아보세요!

회원가입하기
요즘IT의 멤버가 되어주세요! 요즘IT의 멤버가 되어주세요!
요즘IT의 멤버가 되어주세요!
모든 콘텐츠를 편하게 보고 스크랩할 수 있어요.
모든 콘텐츠를 편하게 보고 스크랩 하기
매주 PICK한 콘텐츠를 뉴스레터로 받을 수 있어요.
매주 PICK한 콘텐츠를 뉴스레터로 받기
로그인하고 무료로 사용하기