문서버그 보고서에 넣을 내용
문제 재현 지침 문제를 재현하려면 개발자는 사용 중인 제품, 출처 및 설치 방법을 알아야 합니다.
문제를 재현하는 방법을 설명하는 정확한 단계별 지침을 제공해야 합니다. 문제를 재현하기 위해 일부 데이터를 사용해야 하는 경우 해당 파일을 버그 보고서에 첨부하세요. 버그를 재현하는 데 필요한 최소한의 지침 세트를 생각해 보십시오.
몇 가지 맥락을 제시하고 기대치를 설정하십시오. 무엇을 하려고 했는지, 그리고 프로그램이 어떻게 작동할 것으로 기대했는지 설명하십시오.
어떤 경우에는 개발자가 작동하도록 설계하지 않은 방식으로 프로그램을 사용했기 때문에 버그가 발생하는 경우도 있습니다. 달성하려는 목표를 설명하면 개발자가 이러한 경우를 명확하게 확인할 수 있습니다.
다른 경우에는 버그라고 설명하는 동작이 실제로는 정상적인 동작일 수도 있습니다. 프로그램에서 기대했던 바를 명시적으로 설명하세요. 이는 개발자의 상황을 명확하게 해줄 것입니다. 그들은 동작을 개선하거나 문서를 개선할 수 있지만 적어도 프로그램의 동작이 일부 사용자를 혼란스럽게 한다는 것을 알고 있습니다!
구체적으로 사용하는 소프트웨어의 버전 번호를 포함하십시오(가능한 경우 해당 종속성의 버전 번호도 포함). 다운로드한 항목을 언급할 때는 전체 URL을 포함하세요.
오류 메시지가 나타나면 본 그대로 정확하게 인용하세요. 가능하다면 화면 출력 사본이나 스크린샷을 포함하세요. 관련 로그 파일의 사본을 포함하여 민감한 데이터를 먼저 제거하십시오.
가능한 수정 사항이나 해결 방법을 언급하십시오. 버그 보고서를 제출하기 전에 문제 해결을 시도했을 것입니다. 무엇을 시도했고 어떤 결과를 얻었는지 설명하세요. 무엇이 사실이고 무엇이 단지 가설에 불과했는지 명확하게 설명하세요.
인터넷 검색을 해서 유사한 문제에 대한 설명을 찾았다면, 특히 데비안 버그 추적기나 업스트림 버그 추적기에서 다른 유사한 버그 보고서를 찾았을 때 언급할 수 있습니다.
버그를 유발하지 않고 원하는 결과를 얻을 수 있는 방법을 찾았다면 그 내용도 문서화해 주세요. 이는 동일한 문제를 겪는 다른 사용자에게 도움이 될 것입니다.
긴 버그 보고서는 괜찮습니다. 두 줄의 버그 보고서로는 충분하지 않습니다. 필요한 모든 정보를 제공하려면 일반적으로 여러 단락(때로는 페이지)의 텍스트가 필요합니다.
가능한 모든 정보를 제공하세요. 관련된 내용을 고수하려고 노력하십시오. 그러나 확신이 없다면 너무 적은 것보다는 너무 많은 것이 낫습니다.
버그 보고서가 너무 길면 시간을 내어 콘텐츠를 구성하고 처음에 간단한 요약을 제공하세요.