Bug Writing Guidelines

MDC

[편집] 이것을 읽어야 하는 이유

The Mozilla bug tracking system (Bugzilla) allows any interested individuals on the Internet to directly report and track bugs in mozilla.org open-source projects like the Mozilla Application Suite or Mozilla Firefox. Like you, Mozilla QA (Quality Assurance) wants your bug reports to result in bug fixes; the more effectively a bug is reported, the more likely that an engineer will actually fix it. By following these guidelines, you can help ensure that your bugs stay at the top of the Mozilla engineers' heap, and get fixed. Bugzilla is the preferred method of submitting a bug -- the linked entry form incorporates parts of these guidelines. 모질라 버그 추적 시스템(Bugzilla)은 모질라 통합 프로그램이나 모질라 파이어폭스와 같은 Mozilla.org 오픈 소스 프로젝트에 대해 인터넷에서 직접적으로 버그 보고와 추적을 할 수 있게 합니다. (Mozilla QA (품질 보증)는 버그 수정을 위해 당신의 버그 리포트를 필요로 합니다) 좀 더 효과적으로 버그를 보고한다면 개발자들은 좀 더 알맞게 버그를 수정할 것입니다. 이 지침을 따름으로써 모질라 개발자의 처리 목록에서 상위에 위치하여 확실한 도움을 받을 수 있습니다. 버그질라는 버그를 제출하는데 좋은 방법입니다. - 연결된 목록 양식은 이 지침의 각 부분이 통합되어 있습니다.

[편집] 유용한 버그 리포트를 쓰는 방법

Useful bug reports are ones that get bugs fixed. A useful bug report normally has two qualities: 유용한 버그 리포트는 버그가 수정되도록 합니다. 유용한 버그 리포트는 일반적으로 두 가지 장점을 가지고 있습니다:

1. Reproducible. If an engineer can't see the problem or conclusively prove that it exists, the engineer will probably stamp it WORKSFORME or INVALID, and move on to the next bug. Every relevant detail you can provide helps.
2. Specific. The quicker the engineer can isolate the issue to a specific problem, the more likely it'll be expediently fixed. If you're crashing on a site, please take the time to isolate what on the page is triggering the crash, and include it as an HTML snippet in the bug report if possible. (Specific bugs have the added bonus of remaining relevant when an engineer actually gets to them; in a rapidly changing web, a bug report of "foo.com crashes my browser" becomes meaningless after the site experiences a half-dozen redesigns and hundreds of content changes.)
3. 재현 가능성. 만일 개발자가 문제를 확인할 수 없거나 그 버그가 존재하는 지 확신할 수 없다면 개발자는 아마도 WORKSFORME이나 INVALID라고 도장찍어놓고 다음 버그로 넘어갈 것입니다. 당신이 줄 수 있는 모든 관련된 요소를 제공하여 주십시오.
4. 특징. 좀 더 빨리 개발자가 특정 문제로부터 주제를 구분할 수 있게 되면 좀 더 알맞게 버그가 수정되어 질 수 있습니다. 만일 당신이 사이트에서 문제가 생겼다면 시간을 조금 들여 사이트에서 무엇이 문제를 일으키는 지를 구분하고, 가능하다면 버그 리포트에 HTML 일부분을 포함시켜 주십시오. ( 특징적인 버그는 개발자가 실제로 버그 리포팅을 받았을 때 알맞게 남아있는 추가적인 내용을 가지고 있어야 합니다. 빠르게 변하는 웹에서 "foo.com이 제 브라우져와 충돌이 생깁니다."라는 버그 리포트는 사이트가 6번이나 다시 디자인되고 수 백개의 내용이 바뀐 후에는 의미가 없습니다.)

Let's say you crash at foo.com, and want to write up a bug report: 자 이제 당신에게 문제가 생긴 foo.com을 살펴보고 버그 리포트를 작성하길 원하고 있습니다:

BAD: "My browser crashed. I think I was on foo.com. I think that this is a really bad problem and you should fix it or else nobody will use your browser. By the way, my sister thinks your icons really suck. Oh, and my mom's home page doesn't look right, either, it's all messed up. Thx 4 fixing theze bugz." 잘못된 예: "제 브라우져에 문제가 생겼습니다. 아마도 foo.com에서 생긴 문제 같습니다. 제가 보기에 이것은 정말 심각한 문제입니다. 당신들이 이것을 고치지 않으면 아무도 당신들의 브라우져를 사용하지 않을 겁니다. 어쨌거나 내 여동생이 생각하기에 당신들의 아이콘이 정말 별로라고 생각합니다. 오, 제 어머니도 홈페이지가 제대로 안 보인다고 합니다. 몽땅 다 문제입니다. 이런 버그가 고쳐질 것에 대해 감사드립니다."

GOOD: "I crashed each time when I went to foo.com, using Mozilla on a Win NT 4.0 (Service Pack 5) system. The build ID is 20030609. I also rebooted into Linux, and reproduced this problem using the 20030608 Linux build. Mozilla crashed each time upon drawing the Foo banner at the top of the page. I broke apart the page, and discovered that the following image link will crash Mozilla reproducibly, unless you remove the "border=0" attribute: <IMG SRC="http://foo.com/images/topics/topicfoos.gif" width=34 height=44 border=0 alt="News"> 올바른 예: "윈도우 NT 4.0 (서비스팩 5)를 사용하는 시스템에서 모질라를 이용하여 foo.com에 접속할 때마다 문제가 발생합니다. 모질라 빌드 ID는 20030609입니다. 저는 또한 20030608 리눅스 버젼에서도 같은 문제를 경험하였습니다. 모질라는 페이지의 위에 있는 Foo 배너를 표시할 때마다 충돌이 발생했습니다. 페이지를 구분하여 확인해 본 결과 <IMG SRC="http://foo.com/images/topics/topicfoos.gif" width=34 height=44 border=0 alt="News"> 부분에서 "border=0" 요소를 지우지 않는다면 모질라에 문제를 일으키는 것을 확인하였습니다."

If your problem is Mozilla crashing, Talkback data is very helpful to engineers trying to diagnose the problem. If you can consistently reproduce the crash, please download a build with Talkback and install it. Then, do what is necessary to reproduce the crash, and follow the instructions for sending crash data to the server. Lastly, run the program components/talkback.exe (Win32) or components/talkback/talkback (Unix) and find your "Incident ID". Include this with the bug report. Please don't paste the raw Talkback data into your bug. See Talkback page on MozillaZine for more information about Talkback.

We'd also recommend reviewing a few of the better bug reports, such as 2683, 3092 or 4044. Bug submissions that do not meet these "Useful Bug Report" criteria tend to be investigated on a time-available basis, if they're investigated at all.

[편집] How to enter your useful bug report into Bugzilla

Before you enter your bug, you need to make sure it has not been previously reported. There is a tutorial on the best ways of doing this.

Next, be sure that you've reproduced your bug using a build released within the past three days. Our development process moves at lightning speed, and the bug you've found may already have been fixed. (Nightly builds can be downloaded from the mozilla.org binaries page.) If you've discovered a new bug using a current build, report it in the guided Bugzilla entry form.

1. Are you sure you don't want to use the guided form? You won't have to read the rest of this page if you do.

2. Okay, then. From the Bugzilla main page (http://bugzilla.mozilla.org), choose "Enter a new bug".

3. Select the product that you've found a bug in.

4. If you haven't logged into Bugzilla already, you'll need to enter your email address and password, then press the "Login" button. (If you don't yet have a password, enter your email address below and press the "Submit Request" button instead. You'll receive an email message with your password shortly.)

Now, fill out the form. Here's what it all means:

[편집] Where did you find the bug?

Product: In which product did you find the bug? You just filled this out on the last page.

Version: In which product version did you find the bug? We're not yet using this field. Just leave the default value as you found it. ;)

Component: In which component does the bug exist?

Bugzilla requires that you select a component to enter a bug. (If they all look meaningless, click on the Component link, which links to descriptions of each component, to help you make the best choice.)

Platform: On which hardware platform did you find this bug? (e.g. Macintosh, SGI, Sun, PC.) If you know the bug happens on all hardware platforms, choose 'All'. Otherwise, select the platform that you found the bug on, or "Other" if your platform isn't listed.

OS: On which Operating System (OS) did you find this bug? (e.g. Linux, Windows NT, Mac OS X) If you know the bug happens on all OSs, choose 'All'. Otherwise, select the OS that you found the bug on, or "Other" if your OS isn't listed.

[편집] How important is the bug?

Severity: How damaging is the bug? This item defaults to "normal". (To determine the most appropriate severity for a particular bug, click on the Severity link for a full explanation of each choice, from Critical to Enhancement.)

[편집] Who will be following up on the bug?

Assigned To: Which engineer should be responsible for fixing this bug?

Bugzilla will automatically assign the bug to a default engineer based on the component when you submit the bug report; this text box lets you manually assign it to a different engineer. (To see the list of default engineers for each component, click on the Component link.)

Cc: Who else should receive e-mail updates on changes to this bug? List the full e-mail addresses of other individuals who should receive an e-mail update upon every change to the bug report. You can enter as many e-mail addresses as you'd like; e-mail addresses must be separated by commas, with no spaces between the addresses.

[편집] What else can you tell the engineer about the bug?

URL: On what URL did you discover this bug? If you encountered the bug on a particular URL, please provide it (or, them) here. If you've isolated the bug to a specific HTML snippet, please also provide a URL for that, too or, preferably, return to the bug after you've submitted it and add the HTML snippet as an attachment.

Summary: How would you describe the bug, in approximately 60 or fewer characters? A good summary should quickly and uniquely identify a bug report. Otherwise, developers cannot meaningfully query by bug summary, and will often fail to pay attention to your bug report when reviewing a 10 page bug list. Think of it as a "title".

A summary like "Drag-scrolling any web page crashes Mac OS X builds" is a useful title. "Crash" or "Drag Crash" would be examples of a bad title.

Description: What else can you tell the engineer about this bug? Please provide as detailed of a problem diagnosis in this field as possible, using the following example as a template to go by:

You're done!

After double-checking your entries for any possible errors, press the "Commit" button, and your bug report will be part of the Bugzilla database.