버그 리포팅을 도와주는 7가지 팁

 

 

 

 

 

 

거의 한 달 가량 포스팅을 하지 못했습니다.

 

지난달 2년 2개월 동안 몸담았던 회사를 떠나게 되었고 이후 한 달이 조금 넘는 기간동안 새로운 업무 환경과 프로세스에 적응하느라 눈코뜰새가 없었습니다. 이전 회사에서는 게임 퍼블리싱 QA로 일했던 반면, 이번에 회사를 옮기면서 다시 게임 개발 QA로 돌아오게 되었습니다. 게임 역시 소프트웨어의 한 분야이고 게임 테스팅 역시 소프트웨어 테스팅의 범주에서 벗어나지 않으므로, 퍼블리싱 QA 일을 하든 개발 QA 일을 하든 가장 많은 시간을 할애하는 것은 다름아닌 버그 리포팅입니다.

 

형사들의 수사 보고서에 비유되는 이 버그 리포트를 수없이 작성하고 리뷰해 보면서 느낀 점은, 누구나 버그 리포트를 작성하지만 그만큼 잘 작성하는 것이 정말 어렵다는 점입니다. 소프트웨어 테스팅을 다룬 책이라면 반드시 한 단원을 할애하는 필수 항목이기도 하고 모든 회사의 QA 입문 교육에서도 반드시 포함되는 주제지만 실무에서 쉽게 적용할 수 있는 수준의 교육 보다는 원론적인 이야기에 머무르는 경우가 많은 것 같습니다.

제 스스로 실무를 겪으면서 이런 점들을 좀 더 신경쓴다면 더 나은 버그 리포팅이 될 거라고 생각해 왔던 점들을 정리해 봤습니다.

 

1.   기본적인 문법과 오탈자에 주의하자

말 그대로 버그 리포트도 작문(作文), 즉 글짓기입니다. 글짓기는 글을 쓴 사람이 자신의 의도를 글을 읽는 사람에게 글로써 전달하는 행위를 뜻합니다. 이런 글짓기에서 가장 기본적인 항목이 바로 문법과 철자입니다. 가끔 버그 리포트를 리뷰하다 보면, 주어와 목적어가 생략되기 일쑤고 문장 구성에 맞지 않는 단어를 사용해 도대체 무슨 말을 하고 싶은 건지 파악을 할 수 없는 경우가 더러 있습니다. 누구나 다 안다고 생각하더라도 반드시 완전한 문장 형태를 구성하고 기본적인 문법을 준수해 명백하게 의사를 전달하는 것이 필요합니다.

 

더불어 리포트에 오탈자가 있지는 않는지 점검하는 것도 잊지 말아야 합니다. 테스터의 능력을 파악할 수 있는 방법 중 하나가 바로 그 테스터가 작성한 문서를 살펴보는 것입니다. 오탈자가 많은 문서를 만드는 테스터라면 그 사람이 수행하는 실제 테스트 업무에도 실수가 많을 가능성이 높습니다. 또한 내용이 아무리 완벽하다고 하더라도 오탈자로 인해 그 내용의 신빙성이 떨어질 수 있습니다. QA가 작성하는 모든 문서에서 이런 기본적인 원칙을 지켜야 한다는 점은 아무리 강조해도 모자라지 않을 것 같습니다.

 

2.   보기 좋은 리포트가 재현하기에도 좋다

버그 리포트는 일정한 형식을 갖추고 일정 수준 이상의 가독성을 보장해야 합니다. 한 제품 혹은 한 번의 테스트 스위트에서 발생하는 버그 리포트의 수는 일반적으로 최소 수십개에서 많게는 수 천개에 달합니다. 개발자 혹은 다른 테스터들이 이 정도 분량의 버그 리포트를 참조해 동일한 이슈를 재현하려면, 반드시 읽기 편하게 잘 정리된 템플릿을 사용해야 합니다. BTS(Bug Tracking system)를 사용하지 않고 액셀과 같은 스프레드 시트를 사용하더라도 템플릿을 만들고 활용해야 합니다. 이를 통해 작성된 보고서를 읽는 사람이 좀 더 용이하게 보고서의 각 항목을 이해할 수 있도록 해주어야 합니다.

 

 

3.   구체적인 단어로 디테일하게 작성하자

 

 “게임이 끝나도 결과가 나오지 않는 문제”

 

실제로 제가 본 버그 리포트의 제목입니다. 어떻게 생각하시나요? 제가 본 거의 대부분의 버그 리포트가 이 정도 수준의 단어들을 사용하고 있습니다. 물론 저 문장만 봐도 어떤 게임의 결과에 문제가 있구나 라는 걸 알 수 있지만, 그 이상의 자세한 정보를 알 수가 없습니다. 결국 저 버그 리포트를 읽은 사람은 보고한 사람에게 좀 더 많은 정보를 요청하게 되거나, 그도 용이하지 않다면 스스로가 상황을 유추해 보면서 버그를 재현해 보는 것 밖에는 방법이 없습니다.

 

가급적이면 일반 명사보다는 고유 명사를, 대항목 보다는 소항목을, 성격을 나타내는 형용사보다는 수치를 보여주는 형용사를 사용하는 것이 좋습니다.

 

위 문장을 아래 처럼 바꿔본다면 어떨까요?

 

“1종의 PvE 모드(컨테이너 맵)에서 게임이 종료된 후 스코어와 경험치를 보여주는 결과 화면이 표시되지 않음”

 

물론 제가 만든 예제 역시 모든 정보를 정확하게 전달하고 있는 것은 아닙니다. 다만 상황에 맞게 가급적이면 필요한 정보를 자세하게 전달해 주는 것이 좋습니다. 제목이냐 혹은 스텝이냐에 따라서도 디테일의 정도가 달라질 수 있습니다. 그 점은 아래에서 다시 언급하도록 하겠습니다.

 

4.   기본적인 항목을 충실히 기록하자

버그 리포트에 어떤 항목들이 포함되어야 하는지는 다양한 제품과 업무 환경에 따라 달라지기 마련입니다. 다양한 테스팅 표준에서도 제안하는 항목들이 있지만 그 모든 것을 문서에 담기는 사실상 힘듭니다. 현실적으로는 리포트를 작성하고 활용하는 부서들이 어떤 항목을 포함할지 합의하는 것이 가장 좋습니다. 제 개인적으로 아래 항목들은 반드시 포함되어야 한다고 생각합니다.

 

제 목

이슈 파악이 가능할 정도의 제목이 포함되어야 합니다. 너무 자세하게 늘여쓰는 것도 좋지 않지만, 너무 간략하게 쓰는 것도 이해를 돕지 못합니다. 말로 표현하기 참 힘든 부분인데, 한 줄 정도의 텍스트로 간략한 정황 파악이 될 정도로 표현하는 것이 좋은 것 같습니다.

 

재현 단계

재현 단계를 자세하게 기록합니다. 예전에 PC 호환성을 테스트할 때, 제가 작성하는 모든 리포트의 첫 단계는 “1. PC의 전원을 넣는다” 였습니다. 기본적으로는 제품과 테스트에 대해 잘 모르는 사람이 보더라도 스텝만 따라했을 경우 해당 이슈를 재현할 수 있어야 한다는 것이 기본적인 원칙입니다. 

 

그러면서도 모든 재현 단계가 총 10단계를 넘지 않는 것이 좋습니다. 한 스텝으로 하나의 공정을 표현하는 것이 좋습니다만, 각 단계의 메뉴를 거쳐갈 경우에는 “A -> B -> C” 등의 스텝을 한 줄로 요약하는 것도 효율적입니다. 재현 단계를 기록하는 것은 버그 리포트의 핵심이면서도 가장 어려운 부분 중의 하나입니다. 많은 경험과 고민을 통해 지속적으로 개선해 나가야 할 부분인 것 같습니다.

 

재현율

최근 제가 본 리포트들 중에서 가장 찾기 힘든 항목이 바로 이 재현율이었습니다. 100% 재현이 가능하다 하더라도 이를 명시해 주어야 하며, 불규칙적으로 재현되는 부분은 대략 몇 % 정도의 재현율을 가지고 있다고 명시해 주어야 합니다. 재현이 아주 힘든 경우라면, ‘재현이 안된다’가 아니라 ‘총 30회 시도했으나 그 중 한번도 재현되지 않았다’ 등의 구체적인 시도회수 대비 재현회수를 명시해 주는 것이 도움이 됩니다.

 

재현 환경

기본적으로 문제가 발생한 시스템의 하드웨어, 소프트웨어 및 테스트한 제품의 버전을 명시합니다. 이는 특정 시스템에서 난 문제가 아니더라도 반드시 기록되어야 하는 부분이며, 형상관리를 위해 반드시 필요한 부분입니다. 윈도 시스템의 경우에는 dxdiag 파일을 첨부하는 것도 좋은 방법입니다. 

 

중요도와 우선순위

발견된 이슈가 가지는 중요도와 우선순위를 기록합니다. 회사와 환경에 따라 중요도(Severity)와 우선순위(Priority)를 구별하는 경우도 있고 그렇지 않는 경우도 있습니다만, 가급적이면 이를 구별해 주는 것이 좋습니다. 사전에 정해진 규약에 따라 객관적으로 두 항목을 판단해 기록하는 것이 중요합니다. 이전 회사에서 “버그 인플레이션(Bug inflation)”라는 단어를 사용한 적이 있습니다. 테스터들이 스스로 등록하는 모든 버그를 모두 중요한 버그라고 간주해서, 버그가 발생해 끼치는 영향을 더 심각하게 판단하도록 만든다는 의미에서 사용한 단어였습니다. 사소한 버그임에도 불구하고 테스터들은 스스로 발견한 버그를 절대 사소하지 않은 것으로 치부하는 경향이 있고, 이는 QA의 신뢰성 하락으로까지 이어질 수 있습니다. 어렵지만 객관적인 기준을 가지고 중요도와 우선순위를 기록해야 합니다. 경험이 풍부한 시니어 혹은 리드와 함께 중요도와 우선순위를 리뷰하는 프로세스를 마련하는 것도 권장할만 합니다. 버그 라이프사이클 안에서 이 값들이 변경될 수 있음도 유념해 두어야 합니다.

 

5.   태그를 활용하자

수백 수천 개의 버그 리포트가 누적되면 나중에 검색하고 정리하는데 어려움이 많습니다. 이를 해결하기 위해 리포트의 제목에 태그를 활용하는 것이 좋습니다. JIRA와 같은 툴들이 이미 이 기능을 지원하고 있습니다. 사람마다 필요하다고 마구잡이로 생성하는 것보다 공용 문서에서 이를 관리하는 것이 좋습니다.

 

6.   그림 파일과 동영상을 첨부하자

텍스트만으로는 버그를 충분히 설명하기 힘든 경우가 많습니다. 그런 경우 BTS의 첨부파일 이나 스프레드 시트의 이미지 삽입, 오브젝트 삽입 등의 기능이 많은 도움이 됩니다. 가급적이면 이런 미디어 파일을 활용해 구체적인 정보를 전달해 주는 것이 좋습니다.

 

그림 파일의 경우에는 픽픽이나 칼무리 등의 이미지 편집 프로그램을 활용해 이슈가 되는 부분을 표시하고 간략하게 증상을 설명해 주는 것이 좋으며, 동영상 파일의 경우에는 일반적으로 쉽게 사용가능한 포맷을 활용하되 가능하다면 추가 인코딩을 통해 파일의 용량을 줄여주는 것이 좋습니다.

 

또한 게임 클라이언트에서 로그 파일을 제공한다면 로그 파일을 첨부해 주는 것도 좋은 방법입니다. 버그 트래킹을 범죄 수사에 비유한다면, 로그는 범죄 현장의 시공간을 있는 그대로 기록해 놓은 CCTV 기록에 견줄만 합니다. 로그 파일을 첨부하는 이슈와 그렇지 않는 이슈를 트래킹하는 것은 천지차이입니다. 제품이 로그 파일을 제공한다면 반드시 이를 첨부해주고, 개발자에게 문의해 로그 파일을 분석하는 법을 익힌다면 그야말로 금상첨화 입니다.

 

7.   리포트를 작성하면 반드시 퇴고하라

개발자가 개발 테스팅도 수행하지 않고 제품을 QA에 넘기는 경우 여러분은 어떻게 반응하시나요? ^^

 

그 반대의 경우가 바로 우리가 작성한 버그 리포트를 별도의 검토 과정도 없이 바로 시스템에 업데이트하고 이를 개발자가 재현하려고 시도하는 경우입니다. 개발자가 개발이 완료된 후 개발 테스팅을 수행하듯, QA는 모든 리포트 과정이 완료된 후 반드시 빠진 부분은 없는지 다시 한 번 꼼꼼하게 검토하고 리포트를 등록하는 습관을 가지는 것이 좋습니다.

 

 

버그 리포트를 작성하면서 나름 주의해야할 항목이라고 생각했던 것들을 적어봤습니다. 하지만 이외에도 고려해야할 내용들은 여전히 많습니다. QA 스스로가 어떻게 하면 효율적으로 버그 리포트를 할 수 있을지에 대해 끊임없이 고민해야 합니다. 저 역시 지금도 가장 어려움을 느끼는 일 중의 하나가 바로 버그 리포트를 작성하는 것입니다. 개발자들이 쉽게 알아볼 수 있을까, 내가 잘못 전달하고 있어서 다시 작업을 해야 하지는 않을까 등을 늘 신경쓰면서 작성할 수 밖에 없습니다.

 

이런 버그 리포팅을 포함한 효과적인 문서 작성을 위해 주변의 QA들에게 늘 책을 많이 읽고 글을 많이 써보라고 이야기 합니다. 저 스스로도 그러려고 노력하고 있습니다. 이런 점에서 볼 때 QA는 스스로 엔지니어이기도 하고 테크니컬 라이터이면서, 또한 테크니컬 스토리텔러가 되어야 하는 것 같습니다.

 

참 쉽지 않은 직업입니다.

하지만 그래서 더 재미있는 거겠죠? ^^