결함 보고 방법

빌드를 테스트 하다가 결함을 발견하면 결함을 수정하기 위해 이슈를 작성해야 하는데 이 이슈, 티켓, 혹은 태스크에는 꼭 들어가야 할 요소들이 있습니다. TC에 기반해 테스트하고 있거나 그저 탐색적으로 테스트 하고 있을 때에도 어떤 결함을 경험한 다음 이를 수정하기 위해서는 결함 상황을 구체적으로 언급하고 결함을 가정하지 않았을 때 예상한 동작과 결함에 의해 일어난 예상하지 않은 동작을 기술한다면 꽤 좋은 버그 이슈를 만들 수 있습니다. 한편 결함 상황을 재현할 수 있다면 결함의 재현 과정을 잘 정리한다면 아마 다른 사람들이 만든 이슈보다 자신이 만든 이슈가 훨씬 더 빨리 처리되는 신기한, 한편으로는 별로 신기하지 않은 경험을 하게 될 겁니다.

그런데 이 상황에서 가장 중요한 점은 바로 이 결함에 이름을 붙이는 것입니다. 결함 이름은 결함을 주고 받는 사람들, 결함을 직접 수정할 사람들에게 결함의 종류와 원인을 순식간에 파악하게 만드는 핵심으로 작용할 수도 있습니다. 한편 모호하거나 잘못된 이름을 붙이거나 이름에 해당하지 않는 정보를 이름에 붙여 놓으면 이를 읽는 사람이 결함을 빠르게 이해하지 못하거나 결함을 잘 못 이해할 수 있고 또 이름으로부터 충분한 힌트를 얻지 못하면 본격적으로 내용을 집중해서 읽기 시작해야 하는데 경험 상 좋지 않은 이름이 붙은 이슈는 내용 역시 좋지 않을 때가 많아 이 때부터 이슈를 만든 사람에게 설명을 요청하기 시작할 겁니다.

이는 실제로 받은 지라 이름을 아주 약간 수정한 문장인데 이 문장을 처음 받은 순간부터 이 지라를 받는 순간 느낀 당혹스러움을 설명하기 위해 충분히 시간을 들여 생각해 볼 작정이었습니다. 일단 이 지라를 받고 제목을 읽었지만 문제가 뭔지 이해할 수 없었는데 가장 큰 이유는 결함을 그저 ‘노출 오류’라고만 적었기 때문입니다. 분명 이 이름을 작성한 사람은 정상적인 동작과 결함 동작을 구분할 수 있었을 겁니다. 하지만 자신이 생각하는 결함을 이 지라를 받는 사람 역시 정확히 기억하고 있거나 같은 맥락을 배경으로 한 채 지라 제목을 읽을 거라고 가정했을 것 같습니다.

하지만 지라를 받은 저는 ‘지역 이름’이 표시될 때 뭔가 문제가 있을 거라고 인식하기는 했지만 정확히 어떤 문제가 있는지는 알 수가 없었습니다. 지역 이름의 스펠이 틀렸거나 잘못된 폰트로 나왔거나 타이밍이 틀렸거나 다른 지역 이름이 나왔거나 지정된 시간 후에 사라지지 않았거나 UI 애니메이션이 안 나오는 등 그저 ‘오류’라고 표시된 동작이 무엇을 의미하는지 파악할 수가 없었습니다.

또한 이 제목에는 테스터가 예상한 오류의 원인을 함께 기입하고 있는데 분명 의도는 문제를 빨리 해결하려는 좋은 것이었겠지만 온전하지 않은 추측은 배제하는 편이 낫고 특히 제목에서는 확실히 배제해야 합니다. 우선 테스터와 개발자가 사용하는 언어가 다릅니다. 이 제목에 사용된 체크포인트는 아마도 지역 이름을 표시할 시점을 결정하기 위해 레벨에 배치해 놓은 클리전을 의미하는 것 같은데 체크포인트는 이미 게임 상에서 다른 의미로 사용되고 있어 자칫 엉뚱하게 인식하고 다른 문제를 찾는데 시간을 쓰게 될 수도 있습니다. 물론 테스트 담당자가 정확한 용어를 모르는 것은 전혀 문제가 아닙니다. 다만 정확한 용어를 모른다면 용어를 사용하지 않거나 아예 원인 추측 자체를 하지 않는 편이 상황을 개선하는데 더 큰 도움을 준다고 생각합니다.

‘캐릭터 리젠 위치’ 역시 아마도 레벨을 로딩한 다음 플레이어가 처음 나타날 위치를 설명하려고 한 것 같은데 언리얼 개발환경 기준으로 정확한 용어는 레벨에 배치한 플레이어 스타트 액터 또는 플레이어 스타트 입니다. 사실 이런 표현을 보고 아예 인식할 수 없는 것은 전혀 아니며 맥락 상 플레이어 스타트를 의미하는 거라고 어렵지 않게 추측할 수 있습니다. 그런데 이런 상황이 쌓이면 정작 팀이 아주 바빠 결함을 처리할 담당자들의 주의가 흐려진 상황에서 문제를 일으켜 그렇잖아도 부족한 결정적인 순간의 시간을 낭비하게 만들 수 있어 처음부터 서로 잘 훈련하는 편이 좋다고 생각합니다.

테스트 담당자가 예상한 원인은 이미 다양한 테스트 경험을 가지고 있는 입장에서 대부분 올바르지만 어떤 때는 예상한 원인이 결함을 일으키는 표면적인 원인일 경우도 있고 또 결함의 올바른 원인이 아닐 때도 있습니다. 이 판단은 결함 수정을 도우려는 선한 의도가 분명하지만 오히려 아주 바쁜 상황에서 이 예측만 믿고 표면적인 원인만 수정해 다른 결함일 일으키거나 근본적인 결함을 해결할 기회를 잃게 만들기도 합니다.

결론. 결함을 보고할 때는 결함 이름에 결함 상황을 잘 전달할 수 있는 명확한 언어를 사용해야 하고 내용에는 결함이 없었을 때 예상한 동작과 결함에 의한 동작, 이들 사이의 차이, 그리고 만약 가능하다면 결함을 재현할 수 있는 방법을 언급하되 정확하지 않다면 결함의 원인을 함부로 추측해 기입하지 않아야 합니다.