[번역] 효과적으로 버그 리포팅 하기

이 글은 직접 번역한 글입니다. 처음 해 본 번역이라 매끄럽지 않을 수도 있습니다. 어색한 부분이 있을 경우에 알려주세요 :) 

How to Report Bugs Effectively

by Simon Tatham, professional and free-software programmer (원문보기)

• 효과적으로 버그리포팅 하기

• by Simon Tatham, 전문 프로그래머이자 자유소프트웨어 프로그래머

• 서론

• 공개 소프트웨어를 작성해본 사람이라면 적어도 한번쯤은 나쁜 버그 리포트를 받은 적이 있을 것입니다. "이거 안되요."와 같은 아무 의미 없는 리포트이거나 충분한 정보를 주지않거나 잘못된 정보를 주는 리포트 같은 경우 말이죠. 그러한 문제들은 사용자의 실수, 다른 프로그램의 잘못이나 네트워크 오류로 밝혀 집니다.

• 기술 지원에 관련된 업무가 끔찍하게 보이는 이유가 있습니다. 바로 나쁜 버그 리포트 때문이죠. 그렇다고 해서 모든 버그리포트가 불친절한 것은 아닙니다. 생계를 위해 하고 있는 일은 아니지만 저는 무료소프트웨어를 관리합니다. 그리고 때때로 명쾌하고 도움이 되며 유익한 버그 리포트를 받곤 합니다.

• 저는 이 글을 통해 어떠한 요소가 좋은 버그 리포트를 만드는지 설명하려고 합니다. 가능하면 전 세계의 버그리포팅을 하려는 사람들은 버그 리포팅을 하기 전에 이 글을 읽었으면 좋겠습니다. 특히 나에게 버그리포트를 하려는 사람들은 이 글을 읽었으면 좋겠습니다.

• 간단히 말해서, 버그리포트의 목적은 프로그래머가 프로그램의 잘못 된 점을 알게 하는 것입니다. 당신은 어떻게 하면 오류가 발생하는지 직접(실제로) 보여주거나 오류를 재현하는 방법을 자세하게 알려 줄 수있습니다. 만약 프로그래머들이 오류를 재현할 수 있으면, 그들은 오류를 만드는 원인을 알게 될 때 까지 정보를 모을 것 입니다. 만약 그들이 오류를 재현하지 못한다면, 그들은 더 많은 정보를 얻기 위해 당신에게 물어봐야 할 것입니다.

• 버그리포트에서 , 명확한 사실("나는 이렇게 했고, 이런일이 벌어졌어요")과 추측(내생각에 이것때문이야!) 을 명확히 구분하려고 노력하세요. 사실은 놓치지 말고, 만약 원한다면 추측은 생략하세요.

• 당신이 버그를 보고할 때(버그를 보고한다는 것은), 버그가 고쳐지길 원하기 때문에 그렇게 하는 것입니다. 프로그래머에게 욕을 하거나 의도적으로 불편하게 하는 것은(being deliberately unhelpful) 아무 소용이 없습니다. 그건 아마도 프로그래머의 실수 이거나 당신의 잘못일 것입니다. 물론 당신은 그들에게 화낼 권리는 있지만 ,그것보다는 프로그래머가 원하는 모든 정보를 제공하여 돕는 편이 버그가 좀 더 빠르게 고쳐질 것입니다. 또한 소프트웨어가 무료라는 것은 저자(프로그래머)가 친절한 마음에서 베풀고 있는 것라는것을 명심하길 바랍니다! 
  너무 많은 사람들이 개발자한테 무례하게 군다면 그들은 소프트웨어를 무료로 배포하는 친절을 그만 둘 수도 있습니다.

• "이거 안되요."

• 프로그래머에게 당신의 기초 정보를 공유하세요. 만약 프로그램이 전혀 작동하지 않았다면 프로그래머들은 알고 있을 것입니다. 프로그램이 전혀 동작하지 않는 다는걸 알아차리지 못했기 때문에, 당신의 기초 정보를 제공하는 것은 반드시 효과적일 것입니다. 그들과 조금 다르게 프로그램을 사용 하거나, 프로그램을 사용하는 환경이 다를 것입니다. 프로그래머들은 정보가 필요하고 이러한 정보를 제공하는 것이 버그리포팅의 목적입니다. 언제나 정보는 많으면 많을수록 좋은법입니다.

• 많은 프로그램들, 특히 무료 소프트웨어는 알려진 버그들의 리스트를 발행합니다. 알려진 버그 리스트를 찾는다면 자신이 발견한 버그가 이미 그 리스트에 있는지 확인하기 위해 읽어 볼만한 가치가 있습니다. 만약 이미 그 리스트에 등록되어 있는 버그라면 중복으로 리포팅 할 필요는 없습니다. 하지만 생각하기에 해당 버그와 관련한 보고되지 않은 추가 정보가 있다고 생각된다면, 당신은 어쨌든 프로그래머에게 연락하길 원할지도 모릅니다. 만약 당신이 그들이 진작에 갖고있지 않은 정보를 제공한다면 그들은 버그를 더 쉽게 고칠수 있을 지도 모릅니다.

• 이 에세이에서 버그리포팅에 대한 가이드라인을 설명하고 있지만, 절대적인 규칙은 아닙니다. 몇몇의 프로그래머들은 그들만의 버그리포팅 방법을 가지고 있습니다. 만약 프로그램이 버그리포팅 가이드라인을 함께 제공한다면 그 가이드라인을 읽으세요. 프로그램에서 제공하는 버그리포트 가이드가 이 에세이와 다르다면 프로그램과 함께 온 가이드라인을 우선적으로 따르십시오.

• 버그 리포팅을 하지 않더라도 프로그램에 대해 물어 볼 수 있으며 이때 당신은 어느 부분에서 이 질문에 대한 답을 찾아봤는지 언급해야 합니다. ("제가 챕터4 색션 5.2을 살펴봤는데 제가 찾고있는 기능에 대해 나와있지 않아요") 와 같이 적어주는 것은 프로그래머가 사람들이 프로그램을 사용하다가 모르는것이 있을때 주로 문서의 어느 부분을 보는지를 알게 할 것이고, 이러한 행동들은 문서를 좀더 편리하고 유용하게 만들 수 있습니다.

• "보여주세요!"

• 버그리포팅을 하는 좋은 방법 중 한가지는 프로그래머에게 직접 보여주는 것입니다. 프로그래머를 당신의 컴퓨터 앞으로 데려온 다음, 그들이 만든 소프트웨어를 실행하세요. 그리고 프로그램에 오류가 발생할 때 까지(잘못될 때 까지) 시연하세요. 컴퓨터를 키는 것 부터 프로그램을 실행시키는 것, 그리고 당신이 소프트웨어와 어떻게 상호작용하는지, 당신이 프로그램에 특정 행동을 취할 때 프로그램이 어떤 반응을 보이는지를 프로그래머가 직접 보게 하세요.

• 프로그래머들은 소프트웨어를 훤히 잘 알고 있습니다. 어느 부분이 완벽한지, 어느 부분이 취약한지 알고 있으며 문제가 생겼을 때 어느 부분을 봐야하는지 직관적으로 알고 있습니다. 소프트웨어가 잘못 수행할 때까지, 주어진 단서들을 통해 무언가가 미묘하게 이상하다는 것을 이미 인지하고 있었을것입니다. 그들은 테스트가 실행되는 동안 컴퓨터가 하는 모든 작업들을 관찰 할 수 있고, 중요한 동작들을 짐작할 수있습니다.

• 관찰을 통해 짐작을 할수 있다고 해도, 그 정보들로는 충분하지 않을지도 모릅니다. 프로그래머들은 좀 더 정보가 필요하다고 생각할지도 모르고, 당신에게 같은 동작을 반복해서 보여달라고 요청 할 지도 모릅니다. 그들이 원하는 만큼 버그 발생을 재현하기 위해 과정을 말해달라고 할 수도 있습니다. 프로그래머들은 특정 상황에서만 문제가 발생하는지, 아니면 여러 유사한 상황에서 발생하는지 알아보기 위해 버그 발생 과정을 여러번 다양하게 시도 할 것입니다. 만약 운이 나쁘면 몇시간동안 앉은상태로 조사하게 될 지도 모릅니다. 하지만 가장 중요한 것은 버그가 발생할때 컴퓨터를 바라보는 프로그래머에게 달려있습니다. 일단 에러가 발생하는 걸 찾아 내기만 한다면 그 다음부턴 처리 할 수 있고,문제를 고치기 위한 작업을 시작합니다.

• "어떻게 보여주면 좋은지 가르쳐주세요"

• 지금은 인터넷의 시대이며, 글로벌 커뮤니케이션의 시대입니다. 오늘날 버튼 하나로 자신의 소프트웨어를 러시아 사람에게 보내고, 받은 쪽에서는 소프트웨어에 대한 의견을 나에게 아주 쉽게 보낼 수 있습니다. 따라서 만약 내 프로그램에 문제가 있다해도, 내 눈앞에서 프로그램이 실패하는 것을 보여 줄 수 없습니다. "보여줄 수"만 있다면 좋은 방법이지만, 보여줄 수없는 경우가 더 많습니다.

• 직접 만날 수 없는 프로그래머에게 버그를 리포트 해야한다면, 이 활동의 목적은 그들에게 문제를 재현하게 하는 것이라는 걸 잊지 말아야 합니다. 당신은 프로그래머들이 그들이 갖고있는 동일한 프로그램을 가지고 당신과 같은 일을 하고 같은 방식으로 실패를 만들기를 원합니다. 그들의 눈으로 직접 문제가 발생하는 장면을 볼 수 있어야 그 문제에 대처할 수있습니다.

• 따라서 당신이 한 것들을 조금도 틀림없이 말해주세요. 만약 그래픽 프로그램이라면 어느버튼을 눌렀는지 그리고 어떤 순서로 눌렀는지를 말해주세요. 만약 명령어를 입력해서 프로그램을 실행한 거라면 당신이 입력한 명령어를 정확하게 보여주세요. 가능한한 입력한 그대로의 기록을 제공해야 하고, 어떤 명령어를 쳤으며 컴퓨터가 어떤 응답을 하였는지 그 출력되는 세션의 정확한 복제본을 제공해야 합니다.

• 프로그래머에게 당신이 생각할수 있는 모든 입력을 주세요. 만약 프로그램이 파일을 읽는다면 아마 그 파일의 사본을 보낼 필요가 있습니다. 만약 프로그램이 네트워크를 통해 다른 컴퓨터와 통신을 한다면, 당신은 컴퓨터의 복사본을 보낼수는 없을 것입니다. 그러나 당신은 적어도 무슨종류의 컴퓨터인지는 말할 수 있습니다. (가능하다면) 그 컴퓨터에서 어떤 소프트웨어를 실행했는지를 말해주세요.

• "나는 작동하는데, 뭐가 문제야?"

• 당신이 프로그래머에게 입력한 내용(버튼클릭, 명령어)과 액션의 긴 목록을 주고, 프로그래머가 그 리스트에 따라 프로그램을 실행했는데도 아무것도 잘못되지 않는다면, 당신은 충분한 정보를 준것이 아닙니다. 모든 컴퓨터에서 잘못된 동작이 나타나는게 아니라면, 아마 당신의 시스템과 그들의 시스템이 어느 하나라도 다를지도 모릅니다. 어쩌면 당신은 프로그램이 동작하는 바를 잘못 이해해서 프로그래머와 같은 화면을 보고도 그것이 잘못되었다고 생각하고있고, 프로그래머들은 그것이 맞다고 여기고 있는 상황 인지도 모릅니다.

• 그래서 무슨일이 일었는지에 대해 이야기하세요. 당신이 본 것을 정확하게 말하세요. 왜 당신이 본것이 잘못되었다고 생각하는지 말해주세요. 더 좋은 건, 그들에게 당신이 볼 수 있을 거라고 기대했던 모습(어떻게 해야한다고 생각하는지)을 말해주세요. 만약 당신이 "~이랬더니 잘못되었어요" 라고 말하는것만으로는 매우 중요한 정보를 빠뜨린 것 입니다.

• 만약 에러메시지를 본다면, 무엇이던간에 신중하고 정확하게 프로그래머에게 말하세요. 오류메시지는 중요합니다! 이 단계에서는, 프로그래머는 문제를 고치려 하지 않습니다. 단지 찾으려고 할 뿐이죠. 그들은 무엇이 잘못되었는지를 알아야 하고, 에러메시지들은 컴퓨터가 당신에게 전하려는 최선의 노력인것입니다. 만약 오류메시지를 기억할 다른 좋은 방법이 없다면 적으세요. 그러나 어떤 오류메시지 였는지 보고할 수 없다면, 프로그램이 오류를 일으켰다는 것을 전하는건 아무 의미없습니다.

• 특히 에러메시지에 숫자가 포함되어 있다면 반드시 프로그래머에게 그 번호를 알려주세요. 그 숫자들의 의미를 알수 없다고 그것들이 아무 의미가 없는게 아니기 때문입니다. 숫자들은 프로그래머들이 읽을 수 있는 모든 정보들을 포함하고 있고, 주요 단서들 포함할 가능성이 있습니다. 에러메시지에 있는 숫자는 에러 내용을 글로 표현하기에 컴퓨터는 너무 복잡하기 때문에 존재하는 것이고, 컴퓨터는 최선을 다해 중요한 정보를 어떻게든 전달하고자 하는 것이다.

• 이 단계에서는 프로그래머는 솜씨좋게 탐정일을 하고 있습니다. 그들은 무슨일이 있었는지도 모르고, 컴퓨터 안에서 무슨일이 일어났는지 육안으로 볼수 있는것도 아닙니다. (they can't get close enough to watch it hapeeing for temselves) 그들은 사건 해결의 실마리를 찾고있습니다. 에러메시지, 이해할수없는 숫자 문자열, 심지어 설명할수 없는 지연들은 모두 범죄현장의 지문만큼이나 중요합니다. 그것들을 지키세요!
• 
  많이 의역하였습니다.

• 유닉스를 사용하고 있다면, 프로그램은 코어 덤프(프로그램이 비정상적으로 종료 또는 충돌 될때 프로그램에 기록되는 작업 메모리) 할지도 모릅니다. 코어덤프는 특히 좋은 단서의 원천 이므로 버리지 마세요. 반면, 대부분의 프로그래머들은 거대한 코어 파일을 아무 말 없이 이메일로 받는 것을 좋아하지 않습니다. 그러니 메일을 보내기 전에는 물어보십시오. 또한 코어파일에 프로그램의 전체 상태가 기록되어 있는지 주의하세요. 몇몇 "비밀"이(아마 프로그램이 개인적인 메시지들을 다뤘거나, 중요한 데이터를 처리한것과 연관된 ) 코어파일에 포함될 수있습니다.

• "그러니까.... 제가 시도해봤는데요"

• 오류나 버그 가 발생했을 때 저질러버리기 쉬운 일들이 많습니다. 그들 중 많은 것들이 문제를 악화시킵니다. 제 학교 친구는 실수로 Word 문서를 모두 삭제 했습니다. 그리고는 전문가에게 도움을 요청하기 전에 Word를 다시 설치하고 Defrag 를 시도했습니다. 이러한 작업은 파일 복원에 도움이되지 않았을 뿐만 아니라, 그 사이에 그녀의 디스크는 전세계의 어느 삭제취소 프로그램을 통해서도 일절 복구 할 수 없을 정도로 뒤죽박죽 이되어 버렸습니다. 만약 아무작업도 하지않고 그대로 있었으면 기회는 있었을지도 모릅니다.

• 이러한 유저는 모퉁이에 숨는 몽구스와 비슷 합니다. 아무것도 하지 않는 것보다는 뭔가 하는 편이 낫다고 생각하기 때문에 배수진을치고 맹목적으로 공격합니다. 물론 이것은 컴퓨터 일으키는 문제의 종류에 적합하지 않습니다.

• 몽구스보다는 영양이 되세요. 영양은 예상치 못한 상황이나 놀라운 일들에 직면하면 가만히 멈춥니다. 완전히 정지한 상태로 다른 동물의 주의를 끌지 않으려합니다. 멈춰있는 동안에 생각하고 최선의 방법을 파악합니다. (만약 영양이 기술 지원으로 이어지는 회선을 가지고 있었다면 이 시점에서 전화를 걸 것입니다) 그리고는, 일단 가장 안전한 행동을 결정한 후 실행합니다.

• 무언가 잘못되면 즉시 아무것도 하지 마세요. 어떤 버튼도 일체 누르지 마세요. 스크린을 보고 이상한 모든 것들을 찾아내고 기억하거나 적어두세요. 그리고 가능하다면 " OK "또는 " 취소" 중 어느것이라도 좀 더 안전해 보이는 쪽을 신중하게 누르세요. 조건 반사를 몸에 익히세요 - 컴퓨터가 예기치 못한 일을 시작하면, 멈추세요.

• 영향을받는 프로그램을 닫거나 컴퓨터를 재시작을 통해 어떻게든 문제에서 벗어나면, 다시 그 현상을 일으키려고 해 보는 것이 좋습니다. 프로그래머는 한 번 이상 재현 가능한 문제를 좋아합니다. 행복한 프로그래머는 보다 빨리, 보다 효과적으로 버그를 수정 합니다.

• "타키온 조정이 잘못 된거 같은데요"

• 좋지않은 버그 리포트를 하는것은 비 프로그래머 뿐만 아닙니다. 제가 본 가운데 최악의 버그 리포트중 몇몇은 프로그래머로부터 전해진 것입니다. 물론 그 중에는 좋은 프로그래머도 있습니다.

• 한번은 다른 프로그래머와 같이 일을 했었습니다. 그는 자신이 작성한 코드에서 버그를 발견하고 수정하였습니다. 그는 해결할 수없는 버그를 발견할 때마다 수시로 나에게 들러 도움을 요청 했습니다. 내가 "어디가 이상해?" 라고 물으면, 그는 대답 대신에 버그를 고치기 위해 무엇이 필요한지에 대한 자신의 현재 의견을 말했습니다.

• 현재 의견이 옳을 때는 순탄하게 잘 진행 되었습니다. 그가 이미 절반정도를 끝마쳤고, 함께 일을 완료할 수 있다는 것을 의미 했습니다. 그 방법은 효과적이고 도움이되었습니다.

• 하지만 그는 매우 자주 틀렸습니다. 우리는 왜 프로그램의 특정부분이 잘못된 데이터를 만들고 있는지를 알아내려고 시간을 보냈고, 결국 그 코드는 잘못되지 않았다는 것을 알게되었습니다. 진짜 문제는 다른 부분에 있는데, 30분 동안을 완벽하게 잘 짜여진 코드를 공부하고 있던 것이었습니다.

• 분명 그는 의사에게 이렇게 할 것입니다. "선생님, 하이드로요요다인의 처방전을 내주세요 "라고 말이죠. 사람들은 의사에게 그렇게 말할 필요 없다는 것을 알고 있습니다. 단지 불편함이나 따끔거림, 통증, 발진, 발열과 같은 증상 을 호소하고, 무슨 문제가 있는지, 그 문제를 아떻게 해야할지 의사에게 진단 해달라고 합니다. 그렇지않다면 의사는 당신을 건강 염려증환자 또는 엉뚱한 사람이라고 쫓아 낼 것 입니다 , 뭐 실제로 그렇겠지만요

• 이것은 프로그래머에 대해서도 마찬가지입니다. 자가진단도 가끔은 유용하지만, 그래도 언제나 증상을 말하도록 하세요. 진단은 부가적인 여분일 뿐 , 증상을 전하는 대신 사용해서는 안됩니다. 마찬가지로 문제 해결을 위해 버그 보고에 코드를 첨부하여 보내는 것은 유용하지만, 버그리포트 대용으로는 충분하지 않습니다.

• 프로그래머가 당신에게 추가정보를 요청해오면, 그것을 날조하지 마세요! 한번은 저에게 버그를 제보한 사람이 있었는데, 그에게 명령어(입력하면 제대로된 동작이 일어나지 않을 것임을 알고있는 명령어)를 사용해 줄것을 요청하였습니다. 내가 그렇게 한 이유는 그명령어에 따른 어떤종류의 서로 상이한 에러메시지 두개가 나오는지 알고 싶었기 때문입니다. 어떤 오류가 돌아올 것인지를 아는 것은 매우 중요한 단서가 됩니다. 하지만 그는 실제로 시도하지 않고 "아니요, 움직이지 않을거에요" 라는 대답만이 메일로 돌아왔습니다. 실제로 시도하도록 그를 설득하는데에는 시간이 꽤 껄렸습니다.

• 프로그래머에게 도움이 되고자 당신의 능력을 사용하는건 훌륭한 자세입니다. 비록 당신의 추론이 틀렸다고 해도, 프로그래머는 당신의 수고에 대해서 감사할 것입니다. 그러나 증상뿐인 보고라면 수고를 늘려버릴지도 모릅니다.

• "어라 웃기네요, 조금전까지는 움직였는데"

• 프로그래머에게 "간헐적인 오류"라고 말하면 얼굴을 떨구는 것을 볼 수있습니다. 그나마 해결하기에 수월한 문제는 단순히 일련의 작업을 수행하는것이 오류를 발생시키는 경우입니다. 그럴때 프로그래머는 밀접하게 관찰된 테스트 조건을 반복하여 세세하게 무슨일이 일어나는지 볼 수 있습니다. 너무 많은 문제들이 그런식으로 동작하지 않습니다. 일주일에 한번 실패하거나 드물게 실패하거나 또는 프로그래머 앞에서는 시연할때 절대 실패하지 않지만 마감일이 가까워지면 항상 실패하는 프로그램이 존재할 것입니다.

• 대부분의 간헐적인 오류들은 진짜로 간헐적이지 않습니다. 대부분은 어딘가에 논리가 있습니다. 대부분은 컴퓨터의 메모리가 부족할 때 일어나는 것이고, 몇몇은 다른프로그램이 중요한 파일을 잘못된 시간에 변경하려고 할때 일어나는 것이고, 몇몇은 매 시간 30분정도만 일어나는 것일 수도 있습니다.

• 또한 당신은 버그를 재현 할 수 있는데, 프로그래머는 재현 할 수 없다면 분명히 그들의 컴퓨터 및 당신의 컴퓨터 어딘가에 차이가 있는것이고, 이 차이가 문제의 원인 것입니다. 한번은 창이 화면 왼쪽 상단 모서리의 작은 공처럼 웅크려지고 무응답 되는 프로그램이 있었습니다. 그러나 이 버그는 800 × 600 의 화면 에서만 일어나고, 1024 × 768 의 모니터 에서는 아무 문제 없었습니다.

• 프로그래머는 문제에대해 당신이 알고 있는 것을 무엇이든지 알고싶어 할 것입니다. 할 수 있다면 다른 컴퓨터에서 시험해보세요. 두 번 또는 세 번 시도하고 얼마나 프로그램이 실패하는지를 보세요. 중요한 일을 하고 있을 사용하는 경우에는 이상이 생기는데, 문제를 현장 에서 보여 주려고 할 때 아무 이상이 없을 경우 오랫동안 실행 시키거나 큰 파일을 처리 하면 재현 할 수도 있을지도 모른다. 프로그램이 실패했을 때 무엇을하고 있었는지 가능한 한 상세하게 기억하도록 하세요. 또한 어떠한 패턴을 발견하게 된다면 언급해주세요. 당신이 제공할수 있는 것은 도움이 되어야 합니다. 단지 확률적인 것이라도 (예: " Emacs 가 실행하고 있을 때 더 충돌하는 경향이 있는 것 같다" ) 직접적인 단서가 되지는 않지만, 프로그래머가 그 문제를 재현하는 데 유용 할 수 있습니다 .

• 가장 중요한 것은 프로그래머가 다루고 있는 것이 진정으로 간헐적인인 결함인지 특정 컴퓨터에서 일어나는 결함 인지 확인 하고 싶어하는 것입니다. 그들의 컴퓨터와 당신의 컴퓨터가 얼마나 다른지를 알아내기 위해, 그들은 당신의 컴퓨터 정보를 많이 알고 싶어할 것입니다. 이러한 정보의 대부분은 특정 프로그램 에 의존하지만, 당신이 반드시 제공해야 하는 것 하나는 버전 정보 입니다. 프로그램 자체의 버전 번호 및 운영 체제 버전 번호, 문제에 관련한 다른 모든 프로그램의 버전 번호도 있습니다.

• "그래서 Window 디스크를 로드했습니다...."

• 명확하게 쓰는 것은 버그 리포트의 본질입니다. 당신의 의도 하는 바를 프로그래머가 알 수 없다면, 아무것도 말하지 않은 것과 같습니다.

• 저는 전세계에서 버그 리포트를 받습니다. 그들의 대부분은 영어가 모국어가 아닌 사람들이고, 서투른 영어를 구사합니다. 일반적으로, 영어가 서툴어서 미안하다는 사과가 동반된 버그리포팅은 매우 명확하고 유용합니다. 오히려 불분명한 버그 리포트의 대부분은 영어가 모국어인 사람들로 부터 온 것이며, 그들은 딱히 간결하고 정확하게 표현하기 위한 노력을 하지 않아도 내가 잘 이해 할 것이라 생각합니다.

• 구체적으로 이야기하세요. 같은 일을 다른 두 방법으로 할 수 있다면, 어떤 방법을 사용 했는지 이야기하세요. "Load를 선택했습니다(selected) "는 " "Load를 클릭 했습니다 "또는 "Alt - L 을 눌렀습니다 " 두가지를 의미합니다. 어느 방법을 사용했는지 말하십시오. 종종 그것이 문제가 됩니다.

• 풀어서 이야기하세요. 가능한 한 많은 정보를 주세요. 너무 많은 정보를 준다해도, 프로그래머는 알아서 받아 들입니다. 너무 적게 말하면 그들은 회신하여 더 많은 질문을 해야 합니다. 제가받은 버그 리포트 중에는 문장 하나로만 구성되어 있는 것도 있었습니다. 매번 더 많은 정보를 부탁했고, 그들은 매번 다른 문장을 회신하곤 했습니다. 한 번에 하나의 짧은 문장이 밝혀질 뿐이므로, 충분한 양의 유용한 정보를 얻을 때까지는 몇 주가 걸렸습니다 .

• 대명사에 주의하세요 . "it" 와 같은 단어나 "the window"와 같은 참조는 의미가 불분명 할 때에는 사용하지 마세요. " FooApp 를 시작한 후 경고 창이 나왔습니다. 그것을 닫으려고 하면 충돌 했습니다 " 라는 글을 생각해보세요. 이 것만으로는 이용자가 무엇을 닫으려고 했는지 알수 없습니다. 경고창을 닫으려 했을까요, FooApp 전체를 닫으려 했을까요? 이것은 중요하다. 이와 같은 방법 대신 " FooApp 를 시작한 후 경고 창이 나왔습니다. 경고 창을 닫으려고 하면 FooApp 가 종료되었다 "고 말할 수 있습니다. 두번 째 문장이 길고 반복이 많지만, 더 명확하고 오해의 여지가 적습니다.

• 당신이 쓴 내용을 읽어보세요. 스스로 리포트를 검토하여, 명확하다고 생각 되는지 확인 하세요. 실패를 만들어야 하는 (버그를 재현하기 위한 과정) 하는 일련의 작업이 있다면 단계를 건너 뛰지 않았는지 직접 따라하면서 검토해보세요.

• 요약

• 버그 리포트의 첫 번째 목적은 프로그래머에게 그들 자신의 눈으로 실패 를 확인하게 하는 것 입니다. 그들에게로 가서 직접 프로그램을 실패할 수 없는 경우, 프로그래머들이 스스로 프로그램을 실패 시킬 수 있도록 자세한 지침을 주세요.

• 첫 번째 목적이 잘 되지 않아서 프로그래머가 직접 실패를 확인할 수 없었던 경우, 두 번째 목적은 무엇이 잘못 되었는가를 설명 하는 것입니다. 모든것을 자세히 설명 하세요. 무엇을 보았는지, 당신이 기대하고 있던 결과는 무엇인지 밝히세요. 오류 메시지를 적으세요, 특히 숫자가 포함되어 있는 것은 꼭!

• 컴퓨터가 예기치 않은 동작을 하면 가만히 있으세요. 당신이 진정 될 때까지 아무것도 하지마세요. 위험하다고 생각 되는 일은 하지 말아야 합니다.

• 물론, 당신이 할 수 있다고 생각하는 경우 오류를 직접 진단하려고 노력하세요. 하지만, 당신이 진단한다고 해도 여전히 증상을 보고 해야합니다.

• 프로그래머가 필요로 한다면, 추가 정보를 제공 하세요. 만약에 필요 없었다면 요청하지 않았을 것입니다. 일부러 서투른 행동을 하는게 아닙니다. 필요로 할지도 모르니, 버전 번호를 쉽게 제공 할 수 있도록 항상 준비해두세요.(미리 알아두세요)

• 명쾌하게 쓰세요. 당신이 의미 하는 바를 말하고, 잘못 해석 되지 않도록 조심하세요 .

• 무엇 보다도 정확해야합니다. 프로그래머는 정확함을 좋아합니다.

• ---------------------------------------------------------------------------------------------------------------------------------------------

• 부인성명서 : 사실 나는 몽구스 와 영양 을 본 적이 없습니다. 내 동물학 지식은 부정확 할지도 모릅니다.

• ID

• Copyright © 1999 Simon Tatham.

• 이 문서는 공개 문서입니다.

• You may copy and use the text under the terms of the OpenContent Licence.

• ----------------------------------------------------------------------------------------------------------------------------------------

• 이 문서는 특정 프로그램을 위해 작성된 것은 아닙니다

• 특정 프로그램의 웹 사이트에서 링크를 따라 이 페이지에 방문했다면 그 프로그램의 버그 리포트를 내게 보내지 마십시오. 대신에 원래 있었다 페이지로 돌아가 그 프로그램의 버그를 어디에보고하면 좋을지 살펴 보세요

• 이 문서 자체에 만약 의견과 비판이 있으면 anakin@pobox.com 보내주십시오.