꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 알 수 없는 사용자

버그 리포트 작성은 테스터에게 매우 중요한 업무 중의 하나입니다.

그런데 실은 이런 버그 리포트는 테스터 외의 사람들도 할 수 있는 업무입니다.

만들고 있는 게임과 관련된 사람이라면 그리고 버그라고 생각되는 현상을 찾아냈다면 디자이너도 작성할 수 있고 PM도 작성할 수 있고 GM도 작성할 수 있고 그리고 게이머도 작성할 때가 있죠.

그럼에도 그까이꺼~ 라는 관념 때문인지 이 버그리포트에 대해 제대로 알려주지 못하는 경우가 많습니다..

실은 그 그까이꺼~ 내용이 조엘 온 소프트웨어라는 책에 잘 소개 되어 있습니다.

조엘 온 소프트웨어를 보면 좋은 버그 리포트에는 항상 3가지가 들어 있다고 합니다.

1. 버그를 재현할 수 있는 과정

2. 당초 기대했던 적정 결과

3. 버그로 인한 실제 결과

참 쉬우니까 이번 포스팅은 여기서 끝~~

예 아직 아니됩니다.

다시 3가지 내용이 뭔지 가져와 보죠.

1. 버그를 재현할 수 있는 과정

다시 조엘 온 소프트웨어의 내용을 잠시 빌려봅니다.

 

버그를 재현할 수 있는 방법을 설명해주지 않으면, 프로그래머는 도대체 어떤 버그를 말하는 것인지조차 감을 잡을 수가 없다. “프로그램이 다운되더니 시스템이 엉망이 돼 버렸어.” 아주 친절한 설명이로군. 구체적으로 무엇을어떻게했는지를 말해주지 않으면 프로그래머는 아무것도 할 수가 없다. 정확한 버그 재현 과정을 설명하기 어렵다는 점을 프로그래머가 인정할 수 있는 경우는 두 가지다. 첫 번째는 가끔씩 그저 기억이 잘 나질 않거나 혹은 그냥 “필드” 테스트에서 버그 결과만 그대로 옮기는 경우다. (그런데, 왜 “필드”(field, 밭)이라는 말을 쓸까? ‘호밀밭’ 할 때 그 밭하고 같은 의민가? 아무튼…). 버그 재현 과정을 정확하게 보고하기 어려운 또 다른 경우는 버그가 매번 발생하는 것이 아니라 이따금씩 발생하는 경우다. 하지만, 이런 경우에도 버그 재현 과정은 설명해주어야 한다. 버그가 자주 발생하는 것은 아니라는 주석과 함께. 이처럼 정확한 버그 재현 과정을 파악할 수 없는 경우 버그를 찾아내기란 매우 어렵지만, 그래도 프로그래머들은 디버깅을 시도한다.

 

자세히 잘 써주면 됩니다. 라는 내용이긴 합니다만 몇 가지 예를 좀 골라보겠습니다.

  • 테스트 환경

    - Client의 Version 혹은 Revision을 명시한다.

    - 개발서버 혹은 테스트 서버가 따로 있다면 서버 이름도 명시한다.

  • 장문보다는 짧고 순차적인 단문으로

    - 프로그래머에게 국어 시험 풀게 하는 것도 아닌데 굳이 장문으로 상황을 길게 쓰는 것 안 좋습니다. 디버깅도 일인데 문장 해석까지 시켜야 할까요.

    - 1,2,3,4로 스텝을 나눠가며 단문으로 나눠 적는 것도 좋습니다.

  • 보편적 단어 통일된 단어를 사용한다.

    - 같은 뜻을 얘기하는데 서로 다른 단어를 쓰는 경우가 흔하게 있습니다. 미리미리 통일시켜줘야 나중에 업무상에도 편합니다.

    - 예를 들면 프랍=메쉬=프록시 요런거 보통 비슷한 뜻으로 쓰는데 다르기도 하고 그러죠.

  • 육하원칙 아시죠?

    - 누가? 내 캐릭터가? 저노마가? 저 NPC가? 저 몬스터가?

    - 언제? 몇 시경에? 서버에 log가 남는다면 log 내용 찾을 때도 쓸 수 있겠죠.

    - 어디서? 어떤 맵에서? 맵이름을 몰라? 그럼 좌표는?

    - 무엇을? 어떻게? 왜? 상황에 대한 자세한 설명이 필요합니다.

  • 버그 발생의 조건 최소화하기

    - 버그라는 게 발생할 때의 조건이 제한적이지 않을 때도 있습니다.

    - 이왕이면 제한적인 조건을 찾아내는 게 프로그래머가 원인을 파악하는데 시간을 줄일 수 있으니 좋죠.

    - 하.지.만. 제한적인 조건을 찾는데 시간을 너무 들이지 않는 것이 좋습니다. 10분 동안 재현 스텝을 찾아보고 그래도 안 나온다면 그냥 리포트를 보내세요.

    - 가끔은 테스터보다 프로그래머분들이 더 빨리 문제 상태만 보고 원인을 찾아내기도 합니다. (마음속 한구석에 자리잡고 있던 어떤 의심이라던가.. 그런거 있잖아요.)

    - 그리고 그 문제 조건 찾느라 다른 거 테스트 못하면 그만큼 더 손해랍니다. 언제나 테스트를 위한 시간은 한정적이니 잘 조절하세요.

이 1번 항목이 원래 가장 까다롭습니다. 그만큼 중요한 것이기도 하구요. 프로그래머에게 이쁨받는 테스터가 되려면 이게 중요하다고 해도 과언이 아닙니다.

2. 당초 기대했던 적정 결과

또 조엘 온 소프트웨어를 보죠..

 

또, 당초기대했던적정상태가 어떤 것인지 구체적으로 이야기해주지 않으면, 프로그래머는 도대체 이게 왜 버그라는 것인지 이해할 수 없게 된다. 스플래쉬 화면에 핏자국이 있어요. 그래서요? 그건 코딩할 때 내가 손가락을 다쳐서 그때 묻은 거예요. 도대체 그게 뭐가 잘못됐다는 거죠? 아, 원래 스펙에는 핏자국은 포함되지 않았다는 말이구나. 진작에 그렇게 말씀을 해주시지.

저는 양키 개그는 언제나 훌륭하다고 생각하는데 저 개그는 좀………

테스터 혹 문제를 발견한 사람은 이것이 문제라는 것을 인지하고 리포트를 보냅니다. (그러니까 보내겠죠?)

하지만 프로그래머는 그것이 무엇을 원하는지 모르는 경우가 있습니다.

“내가 왜 이걸 버그라고 하는지 오빠는 몰라?”

여러분이 프로그래머의 여자친구는 아니잖아요? 나는 모르겠는데 넌 대체 왜 그러는 거니?

그러니 순순히 여러분이 보내는 리포트에는 정상 상태의 결과도 적어서 보내주세요. 밀당은 이성 사이에서만 합시다.

3. 버그로 인한 실제 결과

마지막으로, 버그로 인한 결과를 설명해줘야 프로그래머가 버그의 정체를 알 수 있다. 마지막 규칙은 비교적 지키기 쉬운 편이다. 눈에 보이는 상태를 이야기하면 되니까.

마지막은 쉽습니다.

보이는 그대로의 상태를 적으면 되는 거니까요.

1번하고 뭐가 다르냐고 생각하실 수 있습니다. 1번은 과정을 중요시하는 것이고 3번은 말 그대로 결과만을 얘기하는 것입니다.

어떤 행동을 했더니 클라이언트가 강제 종료되었다.

어떤 몬스터를 사냥했는데 경험치가 들어오지 않았다.

골대에 골을 넣었는데 상대방 스코어에 점수가 올라갔다.

위 내용에서 파란색 내용만 없다고 생각해보죠. 버그로 인한 결과 내용이 빠진다면 프로그래머는 이게 그래서 왜 버그인지 이해하기 어려울 것입니다.

설명이 좀 됐을까요?

쉬운 내용임에도 다시 쉽게 쓸려니 좀 부끄럽고 그렇습니다.

하지만 버그 리포트를 쓰는 법에 대해서 생각해 볼 기회가 많진 않잖아요. 누가 열심히 설명해 주는 내용도 아니구요.

간혹 버그를 발견해서 리포트를 전달해 줬더니 뭔 말인지 모르겠다고 면박당하거나 아니면 고치고 있는지 장을 담그는지 반응도 없고…

게임 회사의 모든 사람들이 저렇게 버그 리포트를 작성해준다면 프로그래머도 행복하고 자기가 발견한 문제도 아니지만 어쨌든 수정됐다고 확인해달라고 버그 리포트를 재전달 받는 테스터도 행복하고 자기가 발견한 버그가 빨리 고쳐진다면 모두모두 행복하겠죠?

그런 기분 좋은 업무 환경이 되기를 바라며 작성해 보았습니다.

봐주셔서 감사합니다.

반응형
,