platter

미들 (4~8년)

안녕하세요 🙂<ol><li>개발이 진행되는 동안 처음 설계한 기획안과 디자인을 바탕으로 테스트 케이스를 준비한 다음,</li><li>"이러한 항목들을 테스트 할 예정이고, 각 항목에서 기대하는 결과의 모습은 어떠하다"라는 것을 테스트 케이스 리뷰를 통해 눈높이를 맞춘 다음 (다만 이 부분은 진행하지 않는 경우도 있습니다.조직에 따라 다른거니까요)</li><li>개발이 한 차례 완료되어 테스트 서버/환경에 배포되면, QA에 참여하는 인원이 테스트 케이스를 바탕으로 QA를 진행하고</li><li>이슈가 있는 사항에 대해선 조직에서 사용하는 커뮤니케이션 툴을 통해 1) 무엇이 문제인지 2) 현황이 어떠한지 3) 어떤 상황에서 발생하는지 4) 기대하는 정상적인 결과의 모습이 무엇인지 설명 및 전달해서</li><li>수정이 되면 다시 한 번 체크하는 흐름으로 진행됩니다 </li></ol>&nbsp;

QA진행방식에 대해

안녕하세요 🙂QA를 전문으로 담당하는 분들이 있다면 해당 분들이 테스트 케이스 작성부터 테스트 준비, 테스트 수행을 담당하기 때문에 구태여 PM/PO가 준비하고 공유할 필요는 없어보입니다!다만 QA 담당자가 없고, PM/PO가 이를 준비하되 테스트 수행을 다른 사람들이 함께하는 경우라면, 테스트 케이스를 같이 공유해주셔야 참여하는 분들도 '아, 이런 케이스를 테스트해봐야하는구나? 이 케이스에선 이런 경우를 성공으로 판단하는거구나?' 이해하고 진행할 수 있겠죠!

테스트 케이스는

안녕하세요 🙂테스트 케이스의 각 시나리오, 항목을 어디까지 적느냐는 결국 '어느 수준까지 정밀하게 테스트를 수행하고 제품 품질을 유지할 것인가?'랑 연관되는데요, 기본적으로는 기획 단계에서 설계한 핵심 플로우(flow)와 이에 따른 핵심 기능과 정책(로직)은 모두 테스트 한다고 생각해도 좋을 것 같습니다.&nbsp;쉽게 생각하면 사용자 입장에서 해당 서비스에 진입해서 사용하고 종료하고 떠나는 순간까지의 주요한 경우의 수를 모두 테스트한다고 생각해도 될 것 같은데요,<ol><li>일단 각 메뉴/페이지/기능 진입이 가능한지는 당연히 확인해야 할 테고</li><li>각 메뉴/페이지/기능 내 중요 기능과 정책(로직)이 작동하는지도 확인해야 할 테고</li><li>특히 분기점이 생기는 로직의 경우 각 분기점마다 테스트해봐야겠죠 (예: 결제/환불 시나리오 등)<ul><li>이를 위해 각 분기점에 맞는 데이터, 유저 계정 및 정보 등을 세팅해두는거고요</li></ul></li><li>간혹 폰트, 색상, 배치 등 UI 요소도 테스트하긴 하는데 이는 시나리오로 써서 테스트한다기보단 그냥 자연스럽게 사용하면서 발견하는 경우에 더 가깝습니다</li></ol>

테스트 케이스에 어느 범위까지 적어야하는 지 모르겠어요

안녕하세요 🙂QA, 즉 테스트를 위해선 '무엇을 테스트할 것이고, 그 테스트의 성공 기준은 무엇인가?'라는 부분이 정의되어있어야 테스트가 가능하기 때문에, 통상적으로 Test Case 작성이 필수적입니다!(다만 테스트 케이스 시나리오로 일일이 작성하기 애매하거나 사실상 불가능한 간단한 UI 요소 등은 테스트 환경에서 서비스를 자연스럽게 사용해보면서 발견하는 식으로 하는 경우도 있긴 합니다)

안녕하세요 예비 pm입니다

안녕하세요 🙂 꼭 두가지가 동시에 있어야 한다거나, 혹은 반대로 두가지 중 하나만을 택해야 하는건 아닌데요,큰 틀에서는 제품은 사용자의 유저플로우를 따르게 되므로 굵직한 케이스는 순서(플로우, 퍼널)에 맞춰서 작성하되 그 안에서 디테일한 부분은 상-하위로 나눠보시면 어떨까 싶습니다!&nbsp;vod에서의 예시로 생각해보면<ol><li>순서상으로는 페이지 방문 > 회원가입 시도 > 회원가입 > 회원가입 완료가 있을 것 같고요</li><li>다만 각각 안에서는 [회원가입 시도]에서는 결제 수단에 따라 나뉠 수 있고, [회원가입] 단계에서는 여러 세부 혹은 엣지 케이스들 (아이디 미입력시, 비밀번호 불일치시, 비밀번호 보안 기준 미충족시 등) 이 일종의 상-하위 개념으로 있을 수 있겠지요!&nbsp;</li></ol>

platter

Posts