<9> 좋은 이슈 리포트란 무엇일까?
QA for Beginners
이슈 리포트가 뭔가요?
'이슈 업(Up) 해주세요', '티켓 등록해 주세요', '리포트 작성해 주세요' 등 여러 표현으로 불리지만 이들은 공통적으로 이슈 리포트를 뜻한다. 이슈 리포트가 무엇일까?
별 거 없다. 이슈를 발견하면 이를 유관 부서(개발자 또는 기획자)에게 직접 공유 또는 BTS에 등록하는 방식으로 공유하게 되는데, 이때 보고서 형식으로 작성하게 되고 이를 이슈 리포트라고 한다.
조금만 써보면 언제 그랬냐는 듯 '그냥 쓰면 되는 거 아닌가?' 하게 되지만, 처음 테스트를 수행하고 리포트를 작성해야 하는 상황이 왔을 때 누구나 당황한 적이 있을 것이다. 작성에 있어 옳은 리포트는 없지만, 좋은 리포트는 존재한다. 왜 처음에 어렵다고 느끼는지, 좋은 리포트를 작성하는 것이 왜 좋은지에 대해 이야기해 보겠다.
이슈 리포트를 부담스러워하는 이유
좋은 리포트의 기준을 모르기 때문이다. 대개 사수들은 '이슈 리포트에는 정해진 양식이 없다.'라고 말하면서 '우리 팀에서는 이러한 양식으로 작성한다.'라는 단서를 붙인다. '작성자의 스타일 차이지, 좋고 나쁘다의 이분법적 구분을 해야 하는 것은 아니다'라고 말하지만 '기대 결과를 명확히 작성해 주세요', '이미지보단 영상을 첨부해 주세요', 하다못해 '제목을 두 줄이 넘지 않도록 간결하게 써 주세요'라고 말한다. 이러한 모순은 '어쩌라는 거지?'로 축약되고, 5분이면 작성할 리포트 하나에 20분 동안 진을 빼고 있는 신입의 모습을 보게 만든다.
왜 이런 단서가 붙는가?
하나는 정말 팀에서 합의한 스타일이기 때문이고, 다른 하나는 이를 지키지 않으면 유관 부서가 이슈가 무엇인지를 이해할 수 없기 때문이다. 전자는 고려할 대상이 아니므로 생략하고, 후자에 대해 생각해 보자.
본인이 QA에서 등록한 이슈 리포트를 보고 이슈가 무엇인지를 파악해야 하는 유관 부서의 입장이라고 하자. 텍스트가 잘못 노출되는 현상이라는 이슈 타이틀을 보고 내용을 확인하는데, '한글 안내 문구가 잘못 노출됩니다.'라는 한 문장으로 이슈 설명이 끝났다면 대체 무엇이 잘못 노출되고 있는지 알 수 있을까? 특정 기기 또는 특정 OS 환경에서 일부 글자가 잘려서 그럴까? 아니면 단순히 글자 크기가 너무 큰가? 정렬이 잘못되었나? 안내 문구 자체가 기획과 다른가? 특정 수치를 초과해도 B/E 값을 참조하지 못해 문구가 바뀌지 않아서 그런가? 이처럼 이슈 내용이 모호하면 유관 부서가 이슈를 오해할 여지를 주게 된다.
다른 예시로 특정 기기에서 블랙리스트에 등록된 계정인데도 아이템 수령이 가능한 이슈라고 가정해 보자.
첫째는 우리가 테스트 계정 정보, UUID와 같은 기기 정보, 테스트 환경 등의 정보를 명시해주지 않아 유관 부서의 입장에서 정보가 부족했기에 이해하지 못할 수 있다.
둘째는 '수령이 가능'이라는 표현을 단지 내 보유 내역만 보고 명시했는데 사실은 아이템이 복사되어 무한 수령이 가능한 경우로, 면밀하게 확인하지 않고 이슈를 작성한 결과 유관 부서가 '아이템 복사'가 아닌 '아이템 수령 여부'라는 엉뚱한 부분을 이슈로 인지했기에 발생할 수 있다.
모호한 이슈 리포트에는 위와 같이 무수한 꼬리물음이 따라올 수 있다. 이 꼬리물음의 결과는 다양하게 나타나는데, 유관 부서에서 해당 리포트의 코멘트 또는 Slack과 같은 커뮤니티 채널로 확인 질문이 들어올 수도 있고, 이슈가 아닌 것으로 오해하고 이슈가 다시 우리에게 할당될 수 있다. 이로 인해 우리는 유관 부서에게 필요하다면 이미지 또는 영상으로 재현 과정을 보여면서 무엇이 이슈인지를 다시 설명해야 하고, 담당자를 재지정하고, 이슈가 맞다는 컨센서스를 이뤄야 한다. 이 과정은 짧게는 1분에서 길게는 다음 날까지의 시간 소요가 발생할 수 있고, 이는 QA 기간이라는 제한된 시간을 비효율적으로 사용하게 되기 때문에 불충분한 정보로 작성된 이슈 리포트는 가급적 지양해야 한다.
좋은 리포트를 쓰려면
형식과 상관없이 다음의 5가지만 기억하면 된다.
정확하게 스펙을 이해하고,
면밀한 테스트로 최대한 정확하게 이슈를 파악하고,
이를 이슈 타이틀, 내용, 기대 결과에 정확하고 간결하게 핵심만을 명시하며,
유관 부서의 입장에서도 똑같이 재현할 수 있도록 최대한 구체적인 재현 과정을 명시하며,
유관 부서의 입장에서 필요로 할 정보를 고려하여 데이터 정보, 테스트 환경, 참고 URL, 이미지, 영상 등 최대한 많은 방법을 활용하여 이해를 도와야 한다.
단, 제품의 코드를 손바닥 보듯 훤히 알고 있거나 유관 부서들의 모든 프로세스를 꿰뚫고 있는 것이 아니라면 이슈 원인을 함부로 예측하지 말아야 한다.
이슈는 단순히 하드코딩 되어서 발생했을 수도 있고, 배포 실수일 수도 있고, 개발이나 기획에서 해결할 부분이 아니라 별개인 줄 알았던 운영팀과 같은 부서에서 정의해주지 않아 발생했을 수도 있다. 어설픈 이슈 원인의 예측은 개발자의 자존심을 건드리는 사소한 감정적 갈등 유발에서부터 유관 부서의 이슈 오해로 인한 리소스 낭비의 핵심 원인에까지 불필요한 상황이 발생할 수 있으므로, 본인이 직관적인 성향을 갖고 있다면 잠시 넣어두고 확실한 정보를 바탕으로 눈에 보이는 대로만 이슈를 전달하라.
TC 작성과 마찬가지로 이슈 리포트도 많이 쓰고, 많이 참고하고, 많이 고민할수록 좋은 리포트를 '빠르게 숨 쉬듯' 작성할 수 있을 것이다. 이 글을 통해 좋은 이슈 리포트에 대한 자신만의 기준이 세워지길 바란다.
