버그를 찾는 것만큼 중요한 것이 버그를 잘 전달하는 것입니다. 버그 리포트가 모호하면 개발자는 문제를 재현하지 못하고, 결국 버그는 고쳐지지 않습니다. 좋은 버그 리포트는 읽는 사람이 추가 질문 없이 바로 문제를 확인할 수 있게 합니다. 이 글에서는 버그 리포트에 들어가야 할 내용과 쓰는 요령을 설명합니다.

버그 리포트의 필수 항목

이 항목들은 회사마다 이름이 조금 다르지만 내용은 거의 같습니다. 버그 관리 도구에 정해진 양식이 있다면 그 양식을 빠짐없이 채우는 것이 기본입니다.

버그 리포트를 읽는 사람은 개발자만이 아닙니다. PM은 일정을 판단하고, 기획자는 의도와 다른 동작인지 확인하고, 운영팀은 유저 문의와 연결해 봅니다. 그래서 리포트는 특정 사람만 이해하는 줄임말이나 은어 없이 누구나 읽을 수 있게 써야 합니다.

제목 쓰는 법

제목은 버그 목록에서 가장 먼저 보이는 부분입니다. 개발자와 PM은 제목만 보고 어떤 문제인지, 누가 맡을지 판단합니다. 그래서 제목만 읽어도 위치, 행동, 문제가 보여야 합니다.

• 나쁜 예: 상점 버그
• 나쁜 예: 구매가 이상함
• 좋은 예: [상점] 골드가 가격과 같을 때 구매 버튼을 누르면 골드가 차감되지 않고 아이템이 지급됨
• 좋은 예: [던전] 보스 2단계 진입 직후 파티원 1명이 화면 밖으로 순간 이동됨

대괄호로 기능 영역을 먼저 붙이면 목록에서 분류하기 쉽습니다. 제목에 감정 표현이나 추측은 넣지 않습니다.

재현 절차 쓰는 법

재현 절차는 버그 리포트의 핵심입니다. 처음 보는 사람이 그대로 따라 하면 같은 버그를 볼 수 있어야 합니다.

1. 시작 지점부터 씁니다: 로그인 후 로비 화면처럼 분명한 시작점을 정합니다.
2. 한 단계에 한 행동만 씁니다.
3. 화면과 버튼 이름은 게임 안 표기 그대로 씁니다.
4. 입력한 값이나 선택한 항목을 구체적으로 적습니다.
5. 버그가 나타나는 단계에서 끝냅니다.

재현이 항상 되지 않는 버그도 있습니다. 이럴 때는 재현율을 적고, 발생했을 때의 상황을 최대한 자세히 기록합니다. 영상과 로그가 있으면 개발자가 원인을 찾는 데 큰 도움이 됩니다.

환경 정보도 재현에 큰 영향을 줍니다. 특정 기기나 운영체제, 특정 빌드 버전에서만 생기는 버그가 많기 때문입니다. 여러 기기에서 확인했다면 발생한 기기와 발생하지 않은 기기를 함께 적어 두면 원인을 좁히는 데 도움이 됩니다.

심각도와 우선순위 판단

심각도는 문제 자체의 크기이고, 우선순위는 언제 고칠지에 대한 판단입니다. 오타는 심각도가 낮지만 출시 첫 화면에 크게 보인다면 우선순위가 높을 수 있습니다. 우선순위는 보통 PM이나 리드가 최종 결정하지만, 리포트를 쓰는 사람이 근거를 제시하면 판단이 빨라집니다.

좋은 리포트를 위한 습관

• 하나의 리포트에는 하나의 버그만 씁니다.
• 등록 전에 같은 버그가 이미 있는지 검색합니다.
• 사실과 의견을 구분합니다. 개선 제안은 따로 적습니다.
• 수정 후에는 다시 확인하고 결과를 기록합니다.

버그 리포트는 개발자와 QA가 함께 문제를 해결하기 위한 문서입니다. 비난하는 말투보다 사실을 정확하게 전달하는 데 집중하면 협업이 훨씬 원활해집니다. SBS아카데미게임학원 게임QA 과정에서는 테스트와 검수, 버그 보고까지 게임 품질관리 실무를 익힙니다.

자주 묻는 질문