기획자가 QA를 해야 할 때
효율적인 테스트 관리와 소통을 위한 간단한 가이드
많은 조직에서 QA 담당자를 따로 두지 않고, 기획자가 QA까지 함께 진행하는 경우가 있다.
처음 QA를 할 때, 관련 정보 찾기가 많이 힘들었기 때문에 내 경험 기반으로 QA를 어떻게 진행하고, 효과적으로 소통 및 관리할 수 있었는지 공유하고자 한다.
QA 진행할 때 가장 편리한 툴 중 하나는 JIRA이다. 하지만 나는 막상 JIRA로 QA를 진행하지 못했다ㅠ
개발 외주업체가 있어 보안이슈로 인해 내부 JIRA 접근권한을 주는 데 한계가 있었다. 이 경우 구글스프레드시트로 1차 관리한 것을 따로 JIRA에 추가하여 2번 관리해야 하므로 구글스프레드시트만 활용하는 방향을 채택했다. 추후 JIRA로 관리할 기회가 생기면 따로 글을 작성해 보는 것으로 하고 오늘은 '구글 스프레드시트'로 관리한다는 것을 전제로 작성되었다.
그라운드 룰(Ground rule) 정하기
서비스를 만들 때 작업자가 여러 명이거나 외주 업체가 여러 명일 수밖에 없을 것이다. 각자 역할이 다른 이해관계자 간 커뮤니케이션을 이끌어내야 하는 기획자는 때로는 유연하게, 때로는 엄격하게 Rule을 선언하고 리드해야 할 필요가 있다. 특히 QA에서는 엄격한 Ground Rule을 세워두고 서로 디테일한 규칙을 잘 지키며 진행하도록 당부하는 편이다.
QA 문서를 작성하고 진행하게 되면, 포맷을 동일하게 이해하고 동일한 규칙 안에서 변경하도록 약속해야 한다. 내가 특히 강조하고 꼼꼼하게 안내하는 규칙은 '고유번호(코드), 일시, 담당자'다. 이 3가지는 절대 공란으로 두지 않도록 안내하고 사소한 건 이라도 상태를 변경하거나 문서를 수정할 경우 반드시 3가지는 놓치지 않고 반영하도록 한다.
이 외에도 특정 부분은 반드시 기획자만 수정하도록 한다거나, 특정 색상 사용, 문서 포맷 수정 불가, 비고/메모 작성 룰 등 각자가 원하는 규칙은 다양할 것이다. 규칙은 문서의 변경 사항을 관리하고, 모든 수정이 올바르게 기록되어 혼란을 방지하기 위한 핵심 요소다. 이는 모든 팀원이 혼란스럽지 않고, 최신 상태를 정확히 파악할 수 있도록 해준다. 여러 가지 케이스를 경험하면서 관리를 위해 반드시 지켜줘야 하는 규칙을 발견할 경우 프로젝트 시작 전 단호하게 선언할 수 있도록 추천한다.
QA 시트 만들기
프로세스 중 발견된 문제들을 체계적으로 관리하기 위해 문서를 잘 만드는 것이 중요하다. 이 시트의 포맷과 양식은 앞서 말한 Ground Rule의 가장 중요한 요소 중 하나라 할 수 있다. 시트를 작성할 때 중요한 것은 '관리'를 잘하기 위한 목적이라는 것이다.
나는 크게 2개 시트로 만들어 QA 진행을 했다.
1) TC 시나리오 시트 : QA 진행을 위한 TC(Test Case) 시트를 만들고, 테스트해야 하는 메뉴별 기능 및 테스트 시나리오를 작성했다. 각 시나리오에 TC코드를 부여하고 해당 기능이 동작하는지 여부에 따라 Pass/Fail로 구분했다. 그리고 Fail일 경우 해당 Fail건에 대한 요청사항을 요청사항 시트에 백로그 형태로 누적했다. 이때 한 개의 Fail건에 여러 건의 요청사항이 발생할 수 있기 때문에 요청사항 코드와 TC 시나리오 코드를 매핑하는 것이 중요하다.
2) 요청사항 시트 : TC 시나리오에서 나온 이슈, 혹은 그 외 F/E나 디자인 검수 과정에서 발생한 수정요청사항 일체를 정리한 시트이다. 백로그 형태로 관리하고 이 시트가 서비스의 디테일한 완성도를 높이는데 많은 도움이 되었다. 아래 해당 시트 작성을 위해 활용할 수 있는 칼럼을 정리했다.
[요청사항 시트를 만들 경우 활용할 수 있는 칼럼]
1) 수정 요청사항 번호 : 각 수정 요청에 고유 번호를 부여하고 테스트 케이스(TC) 번호와 연결한다.
2) 목적: 수정 요청의 목적(오류 수정, 기능 개선 등)을 명확히 한다.
3) 디바이스 및 브라우저: 오류가 발견된 디바이스와 브라우저를 기록한다.
4) 발견 일시와 이슈 발견자: 오류를 처음 발견한 시간과 발견자의 이름을 문서화한다.
5) 우선순위: 오류의 긴급성과 중요성에 따라 우선순위를 설정한다.
6) 메뉴 Depth: 오류가 발견된 메뉴 위치를 기록해, 문제의 정확한 위치를 파악한다.
7) 내용 요약 : 문제의 요약과 함께,
8) 시각 자료 링크 : PPT, 피그마 등 이슈 캡처한 시각 자료를 첨부해 문제 상황을 명확히 전달한다.
9) 담당자 : 각 문제를 해결할 담당자를 지정한다.
10) 진행 상태: 문제에 대한 현재 진행 상태(확인 전, 처리 중, 처리완료 등)를 기록한다.
11) 검수자 : 각 문제 해결을 검수할 검수자를 지정한다.
12) 검수 상태: 검수 상태(검수 전, 검수 중, 검수완료 등)를 기록한다.
13) 처리 및 검수 일시: 각 단계별 완료 시간을 기록해 프로젝트 일정 관리와 투명성을 보장한다.
14) 비고: 기타 필요한 메모나 특이 사항을 추가한다.
QA 상황의 시각적 표현
QA 진행 상황을 이해관계자가 쉽게 파악할 수 있도록, 작업 상태와 검수 상태의 개수와 비율을 정리해 볼 수 있는 시각적 도구를 사용하는 것이 중요하다. 도넛 그래프나 바 차트를 사용해 각 상태의 항목 수나 비율을 색상별로 구분하여 한눈에 보기 쉽게 만든다.
진행상태, 검수상태를 시각화할 경우 현재 QA의 진척상황과 이슈(Pass개수, Fail개수 등)에 대한 파악이 훨씬 쉬울 것이다.
마무리하며
전문 QA 팀이 없는 환경에서도 기획자가 체계적인 문서화와 정확한 커뮤니케이션을 통해 성공적인 QA 프로세스를 운영할 수 있다. 모든 팀원이 협력하여 문제를 해결하고, 프로젝트의 품질을 최상으로 유지하는 노력은 프로젝트의 성공을 보장하며, 최종 제품의 사용자 경험이 향상된다.
