버그 추적기에서 버그 보고서의 품질을 어떻게 시행하거나 유지합니까?

Question

효과적인 버그 추적을 위해서는 고품질 버그 보고서가 필수적입니다. 이상적인 세상에서는 모든 버그 보고서에는 해당 버그가 영향을 미치는 소프트웨어 버전 및 버그 재현 방법에 대한 단계별 설명과 같은 필수 정보가 포함됩니다.

하지만 실제로는 보고된 버그의 품질이 많이 다를 수 있습니다.온라인 상태("기능 X가 작동하지 않습니다. 수정하세요!"), 기능 요청, PEBKAC 또는 이해할 수 없는 내용일 수 있습니다.

버그 추적기의 버그 보고서 품질을 효과적으로 유지하기 위해 어떻게 시행하거나 유지합니까?

Answer 1

저는 Jon Limjap의 의견에 동의합니다. QA 담당자는 올바른 기본 교육과 지침을 바탕으로 적절한 버그 보고서를 게시할 수 있을 만큼 유능해야 합니다.그럼에도 불구하고 더 나은 버그 보고를 시행하고 장려하는 방법이 있습니다.

• 대부분의 버그 추적 소프트웨어에는 버그 보고서의 일부 필드를 필수 항목으로 표시하는 방법이 있으므로 보고자가 버그를 성공적으로 생성하려면 실제로 적절한 값을 선택해야 합니다.
• 일반적으로 버그 보고서에 대한 기본 템플릿을 포함할 가능성이 있습니다.

대본:

예상 결과:

실제 결과:

비고:

• 문제가 있는 시스템에서 실행될 버그 보고 도구를 제공하고 관련 정보를 수집하여 아카이브 파일에 압축할 수 있습니다(그리고 데스크탑에 배치할 수도 있습니다).그런 다음 직원에게 보고하고 싶은 버그가 발생할 때마다 이를 실행하고 버그에 아카이브를 첨부하도록 지시합니다.이 도구는 사용하기 쉬워서(단지 실행 파일만 실행하면) 관련 여부를 생각할 필요 없이 버그에 진단 정보를 첨부할 수 있어야 합니다.이 도구는 일반적으로 고객에게도 매우 유용합니다.
• 마지막으로 중요한 것은 "교육, 교육, 교육"입니다.사람들은 경험을 통해 가장 잘 배웁니다. 누군가 적절한 정보가 포함되지 않은 버그를 열 때마다 버그를 처리하는 사람이 버그를 연 사람에게 가서 누락된 내용과 그것이 왜 중요한지 설명하도록 하십시오.

이것은 우리가 현재 직장에서 매우 성공적으로 사용해 온 관행이며 대부분의 작업 환경에 적합할 정도로 보편적이라고 믿습니다.

Answer 2

나는 버그 보고서의 품질이 매우 중요하다고 생각하곤 했습니다.나는 아직도 그렇게 생각한다...내가 보고한 버그에는 QA나 운영 부서에서 입력한 것보다 훨씬 더 유용한 정보가 들어 있습니다.그러나 나는 FogBugz의 모델에 감탄하게 되었습니다.버그를 입력하는 것은 매우 간단합니다.지원 정보가 많지 않더라도 오류 조건이 있다는 것을 아는 것만으로도 도움이 됩니다.게다가 사용자는 뭔가가 완료되고 있다는 느낌을 받습니다.

Answer 3

추적기 사용과 각 필드에 필요한 사항에 대해 훌륭하지만 너무 길지 않은 튜토리얼을 작성하세요.다른 사람들이 막힐 경우 사용할 수 있는 범용 참조 예제를 만드십시오.

나는 Docbook 매뉴얼 페이지를 편집하기 위한 참조 사본을 가지고 있으며 이것을 반복적으로 사용함으로써 나는 이미 대부분의 구문을 암기하고 있습니다.

Answer 4

이는 비공개 QA 검토와 공개 베타에 대해 이야기하는지 여부에 따라 다릅니다.

공개 베타인 경우 사용자가 버그 목록을 직접 편집하도록 허용하는 것은 바람직하지 않습니다.사용자 의견과 보고서를 집계하고 실제 버그와 중복된 버그를 식별하고 이를 복제하는 방법에 대한 일종의 단서를 제공하는 사람을 할당해야 합니다.

그러나 이것이 합법적인 QA 담당자가 게시한 버그 항목이라면 직원의 역량 문제가 있는 것입니다.버그를 보고하는 방법, 특히 복제 단계를 바로잡는 방법에 대한 적절한 지침을 설정해야 합니다.

Answer 5

어려운 질문.시스템에 필요한 특정 필드를 입력하도록 강제할 수 있는 방법이 있는지 확인하고, 중요한 버그가 어떻게든(이메일, RSS) 눈에 띄도록 하여 빠르게 공격할 수 있도록 노력하겠습니다. 귀하의 팀은 품질 표준을 알고 이를 준수하며 지침이 게시되고 공개됩니다.

귀하의 팀이라고 가정합니다.주석 필드에 매번 사용되는 특정 구조(입력 시 예상되는 구조)를 가질 수 있다면 그것도 좋을 것입니다. 소프트웨어에 해당 구조를 정의할 수 있는 기본 메모 개요가 있는 경우 더욱 좋습니다. 빈 양식.

하지만 어느 정도는 개인에게 달려 있습니다. 의사소통 표준의 일부이고 업무 요구 사항으로 예상되며 팀의 다른 모든 구성원에 대한 책임이 있다는 점을 인식해야 합니다. 피할 수 있다면 더 자세한 내용을 찾기 위해 그들을 추적할 수 있는 위치에 있지 마십시오.

특히 우선순위가 낮은 항목의 버그를 수정하는 데 소요되는 시간은 다소 시간이 걸릴 수 있으며 사람들은 세부 사항을 잊어버리기 쉽습니다.

사용자라고 가정하면 다음과 같습니다.높은 수준까지는 할 수 없지만 가능하다면 사람들이 이해할 수 있는 방식으로 어떤 형태로든 질문하려고 노력하겠습니다.

이 주제에 관한 전체 내용은 아니지만 "질문하는 방법"과 같은 방식으로 37 Signals 블로그에 있는 이 게시물은 다음과 같습니다. 링크 텍스트

사용자에게 표시되는 질문을 하는 다른 양식이 있어야 하고 대부분의 데이터만 버그 프로그램에 공급되어야 한다고 해도 저는 올바른 질문을 하기 위해 그렇게 할 것입니다.

어떤 제품인가요?버전은 무엇입니까(찾는 방법을 보여주는 그림)?프로그램을 열고 버튼을 눌러 자동으로 로그 파일을 보낼 수 있다면 화면 덤프를 포함시키는 것이 도움이 될 것입니다. 이로 인해 추가 작업이 중단되었는지, 변경 사항이 손실되었는지 여부 등이 있습니다.

사용자의 경우 질문을 하는 방법에 대해 더 중요할 것이며 특정 질문에 대한 답변이 필요하거나 어떤 질문이 더 도움이 될지 알려주면 더 나은 응답을 얻을 수 있을 것입니다.

Answer 6

다음과 같은 것을 사용하십시오 사용자의 목소리 최종 사용자가 버그 및 기능 요청을 보고할 수 있습니다.버그 추적기 항목은 실제로 내부적이어야 합니다. 최종 사용자에게는 너무 기술적이며 IMHO는 내부 작업을 너무 많이 노출합니다.