• How to Report Bugs Effectively

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

  • by Simon Tatham, professional and free-software programmer
  • by Simon Tatham, 전문 프로그래머이자 자유소프트웨어 프로그래머
  • Introduction
  • 서론
  • Anybody who has written software for public use will probably have received at least one bad bug report. Reports that say nothing ("It doesn't work!"); reports that make no sense; reports that don't give enough information; reports that give wrong information. Reports of problems that turn out to be user error; reports of problems that turn out to be the fault of somebody else's program; reports of problems that turn out to be network failures.
  • 공개 소프트웨어를 작성해본 사람이라면 적어도 한번쯤은 나쁜 버그 리포트를 받은 적이 있을 것입니다. "이거 안되요."와 같은 아무 의미 없는 리포트이거나 충분한 정보를 주지않거나 잘못된 정보를 주는 리포트 같은 경우 말이죠. 그러한 문제들은 사용자의 실수, 다른 프로그램의 잘못이나 네트워크 오류로 밝혀 집니다.
  • There's a reason why technical support is seen as a horrible job to be in, and that reason is bad bug reports. However, not all bug reports are unpleasant: I maintain free software, when I'm not earning my living, and sometimes I receive wonderfully clear, helpful, informative bug reports.
  • 기술 지원에 관련된 업무가 끔찍하게 보이는 이유가 있습니다. 바로 나쁜 버그 리포트 때문이죠. 그렇다고 해서 모든 버그리포트가 불친절한 것은 아닙니다. 생계를 위해 하고 있는 일은 아니지만 저는 무료소프트웨어를 관리합니다. 그리고 때때로 명쾌하고 도움이 되며 유익한 버그 리포트를 받곤 합니다.
  • In this essay I'll try to state clearly what makes a good bug report. Ideally I would like everybody in the world to read this essay before reporting any bugs to anybody. Certainly I would like everybody who reports bugs to me to have read it.
  • 저는 이 글을 통해 어떠한 요소가 좋은 버그 리포트를 만드는지 설명하려고 합니다. 가능하면 전 세계의 버그리포팅을 하려는 사람들은 버그 리포팅을 하기 전에 이 글을 읽었으면 좋겠습니다. 특히 나에게 버그리포트를 하려는 사람들은 이 글을 읽었으면 좋겠습니다.
  • In a nutshell, the aim of a bug report is to enable the programmer to see the program failing in front of them. You can either show them in person, or give them careful and detailed instructions on how to make it fail. If they can make it fail, they will try to gather extra information until they know the cause. If they can't make it fail, they will have to ask you to gather that information for them.
  • 간단히 말해서, 버그리포트의 목적은 프로그래머가 프로그램의 잘못 된 점을 알게 하는 것입니다. 당신은 어떻게 하면 오류가 발생하는지 직접(실제로) 보여주거나 오류를 재현하는 방법을 자세하게 알려 줄 수있습니다. 만약 프로그래머들이 오류를 재현할 수 있으면, 그들은 오류를 만드는 원인을 알게 될 때 까지 정보를 모을 것 입니다. 만약 그들이 오류를 재현하지 못한다면, 그들은 더 많은 정보를 얻기 위해 당신에게 물어봐야 할 것입니다.
  • In bug reports, try to make very clear what are actual facts ("I was at the computer and this happened") and what are speculations ("I think the problem might be this"). Leave out speculations if you want to, but don't leave out facts.
  • 버그리포트에서 , 명확한 사실("나는 이렇게 했고, 이런일이 벌어졌어요")과 추측(내생각에 이것때문이야!) 을 명확히 구분하려고 노력하세요. 사실은 놓치지 말고, 만약 원한다면 추측은 생략하세요.
  • When you report a bug, you are doing so because you want the bug fixed. There is no point in swearing at the programmer or being deliberately unhelpful: it may be their fault and your problem, and you might be right to be angry with them, but the bug will get fixed faster if you help them by supplying all the information they need. Remember also that if the program is free, then the author is providing it out of kindness, so if too many people are rude to them then they may stop feeling kind.
  • 당신이 버그를 보고할 때(버그를 보고한다는 것은), 버그가 고쳐지길 원하기 때문에 그렇게 하는 것입니다. 프로그래머에게 욕을 하거나 의도적으로 불편하게 하는 것은(being deliberately unhelpful) 아무 소용이 없습니다. 그건 아마도 프로그래머의 실수 이거나 당신의 잘못일 것입니다. 물론 당신은 그들에게 화낼 권리는 있지만 ,그것보다는 프로그래머가 원하는 모든 정보를 제공하여 돕는 편이 버그가 좀 더 빠르게 고쳐질 것입니다. 또한 소프트웨어가 무료라는 것은 저자(프로그래머)가 친절한 마음에서 베풀고 있는 것라는것을 명심하길 바랍니다!
    너무 많은 사람들이 개발자한테 무례하게 군다면 그들은 소프트웨어를 무료로 배포하는 친절을 그만 둘 수도 있습니다.
  • "It doesn't work."
  • "이거 안되요."
  • Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less.
  • 프로그래머에게 당신의 기초 정보를 공유하세요. 만약 프로그램이 전혀 작동하지 않았다면 프로그래머들은 알고 있을 것입니다. 프로그램이 전혀 동작하지 않는 다는걸 알아차리지 못했기 때문에, 당신의 기초 정보를 제공하는 것은 반드시 효과적일 것입니다. 그들과 조금 다르게 프로그램을 사용 하거나, 프로그램을 사용하는 환경이 다를 것입니다. 프로그래머들은 정보가 필요하고 이러한 정보를 제공하는 것이 버그리포팅의 목적입니다. 언제나 정보는 많으면 많을수록 좋은법입니다.
  • Many programs, particularly free ones, publish their list of known bugs. If you can find a list of known bugs, it's worth reading it to see if the bug you've just found is already known or not. If it's already known, it probably isn't worth reporting again, but if you think you have more information than the report in the bug list, you might want to contact the programmer anyway. They might be able to fix the bug more easily if you can give them information they didn't already have.
  • 많은 프로그램들, 특히 무료 소프트웨어는 알려진 버그들의 리스트를 발행합니다. 알려진 버그 리스트를 찾는다면 자신이 발견한 버그가 이미 그 리스트에 있는지 확인하기 위해 읽어 볼만한 가치가 있습니다. 만약 이미 그 리스트에 등록되어 있는 버그라면 중복으로 리포팅 할 필요는 없습니다. 하지만 생각하기에 해당 버그와 관련한 보고되지 않은 추가 정보가 있다고 생각된다면, 당신은 어쨌든 프로그래머에게 연락하길 원할지도 모릅니다. 만약 당신이 그들이 진작에 갖고있지 않은 정보를 제공한다면 그들은 버그를 더 쉽게 고칠수 있을 지도 모릅니다.
  • This essay is full of guidelines. None of them is an absolute rule. Particular programmers have particular ways they like bugs to be reported. If the program comes with its own set of bug-reporting guidelines, read them. If the guidelines that come with the program contradict the guidelines in this essay, follow the ones that come with the program!
  • 이 에세이에서 버그리포팅에 대한 가이드라인을 설명하고 있지만, 절대적인 규칙은 아닙니다. 몇몇의 프로그래머들은 그들만의 버그리포팅 방법을 가지고 있습니다. 만약 프로그램이 버그리포팅 가이드라인을 함께 제공한다면 그 가이드라인을 읽으세요. 프로그램에서 제공하는 버그리포트 가이드가 이 에세이와 다르다면 프로그램과 함께 온 가이드라인을 우선적으로 따르십시오.
  • If you are not reporting a bug but just asking for help using the program, you should state where you have already looked for the answer to your question. ("I looked in chapter 4 and section 5.2 but couldn't find anything that told me if this is possible.") This will let the programmer know where people will expect to find the answer, so they can make the documentation easier to use.
  • 버그 리포팅을 하지 않더라도 프로그램에 대해 물어 볼 수 있으며 이때 당신은 어느 부분에서 이 질문에 대한 답을 찾아봤는지 언급해야 합니다. ("제가 챕터4 색션 5.2을 살펴봤는데 제가 찾고있는 기능에 대해 나와있지 않아요") 와 같이 적어주는 것은 프로그래머가 사람들이 프로그램을 사용하다가 모르는것이 있을때 주로 문서의 어느 부분을 보는지를 알게 할 것이고, 이러한 행동들은 문서를 좀더 편리하고 유용하게 만들 수 있습니다.
  • "Show me."
  • "보여주세요!"
  • One of the very best ways you can report a bug is by showing it to the programmer. Stand them in front of your computer, fire up their software, and demonstrate the thing that goes wrong. Let them watch you start the machine, watch you run the software, watch how you interact with the software, and watch what the software does in response to your inputs.
  • 버그리포팅을 하는 좋은 방법 중 한가지는 프로그래머에게 직접 보여주는 것입니다. 프로그래머를 당신의 컴퓨터 앞으로 데려온 다음, 그들이 만든 소프트웨어를 실행하세요. 그리고 프로그램에 오류가 발생할 때 까지(잘못될 때 까지) 시연하세요. 컴퓨터를 키는 것 부터 프로그램을 실행시키는 것, 그리고 당신이 소프트웨어와 어떻게 상호작용하는지, 당신이 프로그램에 특정 행동을 취할 때 프로그램이 어떤 반응을 보이는지를 프로그래머가 직접 보게 하세요.
  • They know that software like the back of their hand. They know which parts they trust, and they know which parts are likely to have faults. They know intuitively what to watch for. By the time the software does something obviously wrong, they may well have already noticed something subtly wrong earlier which might give them a clue. They can observe everything the computer does during the test run, and they can pick out the important bits for themselves.
  • 프로그래머들은 소프트웨어를 훤히 잘 알고 있습니다. 어느 부분이 완벽한지, 어느 부분이 취약한지 알고 있으며 문제가 생겼을 때 어느 부분을 봐야하는지 직관적으로 알고 있습니다. 소프트웨어가 잘못 수행할 때까지, 주어진 단서들을 통해 무언가가 미묘하게 이상하다는 것을 이미 인지하고 있었을것입니다. 그들은 테스트가 실행되는 동안 컴퓨터가 하는 모든 작업들을 관찰 할 수 있고, 중요한 동작들을 짐작할 수있습니다.
  • This may not be enough. They may decide they need more information, and ask you to show them the same thing again. They may ask you to talk them through the procedure, so that they can reproduce the bug for themselves as many times as they want. They might try varying the procedure a few times, to see whether the problem occurs in only one case or in a family of related cases. If you're unlucky, they may need to sit down for a couple of hours with a set of development tools and really start investigating. But the most important thing is to have the programmer looking at the computer when it goes wrong. Once they can see the problem happening, they can usually take it from there and start trying to fix it.
  • 관찰을 통해 짐작을 할수 있다고 해도, 그 정보들로는 충분하지 않을지도 모릅니다. 프로그래머들은 좀 더 정보가 필요하다고 생각할지도 모르고, 당신에게 같은 동작을 반복해서 보여달라고 요청 할 지도 모릅니다. 그들이 원하는 만큼 버그 발생을 재현하기 위해 과정을 말해달라고 할 수도 있습니다. 프로그래머들은 특정 상황에서만 문제가 발생하는지, 아니면 여러 유사한 상황에서 발생하는지 알아보기 위해 버그 발생 과정을 여러번 다양하게 시도 할 것입니다. 만약 운이 나쁘면 몇시간동안 앉은상태로 조사하게 될 지도 모릅니다. 하지만 가장 중요한 것은 버그가 발생할때 컴퓨터를 바라보는 프로그래머에게 달려있습니다. 일단 에러가 발생하는 걸 찾아 내기만 한다면 그 다음부턴 처리 할 수 있고,문제를 고치기 위한 작업을 시작합니다.
  • "Show me how to show myself."
  • "어떻게 보여주면 좋은지 가르쳐주세요"
  • This is the era of the Internet. This is the era of worldwide communication. This is the era in which I can send my software to somebody in Russia at the touch of a button, and he can send me comments about it just as easily. But if he has a problem with my program, he can't have me standing in front of it while it fails. "Show me" is good when you can, but often you can't.
  • 지금은 인터넷의 시대이며, 글로벌 커뮤니케이션의 시대입니다. 오늘날 버튼 하나로 자신의 소프트웨어를 러시아 사람에게 보내고, 받은 쪽에서는 소프트웨어에 대한 의견을 나에게 아주 쉽게 보낼 수 있습니다. 따라서 만약 내 프로그램에 문제가 있다해도, 내 눈앞에서 프로그램이 실패하는 것을 보여 줄 수 없습니다. "보여줄 수"만 있다면 좋은 방법이지만, 보여줄 수없는 경우가 더 많습니다.
  • If you have to report a bug to a programmer who can't be present in person, the aim of the exercise is to enable them to reproduce the problem. You want the programmer to run their own copy of the program, do the same things to it, and make it fail in the same way. When they can see the problem happening in front of their eyes, then they can deal with it.
  • 직접 만날 수 없는 프로그래머에게 버그를 리포트 해야한다면, 이 활동의 목적은 그들에게 문제를 재현하게 하는 것이라는 걸 잊지 말아야 합니다. 당신은 프로그래머들이 그들이 갖고있는 동일한 프로그램을 가지고 당신과 같은 일을 하고 같은 방식으로 실패를 만들기를 원합니다. 그들의 눈으로 직접 문제가 발생하는 장면을 볼 수 있어야 그 문제에 대처할 수있습니다.
  • So tell them exactly what you did. If it's a graphical program, tell them which buttons you pressed and what order you pressed them in. If it's a program you run by typing a command, show them precisely what command you typed. Wherever possible, you should provide a verbatim transcript of the session, showing what commands you typed and what the computer output in response.
  • 따라서 당신이 한 것들을 조금도 틀림없이 말해주세요. 만약 그래픽 프로그램이라면 어느버튼을 눌렀는지 그리고 어떤 순서로 눌렀는지를 말해주세요. 만약 명령어를 입력해서 프로그램을 실행한 거라면 당신이 입력한 명령어를 정확하게 보여주세요. 가능한한 입력한 그대로의 기록을 제공해야 하고, 어떤 명령어를 쳤으며 컴퓨터가 어떤 응답을 하였는지 그 출력되는 세션의 정확한 복제본을 제공해야 합니다.
  • Give the programmer all the input you can think of. If the program reads from a file, you will probably need to send a copy of the file. If the program talks to another computer over a network, you probably can't send a copy of that computer, but you can at least say what kind of computer it is, and (if you can) what software is running on it.
  • 프로그래머에게 당신이 생각할수 있는 모든 입력을 주세요. 만약 프로그램이 파일을 읽는다면 아마 그 파일의 사본을 보낼 필요가 있습니다. 만약 프로그램이 네트워크를 통해 다른 컴퓨터와 통신을 한다면, 당신은 컴퓨터의 복사본을 보낼수는 없을 것입니다. 그러나 당신은 적어도 무슨종류의 컴퓨터인지는 말할 수 있습니다. (가능하다면) 그 컴퓨터에서 어떤 소프트웨어를 실행했는지를 말해주세요.
  • "Works for me. So what goes wrong?"
  • "나는 작동하는데, 뭐가 문제야?"
  • If you give the programmer a long list of inputs and actions, and they fire up their own copy of the program and nothing goes wrong, then you haven't given them enough information. Possibly the fault doesn't show up on every computer; your system and theirs may differ in some way. Possibly you have misunderstood what the program is supposed to do, and you are both looking at exactly the same display but you think it's wrong and they know it's right.
  • 당신이 프로그래머에게 입력한 내용(버튼클릭, 명령어)과 액션의 긴 목록을 주고, 프로그래머가 그 리스트에 따라 프로그램을 실행했는데도 아무것도 잘못되지 않는다면, 당신은 충분한 정보를 준것이 아닙니다. 모든 컴퓨터에서 잘못된 동작이 나타나는게 아니라면, 아마 당신의 시스템과 그들의 시스템이 어느 하나라도 다를지도 모릅니다. 어쩌면 당신은 프로그램이 동작하는 바를 잘못 이해해서 프로그래머와 같은 화면을 보고도 그것이 잘못되었다고 생각하고있고, 프로그래머들은 그것이 맞다고 여기고 있는 상황 인지도 모릅니다.
  • So also describe what happened. Tell them exactly what you saw. Tell them why you think what you saw is wrong; better still, tell them exactly what you expected to see. If you say "and then it went wrong", you have left out some very important information.
  • 그래서 무슨일이 일었는지에 대해 이야기하세요. 당신이 본 것을 정확하게 말하세요. 왜 당신이 본것이 잘못되었다고 생각하는지 말해주세요. 더 좋은 건, 그들에게 당신이 볼 수 있을 거라고 기대했던 모습(어떻게 해야한다고 생각하는지)을 말해주세요. 만약 당신이 "~이랬더니 잘못되었어요" 라고 말하는것만으로는 매우 중요한 정보를 빠뜨린 것 입니다.
  • If you saw error messages then tell the programmer, carefully and precisely, what they were. They are important! At this stage, the programmer is not trying to fix the problem: they're just trying to find it. They need to know what has gone wrong, and those error messages are the computer's best effort to tell you that. Write the errors down if you have no other easy way to remember them, but it's not worth reporting that the program generated an error unless you can also report what the error message was.
  • 만약 에러메시지를 본다면, 무엇이던간에 신중하고 정확하게 프로그래머에게 말하세요. 오류메시지는 중요합니다! 이 단계에서는, 프로그래머는 문제를 고치려 하지 않습니다. 단지 찾으려고 할 뿐이죠. 그들은 무엇이 잘못되었는지를 알아야 하고, 에러메시지들은 컴퓨터가 당신에게 전하려는 최선의 노력인것입니다. 만약 오류메시지를 기억할 다른 좋은 방법이 없다면 적으세요. 그러나 어떤 오류메시지 였는지 보고할 수 없다면, 프로그램이 오류를 일으켰다는 것을 전하는건 아무 의미없습니다.
  • In particular, if the error message has numbers in it, do let the programmer have those numbers. Just because you can't see any meaning in them doesn't mean there isn't any. Numbers contain all kinds of information that can be read by programmers, and they are likely to contain vital clues. Numbers in error messages are there because the computer is too confused to report the error in words, but is doing the best it can to get the important information to you somehow.
  • 특히 에러메시지에 숫자가 포함되어 있다면 반드시 프로그래머에게 그 번호를 알려주세요. 그 숫자들의 의미를 알수 없다고 그것들이 아무 의미가 없는게 아니기 때문입니다. 숫자들은 프로그래머들이 읽을 수 있는 모든 정보들을 포함하고 있고, 주요 단서들 포함할 가능성이 있습니다. 에러메시지에 있는 숫자는 에러 내용을 글로 표현하기에 컴퓨터는 너무 복잡하기 때문에 존재하는 것이고, 컴퓨터는 최선을 다해 중요한 정보를 어떻게든 전달하고자 하는 것이다.
  • At this stage, the programmer is effectively doing detective work. They don't know what's happened, and they can't get close enough to watch it happening for themselves, so they are searching for clues that might give it away. Error messages, incomprehensible strings of numbers, and even unexplained delays are all just as important as fingerprints at the scene of a crime. Keep them!
  • 이 단계에서는 프로그래머는 솜씨좋게 탐정일을 하고 있습니다. 그들은 무슨일이 있었는지도 모르고, 컴퓨터 안에서 무슨일이 일어났는지 육안으로 볼수 있는것도 아닙니다. (they can't get close enough to watch it hapeeing for temselves) 그들은 사건 해결의 실마리를 찾고있습니다. 에러메시지, 이해할수없는 숫자 문자열, 심지어 설명할수 없는 지연들은 모두 범죄현장의 지문만큼이나 중요합니다. 그것들을 지키세요!
  • note icon
    많이 의역하였습니다.
  • If you are using Unix, the program may have produced a core dump. Core dumps are a particularly good source of clues, so don't throw them away. On the other hand, most programmers don't like to receive huge core files by e-mail without warning, so ask before mailing one to anybody. Also, be aware that the core file contains a record of the complete state of the program: any "secrets" involved (maybe the program was handling a personal message, or dealing with confidential data) may be contained in the core file.
  • 유닉스를 사용하고 있다면, 프로그램은 코어 덤프(프로그램이 비정상적으로 종료 또는 충돌 될때 프로그램에 기록되는 작업 메모리) 할지도 모릅니다. 코어덤프는 특히 좋은 단서의 원천 이므로 버리지 마세요. 반면, 대부분의 프로그래머들은 거대한 코어 파일을 아무 말 없이 이메일로 받는 것을 좋아하지 않습니다. 그러니 메일을 보내기 전에는 물어보십시오. 또한 코어파일에 프로그램의 전체 상태가 기록되어 있는지 주의하세요. 몇몇 "비밀"이(아마 프로그램이 개인적인 메시지들을 다뤘거나, 중요한 데이터를 처리한것과 연관된 ) 코어파일에 포함될 수있습니다.
  • "So then I tried . . ."
  • "그러니까.... 제가 시도해봤는데요"
  • There are a lot of things you might do when an error or bug comes up. Many of them make the problem worse. A friend of mine at school deleted all her Word documents by mistake, and before calling in any expert help, she tried reinstalling Word, and then she tried running Defrag. Neither of these helped recover her files, and between them they scrambled her disk to the extent that no Undelete program in the world would have been able to recover anything. If she'd only left it alone, she might have had a chance.
  • 오류나 버그 가 발생했을 때 저질러버리기 쉬운 일들이 많습니다. 그들 중 많은 것들이 문제를 악화시킵니다. 제 학교 친구는 실수로 Word 문서를 모두 삭제 했습니다. 그리고는 전문가에게 도움을 요청하기 전에 Word를 다시 설치하고 Defrag 를 시도했습니다. 이러한 작업은 파일 복원에 도움이되지 않았을 뿐만 아니라, 그 사이에 그녀의 디스크는 전세계의 어느 삭제취소 프로그램을 통해서도 일절 복구 할 수 없을 정도로 뒤죽박죽 이되어 버렸습니다. 만약 아무작업도 하지않고 그대로 있었으면 기회는 있었을지도 모릅니다.
  • Users like this are like a mongoose backed into a corner: with its back to the wall and seeing certain death staring it in the face, it attacks frantically, because doing something has to be better than doing nothing. This is not well adapted to the type of problems computers produce.
  • 이러한 유저는 모퉁이에 숨는 몽구스와 비슷 합니다. 아무것도 하지 않는 것보다는 뭔가 하는 편이 낫다고 생각하기 때문에 배수진을치고 맹목적으로 공격합니다. 물론 이것은 컴퓨터 일으키는 문제의 종류에 적합하지 않습니다.
  • Instead of being a mongoose, be an antelope. When an antelope is confronted with something unexpected or frightening, it freezes. It stays absolutely still and tries not to attract any attention, while it stops and thinks and works out the best thing to do. (If antelopes had a technical support line, it would be telephoning it at this point.) Then, once it has decided what the safest thing to do is, it does it.
  • 몽구스보다는 영양이 되세요. 영양은 예상치 못한 상황이나 놀라운 일들에 직면하면 가만히 멈춥니다. 완전히 정지한 상태로 다른 동물의 주의를 끌지 않으려합니다. 멈춰있는 동안에 생각하고 최선의 방법을 파악합니다. (만약 영양이 기술 지원으로 이어지는 회선을 가지고 있었다면 이 시점에서 전화를 걸 것입니다) 그리고는, 일단 가장 안전한 행동을 결정한 후 실행합니다.
  • When something goes wrong, immediately stop doing anything. Don't touch any buttons at all. Look at the screen and notice everything out of the ordinary, and remember it or write it down. Then perhaps start cautiously pressing "OK" or "Cancel", whichever seems safest. Try to develop a reflex reaction - if a computer does anything unexpected, freeze.
  • 무언가 잘못되면 즉시 아무것도 하지 마세요. 어떤 버튼도 일체 누르지 마세요. 스크린을 보고 이상한 모든 것들을 찾아내고 기억하거나 적어두세요. 그리고 가능하다면 " OK "또는 " 취소" 중 어느것이라도 좀 더 안전해 보이는 쪽을 신중하게 누르세요. 조건 반사를 몸에 익히세요 - 컴퓨터가 예기치 못한 일을 시작하면, 멈추세요.
  • If you manage to get out of the problem, whether by closing down the affected program or by rebooting the computer, a good thing to do is to try to make it happen again. Programmers like problems that they can reproduce more than once. Happy programmers fix bugs faster and more efficiently.
  • 영향을받는 프로그램을 닫거나 컴퓨터를 재시작을 통해 어떻게든 문제에서 벗어나면, 다시 그 현상을 일으키려고 해 보는 것이 좋습니다. 프로그래머는 한 번 이상 재현 가능한 문제를 좋아합니다. 행복한 프로그래머는 보다 빨리, 보다 효과적으로 버그를 수정 합니다.
  • "I think the tachyon modulation must be wrongly polarised."
  • "타키온 조정이 잘못 된거 같은데요"
  • It isn't only non-programmers who produce bad bug reports. Some of the worst bug reports I've ever seen come from programmers, and even from good programmers.
  • 좋지않은 버그 리포트를 하는것은 비 프로그래머 뿐만 아닙니다. 제가 본 가운데 최악의 버그 리포트중 몇몇은 프로그래머로부터 전해진 것입니다. 물론 그 중에는 좋은 프로그래머도 있습니다.
  • I worked with another programmer once, who kept finding bugs in his own code and trying to fix them. Every so often he'd hit a bug he couldn't solve, and he'd call me over to help. "What's gone wrong?" I'd ask. He would reply by telling me his current opinion of what needed to be fixed.
  • 한번은 다른 프로그래머와 같이 일을 했었습니다. 그는 자신이 작성한 코드에서 버그를 발견하고 수정하였습니다. 그는 해결할 수없는 버그를 발견할 때마다 수시로 나에게 들러 도움을 요청 했습니다. 내가 "어디가 이상해?" 라고 물으면, 그는 대답 대신에 버그를 고치기 위해 무엇이 필요한지에 대한 자신의 현재 의견을 말했습니다.
  • This worked fine when his current opinion was right. It meant he'd already done half the work and we were able to finish the job together. It was efficient and useful.
  • 현재 의견이 옳을 때는 순탄하게 잘 진행 되었습니다. 그가 이미 절반정도를 끝마쳤고, 함께 일을 완료할 수 있다는 것을 의미 했습니다. 그 방법은 효과적이고 도움이되었습니다.
  • But quite often he was wrong. We would work for some time trying to figure out why some particular part of the program was producing incorrect data, and eventually we would discover that it wasn't, that we'd been investigating a perfectly good piece of code for half an hour, and that the actual problem was somewhere else.
  • 하지만 그는 매우 자주 틀렸습니다. 우리는 왜 프로그램의 특정부분이 잘못된 데이터를 만들고 있는지를 알아내려고 시간을 보냈고, 결국 그 코드는 잘못되지 않았다는 것을 알게되었습니다. 진짜 문제는 다른 부분에 있는데, 30분 동안을 완벽하게 잘 짜여진 코드를 공부하고 있던 것이었습니다.
  • I'm sure he wouldn't do that to a doctor. "Doctor, I need a prescription for Hydroyoyodyne." People know not to say that to a doctor: you describe the symptoms, the actual discomforts and aches and pains and rashes and fevers, and you let the doctor do the diagnosis of what the problem is and what to do about it. Otherwise the doctor dismisses you as a hypochondriac or crackpot, and quite rightly so.
  • 분명 그는 의사에게 이렇게 할 것입니다. "선생님, 하이드로요요다인의 처방전을 내주세요 "라고 말이죠. 사람들은 의사에게 그렇게 말할 필요 없다는 것을 알고 있습니다. 단지 불편함이나 따끔거림, 통증, 발진, 발열과 같은 증상 을 호소하고, 무슨 문제가 있는지, 그 문제를 아떻게 해야할지 의사에게 진단 해달라고 합니다. 그렇지않다면 의사는 당신을 건강 염려증환자 또는 엉뚱한 사람이라고 쫓아 낼 것 입니다 , 뭐 실제로 그렇겠지만요
  • It's the same with programmers. Providing your own diagnosis might be helpful sometimes, but always state the symptoms. The diagnosis is an optional extra, and not an alternative to giving the symptoms. Equally, sending a modification to the code to fix the problem is a useful addition to a bug report but not an adequate substitute for one.
  • 이것은 프로그래머에 대해서도 마찬가지입니다. 자가진단도 가끔은 유용하지만, 그래도 언제나 증상을 말하도록 하세요. 진단은 부가적인 여분일 뿐 , 증상을 전하는 대신 사용해서는 안됩니다. 마찬가지로 문제 해결을 위해 버그 보고에 코드를 첨부하여 보내는 것은 유용하지만, 버그리포트 대용으로는 충분하지 않습니다.
  • If a programmer asks you for extra information, don't make it up! Somebody reported a bug to me once, and I asked him to try a command that I knew wouldn't work. The reason I asked him to try it was that I wanted to know which of two different error messages it would give. Knowing which error message came back would give a vital clue. But he didn't actually try it - he just mailed me back and said "No, that won't work". It took me some time to persuade him to try it for real.
  • 프로그래머가 당신에게 추가정보를 요청해오면, 그것을 날조하지 마세요! 한번은 저에게 버그를 제보한 사람이 있었는데, 그에게 명령어(입력하면 제대로된 동작이 일어나지 않을 것임을 알고있는 명령어)를 사용해 줄것을 요청하였습니다. 내가 그렇게 한 이유는 그명령어에 따른 어떤종류의 서로 상이한 에러메시지 두개가 나오는지 알고 싶었기 때문입니다. 어떤 오류가 돌아올 것인지를 아는 것은 매우 중요한 단서가 됩니다. 하지만 그는 실제로 시도하지 않고 "아니요, 움직이지 않을거에요" 라는 대답만이 메일로 돌아왔습니다. 실제로 시도하도록 그를 설득하는데에는 시간이 꽤 껄렸습니다.
  • Using your intelligence to help the programmer is fine. Even if your deductions are wrong, the programmer should be grateful that you at least tried to make their life easier. But report the symptoms as well, or you may well make their life much more difficult instead.
  • 프로그래머에게 도움이 되고자 당신의 능력을 사용하는건 훌륭한 자세입니다. 비록 당신의 추론이 틀렸다고 해도, 프로그래머는 당신의 수고에 대해서 감사할 것입니다. 그러나 증상뿐인 보고라면 수고를 늘려버릴지도 모릅니다.
  • "That's funny, it did it a moment ago."
  • "어라 웃기네요, 조금전까지는 움직였는데"
  • Say "intermittent fault" to any programmer and watch their face fall. The easy problems are the ones where performing a simple sequence of actions will cause the failure to occur. The programmer can then repeat those actions under closely observed test conditions and watch what happens in great detail. Too many problems simply don't work that way: there will be programs that fail once a week, or fail once in a blue moon, or never fail when you try them in front of the programmer but always fail when you have a deadline coming up.
  • 프로그래머에게 "간헐적인 오류"라고 말하면 얼굴을 떨구는 것을 볼 수있습니다. 그나마 해결하기에 수월한 문제는 단순히 일련의 작업을 수행하는것이 오류를 발생시키는 경우입니다. 그럴때 프로그래머는 밀접하게 관찰된 테스트 조건을 반복하여 세세하게 무슨일이 일어나는지 볼 수 있습니다. 너무 많은 문제들이 그런식으로 동작하지 않습니다. 일주일에 한번 실패하거나 드물게 실패하거나 또는 프로그래머 앞에서는 시연할때 절대 실패하지 않지만 마감일이 가까워지면 항상 실패하는 프로그램이 존재할 것입니다.
  • Most intermittent faults are not truly intermittent. Most of them have some logic somewhere. Some might occur when the machine is running out of memory, some might occur when another program tries to modify a critical file at the wrong moment, and some might occur only in the first half of every hour! (I've actually seen one of these.)
  • 대부분의 간헐적인 오류들은 진짜로 간헐적이지 않습니다. 대부분은 어딘가에 논리가 있습니다. 대부분은 컴퓨터의 메모리가 부족할 때 일어나는 것이고, 몇몇은 다른프로그램이 중요한 파일을 잘못된 시간에 변경하려고 할때 일어나는 것이고, 몇몇은 매 시간 30분정도만 일어나는 것일 수도 있습니다.
  • Also, if you can reproduce the bug but the programmer can't, it could very well be that their computer and your computer are different in some way and this difference is causing the problem. I had a program once whose window curled up into a little ball in the top left corner of the screen, and sat there and sulked. But it only did it on 800x600 screens; it was fine on my 1024x768 monitor.
  • 또한 당신은 버그를 재현 할 수 있는데, 프로그래머는 재현 할 수 없다면 분명히 그들의 컴퓨터 및 당신의 컴퓨터 어딘가에 차이가 있는것이고, 이 차이가 문제의 원인 것입니다. 한번은 창이 화면 왼쪽 상단 모서리의 작은 공처럼 웅크려지고 무응답 되는 프로그램이 있었습니다. 그러나 이 버그는 800 × 600 의 화면 에서만 일어나고, 1024 × 768 의 모니터 에서는 아무 문제 없었습니다.
  • The programmer will want to know anything you can find out about the problem. Try it on another machine, perhaps. Try it twice or three times and see how often it fails. If it goes wrong when you're doing serious work but not when you're trying to demonstrate it, it might be long running times or large files that make it fall over. Try to remember as much detail as you can about what you were doing to it when it did fall over, and if you see any patterns, mention them. Anything you can provide has to be some help. Even if it's only probabilistic (such as "it tends to crash more often when Emacs is running"), it might not provide direct clues to the cause of the problem, but it might help the programmer reproduce it.
  • 프로그래머는 문제에대해 당신이 알고 있는 것을 무엇이든지 알고싶어 할 것입니다. 할 수 있다면 다른 컴퓨터에서 시험해보세요. 두 번 또는 세 번 시도하고 얼마나 프로그램이 실패하는지를 보세요. 중요한 일을 하고 있을 사용하는 경우에는 이상이 생기는데, 문제를 현장 에서 보여 주려고 할 때 아무 이상이 없을 경우 오랫동안 실행 시키거나 큰 파일을 처리 하면 재현 할 수도 있을지도 모른다. 프로그램이 실패했을 때 무엇을하고 있었는지 가능한 한 상세하게 기억하도록 하세요. 또한 어떠한 패턴을 발견하게 된다면 언급해주세요. 당신이 제공할수 있는 것은 도움이 되어야 합니다. 단지 확률적인 것이라도 (예: " Emacs 가 실행하고 있을 때 더 충돌하는 경향이 있는 것 같다" ) 직접적인 단서가 되지는 않지만, 프로그래머가 그 문제를 재현하는 데 유용 할 수 있습니다 .
  • Most importantly, the programmer will want to be sure of whether they're dealing with a true intermittent fault or a machine-specific fault. They will want to know lots of details about your computer, so they can work out how it differs from theirs. A lot of these details will depend on the particular program, but one thing you should definitely be ready to provide is version numbers. The version number of the program itself, and the version number of the operating system, and probably the version numbers of any other programs that are involved in the problem.
  • 가장 중요한 것은 프로그래머가 다루고 있는 것이 진정으로 간헐적인인 결함인지 특정 컴퓨터에서 일어나는 결함 인지 확인 하고 싶어하는 것입니다. 그들의 컴퓨터와 당신의 컴퓨터가 얼마나 다른지를 알아내기 위해, 그들은 당신의 컴퓨터 정보를 많이 알고 싶어할 것입니다. 이러한 정보의 대부분은 특정 프로그램 에 의존하지만, 당신이 반드시 제공해야 하는 것 하나는 버전 정보 입니다. 프로그램 자체의 버전 번호 및 운영 체제 버전 번호, 문제에 관련한 다른 모든 프로그램의 버전 번호도 있습니다.
  • "So I loaded the disk on to my Windows . . ."
  • "그래서 Window 디스크를 로드했습니다...."
  • Writing clearly is essential in a bug report. If the programmer can't tell what you meant, you might as well not have said anything.
  • 명확하게 쓰는 것은 버그 리포트의 본질입니다. 당신의 의도 하는 바를 프로그래머가 알 수 없다면, 아무것도 말하지 않은 것과 같습니다.
  • I get bug reports from all around the world. Many of them are from non-native English speakers, and a lot of those apologise for their poor English. In general, the bug reports with apologies for their poor English are actually very clear and useful. All the most unclear reports come from native English speakers who assume that I will understand them even if they don't make any effort to be clear or precise.
  • 저는 전세계에서 버그 리포트를 받습니다. 그들의 대부분은 영어가 모국어가 아닌 사람들이고, 서투른 영어를 구사합니다. 일반적으로, 영어가 서툴어서 미안하다는 사과가 동반된 버그리포팅은 매우 명확하고 유용합니다. 오히려 불분명한 버그 리포트의 대부분은 영어가 모국어인 사람들로 부터 온 것이며, 그들은 딱히 간결하고 정확하게 표현하기 위한 노력을 하지 않아도 내가 잘 이해 할 것이라 생각합니다.
  • Be specific. If you can do the same thing two different ways, state which one you used. "I selected Load" might mean "I clicked on Load" or "I pressed Alt-L". Say which you did. Sometimes it matters.
  • 구체적으로 이야기하세요. 같은 일을 다른 두 방법으로 할 수 있다면, 어떤 방법을 사용 했는지 이야기하세요. "Load를 선택했습니다(selected) "는 " "Load를 클릭 했습니다 "또는 "Alt - L 을 눌렀습니다 " 두가지를 의미합니다. 어느 방법을 사용했는지 말하십시오. 종종 그것이 문제가 됩니다.
  • Be verbose. Give more information rather than less. If you say too much, the programmer can ignore some of it. If you say too little, they have to come back and ask more questions. One bug report I received was a single sentence; every time I asked for more information, the reporter would reply with another single sentence. It took me several weeks to get a useful amount of information, because it turned up one short sentence at a time.
  • 풀어서 이야기하세요. 가능한 한 많은 정보를 주세요. 너무 많은 정보를 준다해도, 프로그래머는 알아서 받아 들입니다. 너무 적게 말하면 그들은 회신하여 더 많은 질문을 해야 합니다. 제가받은 버그 리포트 중에는 문장 하나로만 구성되어 있는 것도 있었습니다. 매번 더 많은 정보를 부탁했고, 그들은 매번 다른 문장을 회신하곤 했습니다. 한 번에 하나의 짧은 문장이 밝혀질 뿐이므로, 충분한 양의 유용한 정보를 얻을 때까지는 몇 주가 걸렸습니다 .
  • Be careful of pronouns. Don't use words like "it", or references like "the window", when it's unclear what they mean. Consider this: "I started FooApp. It put up a warning window. I tried to close it and it crashed." It isn't clear what the user tried to close. Did they try to close the warning window, or the whole of FooApp? It makes a difference. Instead, you could say "I started FooApp, which put up a warning window. I tried to close the warning window, and FooApp crashed." This is longer and more repetitive, but also clearer and less easy to misunderstand.
  • 대명사에 주의하세요 . "it" 와 같은 단어나 "the window"와 같은 참조는 의미가 불분명 할 때에는 사용하지 마세요. " FooApp 를 시작한 후 경고 창이 나왔습니다. 그것을 닫으려고 하면 충돌 했습니다 " 라는 글을 생각해보세요. 이 것만으로는 이용자가 무엇을 닫으려고 했는지 알수 없습니다. 경고창을 닫으려 했을까요, FooApp 전체를 닫으려 했을까요? 이것은 중요하다. 이와 같은 방법 대신 " FooApp 를 시작한 후 경고 창이 나왔습니다. 경고 창을 닫으려고 하면 FooApp 가 종료되었다 "고 말할 수 있습니다. 두번 째 문장이 길고 반복이 많지만, 더 명확하고 오해의 여지가 적습니다.
  • Read what you wrote. Read the report back to yourself, and see if you think it's clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step.
  • 당신이 쓴 내용을 읽어보세요. 스스로 리포트를 검토하여, 명확하다고 생각 되는지 확인 하세요. 실패를 만들어야 하는 (버그를 재현하기 위한 과정) 하는 일련의 작업이 있다면 단계를 건너 뛰지 않았는지 직접 따라하면서 검토해보세요.
  • Summary
  • 요약
  • The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
  • 버그 리포트의 첫 번째 목적은 프로그래머에게 그들 자신의 눈으로 실패 를 확인하게 하는 것 입니다. 그들에게로 가서 직접 프로그램을 실패할 수 없는 경우, 프로그래머들이 스스로 프로그램을 실패 시킬 수 있도록 자세한 지침을 주세요.
  • In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
  • 첫 번째 목적이 잘 되지 않아서 프로그래머가 직접 실패를 확인할 수 없었던 경우, 두 번째 목적은 무엇이 잘못 되었는가를 설명 하는 것입니다. 모든것을 자세히 설명 하세요. 무엇을 보았는지, 당신이 기대하고 있던 결과는 무엇인지 밝히세요. 오류 메시지를 적으세요, 특히 숫자가 포함되어 있는 것은 꼭!
  • When your computer does something unexpected, freeze. Do nothing until you're calm, and don't do anything that you think might be dangerous.
  • 컴퓨터가 예기치 않은 동작을 하면 가만히 있으세요. 당신이 진정 될 때까지 아무것도 하지마세요. 위험하다고 생각 되는 일은 하지 말아야 합니다.
  • By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
  • 물론, 당신이 할 수 있다고 생각하는 경우 오류를 직접 진단하려고 노력하세요. 하지만, 당신이 진단한다고 해도 여전히 증상을 보고 해야합니다.
  • Be ready to provide extra information if the programmer needs it. If they didn't need it, they wouldn't be asking for it. They aren't being deliberately awkward. Have version numbers at your fingertips, because they will probably be needed.
  • 프로그래머가 필요로 한다면, 추가 정보를 제공 하세요. 만약에 필요 없었다면 요청하지 않았을 것입니다. 일부러 서투른 행동을 하는게 아닙니다. 필요로 할지도 모르니, 버전 번호를 쉽게 제공 할 수 있도록 항상 준비해두세요.(미리 알아두세요)
  • Write clearly. Say what you mean, and make sure it can't be misinterpreted.
  • 명쾌하게 쓰세요. 당신이 의미 하는 바를 말하고, 잘못 해석 되지 않도록 조심하세요 .
  • Above all, be precise. Programmers like precision.
  • 무엇 보다도 정확해야합니다. 프로그래머는 정확함을 좋아합니다.
  • ---------------------------------------------------------------------------------------------------------------------------------------------
  • ---------------------------------------------------------------------------------------------------------------------------------------------
  • Disclaimer: I've never actually seen a mongoose or an antelope. My zoology may be inaccurate.
  • 부인성명서 : 사실 나는 몽구스 와 영양 을 본 적이 없습니다. 내 동물학 지식은 부정확 할지도 모릅니다.
  • $Id$
  • ID
  • Copyright © 1999 Simon Tatham.
  • Copyright © 1999 Simon Tatham.
  • This document is OpenContent.
  • 이 문서는 공개 문서입니다.
  • You may copy and use the text under the terms of the OpenContent Licence.
  • You may copy and use the text under the terms of the OpenContent Licence.
  • ---------------------------------------------------------------------------------------------------------------------------------------------
  • ----------------------------------------------------------------------------------------------------------------------------------------
  • This article is not specific to any particular program.
  • 이 문서는 특정 프로그램을 위해 작성된 것은 아닙니다
  • If you have reached this page by following a link from the website for a particular program, DO NOT send bug reports for that program to me. Instead, return to the page you came from to find out where to report bugs in the program.
  • 특정 프로그램의 웹 사이트에서 링크를 따라 이 페이지에 방문했다면 그 프로그램의 버그 리포트를 내게 보내지 마십시오. 대신에 원래 있었다 페이지로 돌아가 그 프로그램의 버그를 어디에보고하면 좋을지 살펴 보세요
  • If you have comments or criticism about this article itself, please send them to anakin@pobox.com.
  • 이 문서 자체에 만약 의견과 비판이 있으면 anakin@pobox.com 보내주십시오.
0 Comments