버그 리포팅, 개발자에게 효과적으로 전달하기

 

QA는 테스트 중 버그를 발견하면 이 버그에 대한 정보를 수집하여 이슈화 하는 작업, 즉 버그 리포팅을 진행하게 됩니다.

이렇게 생성된 이슈는 개발자에게 전달되고 수정 작업을 거쳐 해소될 때까지 관리가 이루어집니다.

하지만 이슈는 종종 해소를 시작하는 과정에서 원인 파악에 많은 시간이 소요되기도 하고, 그 만큼 수정 작업에 착수하는데도 딜레이가 발생하곤 합니다. 왜 이런 경우가 발생하게 될까요?

여러가지 경우가 있겠습니다만, 경험으로 빗대어 봤을 때 이런 경우는 대게 이슈에 대한 정보가 부족하거나 잘못된 경우가 대표적입니다.

 

이번 포스팅에서는 이 경우가 가급적 발생하지 않도록, 보다 효과적으로 개발자가 이슈에 대한 파악을 할 수 있도록 버그 리포팅을 어떤 방법으로 작성해야 하는지에 대해 다루어 보고자 합니다.

 

 

버그 리포팅은 무엇인가요?

서두에서도 언급했지만, 버그 리포팅은 단어 의미 그대로 버그(Bug)를 리포팅(Reporting) 하는 것. 발생한 결함에 대해 알리는 것을 의미합니다. 테스트를 진행하며 필연적으로 수행하게 될 업무이자 버그를 수정하여 빌드의 안정성을 확보하는 매우 중요한 요소입니다. 대게 QA가 이 업무를 수행하며 이슈의 생성부터 종료까지의 전체적인 상태를 관리합니다.

여담으로 프로젝트 규모가 작아 QA 조직이 없는 경우, 개발자가 자체적으로 수행하는 경우도 더러 있습니다.

 

 

버그를 등록할 때 필수로 포함해야 할 요소들

그렇다면 버그 리포팅을 진행할 때 어떤 정보들이 이슈에 포함되어야 개발자가 효과적으로 버그에 대해 캐치할 수 있을까요?

이해가 쉽도록 실무에서 보편적으로 사용하는 JIRA를 기준으로 리뷰해보겠습니다.

우리에게 친숙한 JIRA 양식으로 가상의 버그를 만들어 보았습니다.

우리의 목표는 담당자(개발자)에게 부연 설명 없이 이 이슈를 전달한 것 만으로도 명확하게 문제의 현상과 원인을 전달하는 것입니다. 이를 위해 이슈 내용에 필수적으로 포함되어야 하는 요소들에 대해 알아보도록 하죠.

 

요약(Summary)

이슈의 간판이 되는 요약이 첫 번째 요소입니다.명심하세요. 요약은 단어가 내포하는 의미에서도 알 수 있듯이 최소한 간결하면서도 명확해야 합니다.요약이 쓸데없이 길고 두루뭉슬하게 작성이 된다면, 담당하게 될 개발자도 문제가 무엇인지 헷갈릴 뿐더러 작성한 본인 조차도 나중에 이 이슈를 보면 기억이 가물가물해질 가능성도 높습니다. 특히나 생성된 이슈가 많은 상태에서 각각의 요약이 명확하지 못하다면 이슈 리스트에서도 특정 이슈를 찾아내는데 애를 먹을 수도 있겠습니다.한 가지 팁이 있다면, 사전에 버그의 발생지를 콘텐츠를 기준으로 분류해두고 해당 콘텐츠에서 발생한 버그를 이슈화 할 때 말머리로 콘텐츠명을 사용하는 방법입니다.가상의 버그 기준으론 '사냥' 이라는 콘텐츠에서 버그가 발견된 건이므로 말머리를 [사냥]으로 붙여 연관된 이슈 관리를 용이하게 할 수 있습니다.

 

 

우선순위/심각도(Priority/Serverity)

두 번째 요소로 우선순위/심각도가 있습니다.요약이 이슈의 간판 역할을 한다면, 우선순위는 이 버그의 중요도를 나타내는데 사용됩니다.우선순위의 분류에 따라 이 버그가 얼마나 긴급하게 수정되어야 하고, 나중에 수정되어도 무방한지를 알 수 있게 해줍니다.버그가 산발적으로 발생하는 상황에서 프리징, 크래시 이슈와 같은 크리티컬한 버그와 UI 겹침, 오탈자 이슈와 같은 마이너한 버그가 혼재되어 있을 때 우선순위가 누락되어 있거나 엉뚱하게 지정돼 있다면 수정 작업이 비효율적으로 이루어질 가능성이 높겠죠? 빌드의 안정성이 최대한 높이기 위해서는 우선순위를 정확하게 분류하여 중요하고 긴급한 이슈가 먼저 대응되도록 해야 합니다.

 

 

발생 버전(Affects Version)

다음으로는 발생 버전입니다. 버전을 나눠 관리하는 개발 환경인 만큼 어느 버전에서는 발생하지만 또 어느 버전에서는 발생하지 않는 버그일 수 있습니다. 그렇기에 이슈 내용에는 버그가 어느 버전에서 발생하고 있는지 기재되어야 혼선을 방지할 수 있습니다. 보고자가 A 버전에서 테스트 중 발견한 버그를 이슈화 했지만 수정 담당자가 이슈 재현 여부를 B 버전에서 확인 했을 때 재현되지 않는다면 원인 파악하는데 빙 돌아가게 되는 경우도 생각보다 많습니다.추가로 조금 더 세분화 해보자면 발생 버전과 더불어 발생 서버도 제공하는 것이 좋습니다. 특히나 버그가 서버 로직 관련 이슈라면 더욱 빠르게 원인 파악을 할 수 있게끔 도울 수 있습니다.

 

 

OS(Operation System)

OS도 발생 버전 못지 않게 중요한 요소입니다. 모바일을 예시로 Android 환경에서는 발생하지만 iOS 환경에서는 발생하지 않는 버그도 존재합니다. 물론 이런 경우 OS가 달라 발생하는 이슈인 만큼 특정 부류에 관련된 버그라 비교적 발생 빈도가 높은 편은 아니지만 발생 환경을 정확히 전달해 엉뚱한 OS에서 살펴보는 일이 없도록 사전에 공유되어야 합니다.

 

 

재현 확률(Probability)

"저는 버그가 재현되지 않아요."개발 담당자로부터 재현이 되지 않는다는 회신을 받게 된다면 재현 확률이 혹시 이슈 사항에 누락되어 있었던 것은 아닌지 확인해보아야 합니다. 의외로 이 요소를 간과하거나 누락해서 혼선을 빚는 경우가 많은데요, 대부분의 기능 이슈의 경우 A 조작을 통해 B의 결과가 100% 나오기에 확률 정보를 굳이 적지 않아도 이슈 수정하는 과정에서는 대게 문제가 되지 않기 때문입니다. 그러나 상황에 따라 간헐적으로 발생하는 버그도 분명히 존재하기에 가급적 이슈업 시 재현 확률도 필수 요소로 포함하여 전달하는 것이 좋습니다. 팁으로, 요약에서 "간헐적으로" 라는 키워드를 포함시켜 요약부터 해당 이슈가 100% 확률로 발생하는 버그가 아님을 명시해주는 방법도 추천드리고 싶습니다.

 

 

사전 조건(Preconditions)

담당 개발자가 이슈 상의 콘텐츠에 대해 빠삭하게 알고 있다면 발생하는 버그에 대한 재현 확인 및 원인 파악에 큰 어려움이 없을 것으로 보입니다. 하지만 담당 개발자가 콘텐츠의 세부적인 내용에 대해 인지하고 있지 않은 상태나(대게 메인 담당자 부재로 다른 담당자가 맡거나, 프로젝트에 갓 합류하여 적응하는 중인 신규 담당자가 맡게 되는 경우가 해당됨) 재현하는 과정에 여러가지 사전 세팅이 필요한 경우가 많을 경우, 사전 조건을 필수적으로 기재하는 것을 권장합니다.위 버그의 경우 A 디버프를 적용하기 위해 A 디버프 활성 아이템(ID: 104)을 보유해야 하고, 버그가 발생하고 있는 사냥터에 진입하기 위해 사냥터 콘텐츠를 해금해야 하는데 이러한 정보를 모른다면 어떻게 디버프를 적용시키고 사냥터에 어떻게 이동할 수 있는지 헤멜 수 있습니다. 더 나아가 이슈가 수정되어 수정 작업에 대해 다른 QA가 테스트를 하게 되었을 때 사전 조건을 모른다면 동일하게 헤멜 가능성이 높겠죠?

 

 

재현 스탭(Steps to Reproduce)

이슈의 주축이 되는 요소인 재현 스탭 입니다. 발생 중인 버그를 재현하여 원인을 파악하고자 할 때 이슈 상에 재현 스탭이 기재되어 있지 않다면 당연히 정보 전달에서 큰 어려움이 생길 것입니다. 이슈를 등록할 때 누락되는 경우는 거의 없습니다만 그 만큼 중요한 요소임을 인지해야 합니다. 재현 스탭은 요약에서 충분히 전달하지 못한 정보를 보다 네러티브하게 풀어서 전달하는 역할을 맡습니다. 추가로 이 요약과 재현 스탭에서 사용하는 키워드와 내용이 일관성 있게 작성되도록 하는 것이 전달받는 입장에서도 쓸데 없이 많은 정보를 얻지 않도록 유의해야 합니다.

 

 

실행 결과(Actual Result)

실제 해당 재현 스탭으로 조작했을 때 발생하는 결과에 대한 내용입니다. 말 그대로 버그에 대한 문제점을 지시하는 요소이며 요약과 다소 유사한 결을 가집니다. 결과가 어떻게 나왔는지 이 요소에서 명확하게 전달되어야 합니다.명확하게 전달되어야 하는 또 다른 이유 중 하나는 실행 결과가 실제로 이슈 사항인지 아닌지를 판단하는 잣대로 사용되기 때문입니다. 내용에 따라 테스트 담당자(QA)가 오인해서 버그로 착각한 것일 수도 있고, 버그로 취급하지 않고 노운 이슈로 처리하는 경우도 많습니다.

 

 

기대 결과(Expected Result)

마지막 요소인 기대 결과입니다. 재현 스탭과 같이 조작했을 때 의도된 대로라면 이렇게 동작할 것이다에 대한 내용이 추가되어야 합니다. 이 내용은 기획서(명세서)를 기반으로 명시되어야 하며 참고한 기획서의 출처 등을 같이 기재하는 방법도 효과적입니다.

 

 

추가 요소는 프로젝트에 맞게 유동적으로

이렇게 개발자에게 효과적으로 이슈를 전달하기 위해 보편적으로 중요도가 높은 요소들을 다루어 보았는데요. 어떤 프로젝트에서는 부가적인 요소가 또 다른 프로젝트에서는 필수적인 요소로 취급될 수도 있습니다. 중요도가 높은 요소는 필수적으로 가져가면서 프로젝트의 성격, 상황에 맞게 유동적으로 구성하여 이슈를 전달하는 것이 보다 효과적으로 이슈를 만드는데 적잖이 도움이 될 것이라 생각합니다.

 

감사합니다.