직군별로 바라보는 QA 케이스 스터디
두번째로 진행하는 사이드프로젝트는 어느새 백엔드 개발을 마무리하면서 프론트 개발을 하고 있다. 역시나 사이드프로젝트는 본업이 아니다보니 항상 예상보다 진행이 더디고 예상하지 못하는 일들이 발생한다.
진행속도를 높이기 위해서 최소한의 인원으로 진행을 하다보니 다양한 역할을 하기 마련이다. 비용이 발생하면 회계 장부를 만들고 마케팅 플랜이 필요하면 AOS나 초기 마케팅 전략 관련한 스터디를 한다.
이번엔 QA의 차례이다.
회사에서 진행하는 QA 체크리스트를 곁눈짓으로 보긴 했었지만, 평소에도 꼼꼼한 성격이 아니다보니 덜컥 겁이 났다. 첫번째 사이드프로젝트는 QA 단계까진 진행하지 못했다 보니 이번엔 잘 준비해보고 싶었던 마음도 컸다. 아래부터는 인터넷의 스승님들을 찾아보며 만든 스터디 내용이다. 이를 유념하면서 팀원들과 더블체크하며 진행해보려 한다.
기능적으로 문제가 있는가? (제대로 작동하는가)
기획의도와 일치하는가
UX 사용성에 개선 필요한 불편함이 있는가?
테스트(Test)란 한 개 이상의 테스트 케이스의 집합을 의미합니다.
테스트 케이스(Test Case)란? 「프로그램의 특정 경로를 실험」해 보거나 혹은 「프로그램이 특정 요구 사항을 준수하는지를 확인」하기 위한 목적으로 사용. 이때, 「특정 목적」 또는 「테스트 조건의 확인」을 위해 개발된 「입력값, 실행 사전 조건, 예상 결과 및 실행 사후 조건」 등을 포함한 내용의 집합.
테스트 시나리오(Test Scenario)란? 테스트 실행을 위한 일련의 활동을 구체적으로 기술해둔 문서. 테스트 시나리오는 「테스트 스크립트」라고 불리기도 하며, 혹은 「수동 테스트 스크립트」
서비스의 케이스와 기능, 정책에 대해서 충분히 알고 있어야 한다.
정상 시나리오 이외에도 예외 케이스/시나리오도 확인한다.
데이터 측정 관련한 작업의 QA 작업도 진행한다.
시나리오별 Test Case 작성하기
시나리오별 계정 셋팅하기
에러 케이스, 오류 케이스 함께 테스트하기 (0, null, 스페이스 등)
누적 QA 1/2/3 차 등 여러 나눠서 진행하면 각 기능/화면의 의존성을 확인한다.
여러 직군과 팀이 QA에 참여한다.
QA가 없다면, 주로 QA/QC를 기획자가 담당하게 되는 경우가 많다. 하지만 여러 직군이 참여 할 수 있도록 유도하여 각 직군별로 제품에 대한 이해를 높이는 계기를 만들어 줄 수 있다.
기획자: 기획자는 제품의 정책에 대해서 가장 잘 이해하고 있는 사람이다. 자신의 기획의도를 가장 먼저 확인하고 이슈를 예방할 수 있다.
디자이너: 폰트/컬러 등의 디자인 시스템을 가장 잘 파악하고 있는 사람이다. 다른 직군의 눈에서 볼 수 없는 것들을 빠르게 캐치할 수 있다.
개발자: 자신의 개발 작업물을 코드를 넘어서 어떻게 서비스로 구현되는지 파악할 수 있다. 조회 속도부터 자연스러운 UX 등 개발 단위에선 생각 못하는 여러 방면에 대한 생각을 할 수 있다. (예외 케이스로 인한 서비스 경험 등)
QA 순서
1. Test 시나리오를 꼼꼼하게 작성한다.
2. 이슈 내용을 각 화면 스토리에 티켓으로 작성한다. 별도의 QA 티켓 생성하여 하위에 이슈 티켓 생성
3. 각 이슈는 해당 티켓으로 이슈 트래킹 > 이슈 완료 여부 확인 > 후순위 티켓은 백로그 이동 확인
4. 모든 티켓의 처리가 완료되면 QA 종료
참고 문서
아기자기한 프로덕트 팀의 Test Case 도입기 | 요즘IT
초보 기획자 혹은 PM을 위한 QA 가이드 | 요즘IT