💦 나만 모르는 프로덕트 관리 이야기 [✏️ 초보 기획자 혹은 PM을 위한 QA 가이드] (👀간단 요약) 📌 시나리오별 계정 미리 세팅하기 Test Case에서 구매자와 판매자의 [my홈]

💦 나만 모르는 프로덕트 관리 이야기 [✏️ 초보 기획자 혹은 PM을 위한 QA 가이드] (👀간단 요약) 📌 시나리오별 계정 미리 세팅하기 Test Case에서 구매자와 판매자의 [my홈]을 확인해야 한다고 가정, 해당 화면에서 구매자는 최근 주문내역을 확인할 수 있어야 하고, 판매자는 최근 등록한 상품 내역을 확인할 수 있어야 한다면? ✓ 구매 내역이 없는 구매자 → 출력할 값이 없는 케이스 ✓ 구매 내역이 있는 구매자 → 구매 내역이 출력되는지 등 ✓ 판매 중인 상품이 없는 판매자 → 출력할 값이 없는 케이스 ✓ 판매 중인 상품이 있는 판매자 → 판매 상품 내역이 출력되는지 등 ✓ 시나리오 별 계정을 세팅하는 이유는 맞지 않는 계정으로 QA를 진행한 후 엉뚱한 결과를 남겨두는 경우를 방지하기 위함 📌 혹시 테스트 서버와 실서버가 연동된 건 없는지 확인하기 ✓ 상황에 따라 어째서인지 테스트 서버에서의 활동이 실서버에 영향을 주는 경우가 존재 ✓ QA를 위한 테스트 서버에서 해야 하는 활동 중 혹시나 실서버에 영향을 줄 수 있는 활동이 있는지 미리 살펴봐야 ✓ QA 서버에서 실제 사용자가 남긴 게시글에 댓글을 다는 경우, 실서버의 유저에게 실제로 알림이 발생하는 경우가.. 📌 시나리오의 한계를 극복하기 위한 랜덤 QA ✓ 서비스의 전체 맥락을 이해한다고 해도 케이스를 누락하거나, 혹은 애초에 케이스로 확인할 수 없는 경우 존재 ✓ 의도하지 않았음에도 실제 서비스에서 발생 가능한 경우는 Test Case로 발견하고, 검수할 수 없음 ✓ 시나리오 A를 확인하러 진입한 화면, 구간에서 일부러 다른 요소 B, C, D, E 진행해 보기 ✓ 일부러 틀린 값 만들기 ✓ 내가 특정 유형의 고객이라고 생각하고 써보기 📌 의존성 요소를 고려한 누적 QA ✓ 단순히 특정 날짜에 힘들게 몰아서 시나리오 1~30번을 모두 테스트하고 ✓ 며칠 후 31번부터 50번까지 테스트한 뒤에 배포했을 때 분명 테스트상 이상이 없었던 1~30번에서 이슈가 생기는 수가 있음 ✓ 서로 의존성이 없어야 하는데 의존성이 있는 걸 생략했거나, 의존성이 당연히 있는 부분을 거꾸로 놓칠 수가 있기 때문 📌 프로덕트 팀, 그 외의 인원도 창여시키기 ✓ PM/기획자 입장에선 놓친 부분 등을 다른 이들이 교차 확인해 주어 안심 ✓ 개발자: 본인이 작성한 코드 너머, 서비스의 실제 구동, 운영 차원에서 이해하게 되는 계기 ✓ 디자이너: 퍼블리싱이 잘못된 부분이 없는지 한 번 더 살펴보게 되고 + 디테일한 정책도 한 번 더 확인 ✓ 조직 내 이해관계자-요청자: 요청한 기능이 잘 들어갔는지 직접 확인 ✓ VOC 담당자 또는 운영 인력: 서비스가 실제로 어떻게 구동, 운영되는지 확인