번역이 완료되지 않았습니다. Please help translate this article from English
이 페이지는 2014년 4분기에 모질라 QA팀의 테크니컬 리뷰를 받아야합니다.(Ioana Chiorean님이 담당합니다) QMO의 How to write a proper bug페이지 글이 이 글로 병합되었습니다.
효과적인 버그 리프트는 수정될 수 있을것 같이 작성한 것입니다. 이 가이드 라인은 그런 보고서를 작성하기 위한 방법을 설명합니다.
- 당신의 소프트웨어가 최신버전인지 확인하십시오.
- Bugzilla 에서 해당 버그가 발견되었는지 확인하십시오. (예제).
- 새로운 버그리포트를 작성할때에는 대부분 버그 리포팅 방법을 안내합니다.
- 여러 가지 이슈사항을 가지고 있다면, 버그리포트를 각각 분리해서 제출하십시오.
재현가능한 정확한 단계 작성
어떻게 개발자는 자신의 컴퓨터에서 버그를 재현할 수 있을까요?
재현 단계는 버그 보고서 전체에서 가장 중요한 부분입니다. 개발자가 버그를 재현 가능한 경우에 고쳐질 가능성이 매우 높습니다. 만약 이 과정이 명확하지 않은 경우에는, 버그가 수정되었는지조차 모를 수도 있습니다.
각 단계의 의도와 더불어 Firefox와의 상호작용을 개연성있게 설명하십시오.
- 잘못된 예 : "다른 창에서 Gmail 열기"
- 올바른 예 : "Cmd + N을 눌러 새 브라우저 창을 열고, 검색 주소창에 https://mail.google.com/을 입력하고 Enter 키를 누르십시오. "
당신이 지시한 단계를 진행한 후, 예상했던 결과와 관찰력롸를 명확하게 설명하십시오. 추측에서 명확하게 관찰결과를 분리하십시오.
- 잘못된 예 : "동작하지 않습니다."
올바른 예 : "내 편지함이 보이지 않고, 다음과 같은 메시지가 출력됩니다. '당신의 브라우저는 쿠키를 지원하지 않습니다. (error -91)' "
명확한 요약문 작성
어떻게하면 간략하게 버그를 설명할 수 있을까요? 이것은 버그 관리자(Triager)나 개발자가 볼 문서의 첫 부분입니다.
좋은 요약문은 짧고 명확하게 구분가능하게 작성되어야 합니다. 그리고 해결책이 아닌 문제에 집중하여 설명해야합니다.
- 좋은 예 : "파일 복사 메시지에서 취소를 누르면, 파일관리자에서 오류가 발생함."
- 나쁜 예 : "소프트웨어 오류"
- 좋은 예 : "overflow : hidden으로 스타일이 지정된 <textarea>에서 아래쪽 화살표 스크롤이 작동하지 않습니다."
- 나쁜 예 : "내 웹사이트에서 브라우저가 동작해야합니다."
Finding the correct product and component
You will be asked to categorize your bug into a "product" and a "component" within that product, in order to direct your report to the correct developers.
If you're using Firefox, the bug is most likely in "Firefox", "Toolkit", or "Core".
- List of components in the "Firefox" product - Most parts of Firefox that you interact with directly
- List of components in the "Toolkit" product - Interface widgets and some frontend features
- List of components in the "Core" product - Web page rendering, networking, etc.
When in doubt, search for similar bugs and see what component they are in.
If none of the components seem appropriate, look for a "General" component in the most appropriate product.
Specific types of bugs
If you are reporting a crash bug, please include a Breakpad ID or attach stack trace, and include the crash signature in the bug summary.
If you are reporting a memory use or leak bug, please attach the output of about:memory (Firefox 6+). Ideally, find steps to reproduce an increase in what is shown in about:memory (even after clicking the "Minimize memory usage" button at the bottom). If you have trouble finding steps to reproduce, try the Firefox Support page titled High Memory Usage. If you are a C++ developer, more precise tools are available.
If you are reporting a bug involving a specific web page, please try to make a reduced testcase and attach it to the bug report.
If the bug was recently introduced, finding a regression window can help identify the cause of the bug.
Original document information
- Author(s): Jesse Ruderman, Gervase Markham
- Other Contributors: Eli Goldberg, Claudius Gayle, Jan Leger, Felix Miata, Peter Mock, Chris Pratt, Chris Yeh, and others.
The following article has been merged into this page from QMO: How to write a proper bug
Bug Validity Checklist
Verify the problem you found is a New Bug
To verify if what you've found is indeed a new software bug in one of Mozilla's products, go through the following checklist to make sure it's something worth creating a new bug report for.
- Make sure it's a software bug. It should be either an error, flaw, mistake failure of fault in the browser that produces an incorrect and/or unexpected result.
- See if it's an already known bug by looking at your particular version's release notes
- Make sure that no one has already fixed the problem by re-verifying the bug against the latest trunk nightly located here
- Make sure there isn't a duplicate bug already created by using this handy guide to search through Bugzilla for your problem
If you're lost and not sure what to do always check out the IRC channel, #qa, at irc.mozilla.org and ask there. If no one answers, try posting to our Bugzilla forums. Otherwise if you haven't found your software bug, its time to write a bug report!
The Bug Report
Where do I go to create a bug?
- Mozilla's main tracking tool for reporting, investigating and fixing bugs is located here. The first step in order to log a bug, is to register an account. To do that, go to Bugzilla's home page and click on the "New Account" hyperlink at the top of the page.
- After registering and then logging into your new account, go back to the Bugzilla home page and click on the "New" hyperlink at the top of the page. Click the product that the bug is found in and fill out the resulting form. If you have any issues with finding the product you want to file the bug for, go to the #qa channel at irc.mozilla.org and ask for help from our very friendly MozQA community.
What does the community want to see in a bug report?
There are a couple of generally-held principles that should be taken into account when creating a bug. They would be the following:
- Keep the Description and Summary clear and concise
- Only report one issue in a bug report
- Report only facts in your bugs and remove any assumptions you might have
General Outline of a Bug Report
- Summary: How would you describe the bug in less than 60 characters? It should quickly and uniquely identify a bug report as well as explain the problem, not your suggested solution.Good: "Cancelling a File Copy dialog crashes File Manager" Bad: "Software crashes" Bad: "Browser should work with my web site"
- Component: In which sub-part of the software does it exist?This field is a requirement to submit any bug report. Click the word "Component" to see a description of each component. If none seems appropriate, highlight the "General" component.
- OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)Example: "If you know the bug happens on more than one type of operating system, choose "All". If your OS isn't listed, choose Other".
- Description: The details of your problem report, including:-Overview: This is a larger detailed restatement of the summary. An example would be: "Drag-selecting any page crashes Mac builds in the NSGetFactory function". -Build Id: To find this either go to the "about:" page via the location bar or, if you have MozQA's Nightly Tester Tools extension, then go to Tools | Nightly Tester Tools and select the option that contains the output of the build Id. It should look something like this: "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3". -Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable). It should look something like this: "Doesn't Occur On Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20081107 Firefox/3.1b2".
- Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. If they're necessary, make sure to include any special setup steps.A good example of this would look like the following: 1) View any web page. (I used the default sample page, http://www.google.com/). 2) Drag-select the page. Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.
- Actual Results: What the application did after performing the above steps.An example would be: The application crashed.
- Expected Results: What the application should have done, were the bug not present.An example would be: The window should scroll downwards. Scrolled content should be selected. Or, at least, the application should not crash.
Continue reading How to Write a Proper Bug Report Part 2
Original document information
- Author(s): Aakash Desai
- Date last modified: June 3, 2013 at 2:41 am PST
Triager 라는 직업군을 처음봤으나 구글 검색결과 가장 의미에 부합하는 단어로 번역해봤습니다.