버그 리포트는 어떻게 써야 할까?

게임 QA의 보고서

게임을 포함한 소프트웨어 개발에 가장 큰 위험 요소는 버그다. QA의 주 업무는 버그를 발견하여 제품의 안정성을 높이는 거다. 버그를 발견한 뒤엔 리포트를 작성한다. 이후 담당 기획자와 개발자에게 내용을 공유한다. 업무의 많은 시간을 할애하고 그 중요도가 높은 만큼 리포트 작성에 대한 고민이 크다.

제목
어느 글이 그렇듯 제목이 가장 중요하다. 제목은 리포트 내용의 요약이다. 구체적인 현상을 한 문장으로 정리해야 한다. FPS 게임을 예로 들어보겠다. ‘특정 맵에서 주 무기의 총기 반동이 제대로 반영이 안 되는 문제’가 제목이라면 구체적인 문제를 파악하기 힘들다. ‘특정 맵에 있는 OO좌표에 있는 50m 거리 표적에게 사격하는 AK47의 총기 반동이 다른 맵보다 큰 문제’라고 하면 전보다 좀 더 자세한 설명이 된다. 너무 길면 안 되지만, 모든 내용을 담고 있는 제목을 쓰려고 노력해야 한다.

환경
테스트를 진행하는 환경에 대해 자세히 서술한다. 필자 회사의 경우 BTS(Bug Tracking system)로 JIRA 프로세스를 이용 중이다. 버그 리포트는 종종 형사의 수사 보고서로 비유된다. 범인을 잡기 위해선 범죄 현장의 모든 요소가 중요하다. 이처럼 어떤 서버, 빌드 등 고려해야 하는 다양한 환경에 대한 정보가 있어야 한다.

재현율
해당 현상이 어느 정도 빈도로 나타나는지 적어야 한다. 모든 버그는 100%로 일어나지 않는다. 때문에 대략적으로라도 재현율을 제공해야 한다. 만약 %로 나타나기 어렵다면, '20번 시도했으나 다시 재현하지 못함'처럼 구체적인 수치로 표시하는 게 좋다.

설명
제목으로 모든 내용을 담을 수 없기에 자세한 사항은 설명하는 칸을 활용해야 한다. 재현을 위한 버그 사전 스텝이나, IP와 포트, 스트림, 서버, 클라이언트 등 적는다. 이외에도 참고가 될만한 정보를 모두 쓴다. 기대 결과도 적어주면 좋다. 버그가 없고 소프트웨어가 정상 작동하면 나타나는 결과에 대해 쓴다.

재현 스텝
재현 스텝은 가장 알아보기 쉽고 짧게 쓰는 게 좋다. 필자 회사의 경우 굳이 '전원을 넣는다' 같은 항목을 쓰지 않는다. 이미 게임을 실행했다는 전제를 깐다. (이 과정에서 발생하면 어쩔 수 없이 적지만) 이후 생략이 가능한 부분은 모두 적지 않는다. '1. A -> B -> C  2. OO 접속해 해당 증상 확인'과 같이 쓴다.

참고 파일
백 마디 글보다 한 장의 사진이 더 이해하기 쉬울 때가 있다. 때문에 스크린 샷과 영상을 만들어 보기 좋게 편집해서 첨부해야 한다. 적당한 용량과 서버와 원활한 연결을 위해 확장자 명을 고려하는 게 좋다. 불가피하게 용량이 큰 경우 아예 링크를 달아서 회사 내부 공유 폴더에 업로드하는 편이 낫다.

댓글
버그 리포트(이슈라고도 부르는데) 관련 새로운 소식이나 추가적인 정보는 댓글을 남기는 게 좋다. 이미 이슈에 게재된 정보를 업데이트하면 무엇을 고쳤는지 바로 알기 어렵다. 댓글을 통해 개발자나 기획자에게 알리면서 작업이 어떻게 진행되는지 소통하자.

하루 업무 중 가장 많은 시간을 차지하지만, 아직도 어떻게 써야 하는지 어렵다. 정도가 없지만, 읽는 입장에서 최대한 알기 쉽게 쓰려고 노력 중이다. 게임회사임에도 글쓰기가 이리 중요하다. 현직 종사자의 조언에 책을 읽어야 한다는 말이 괜히 나온 게 아니다.