사용자가 적절하고 유용한 버그 보고서를 작성하도록하기

누구나 사용자가 반쯤 괜찮은 (읽기 : 유용한 ) 버그 보고서 를 작성 하도록하는 좋은 방법을 알고 있습니까?

우리는 대부분의 사용자에게 이해하기 쉬운 내용을 읽고 싶었지만 (읽기 쉽고 이해하기는했지만) 개발자에게 유용한 정보를 제공했습니다.

파란색 버튼을 클릭하면 작동하지 않습니다! 아, 방금 일주일의 일을 잃어 버렸어요.

그다지 유용하지 않습니다.

나는 목록에 대해 고치기 시작했지만 비슷한 방법이 이미 있는지 당신들과 함께 확인하려고 생각했습니다.

사용자가 적절하고 유용한 버그 보고서를 작성하도록하는 가장 효과적인 방법은

1. 온라인으로 보고서를 볼 수 있도록 ...
   ^{[시스템]보고 해 주셔서 감사합니다. 요청 상태는 여기에서 찾을 수 있습니다.}
2. ... 지정된 엔지니어 의 평가 및 의견 과 함께 ...
   ^{[엔지니어] 다음 세부 사항에 대한 요청이 거부되었습니다. ...}
3. ... 보고서 를 편집 / 개선 하는 옵션이 있습니다.
   ^{[사용자] 요청한 세부 사항이 추가되었습니다. 다시 평가하십시오 : ...}

그것이 유일한 효과적인 방법 이라고 주장하기까지는 갈 것입니다 .

사실, 버그 리포트를 효과적으로 작성하는 기술 은 경험과 함께 제공됩니다. 경험을 얻는 법을 배워야합니다. 학습에는 연습, 피드백 받기 및 개선이 포함됩니다.

사용자가 편집 할 수있는 온라인 버그 보고서는 사용자에게 개선 을 가르치는 가장 효율적인 방법 입니다.

• ^{위의 대안 옵션은 1) 사용자와의 대면 학습 세션을 준비하는 것입니다 (특히 전 세계에 수천 개가 퍼져있는 경우). 또는 2) 전화로 설명해주십시오 ( "225 번 줄에 쓴 쓰레기 만 볼 수 있다면 ..."). 또 뭐요? 오) 3) 이메일로, "당신이 우리에게 보낸 2 개월 전에 보낸 메일에서, 당신은 언급하지 않았습니다 ... 그 이메일이 아니라, 오늘 우리에게 5 개의 이메일을 보냈으며, 그중 3 개는 제목 Re 와 함께있었습니다 : 파란색 버튼 클릭 ,보세요 두 번째는 10Mb 스크린 샷이 첨부 된 것인데 ... 무엇을 찾을 수 없습니까? "}

제 생각에는 더 중요한 것은 버그를 사용하여 사용자와의 연락을 의미있게 만드는 것입니다. 버그 보고서를 작성하고 이해하는 것은 기술이며, 사용자가 가능한 한 쉽게 첫 접촉을 한 다음 필요에 따라 더 많은 가치에 대한 피드백을 점진적으로 제공하는 것이 좋습니다.

예를 들어, 사용자의 이메일을 받고 다음 텍스트가 포함 된 일반 텍스트 필드를 제공하십시오.

"I did _____ , and expected ______ to happen, but ______ happened instead."

이메일을받은 후 자동 회신을 통해 버그를 제출했는지 확인하기 위해 이중 선택을 받도록합니다. 버그를 받았으며 버그에 대한 후속 조치는 괜찮습니다.

이 주제에 대해 Mozilla와 Sun의 아이디어를 고려할 수 있습니다.

• 버그 작성 지침 -Mozilla MDN 기사
• 적절한 버그를 작성하는 방법 -Mozilla QMO 기사
• 유용한 버그 보고서를 작성하는 방법 -Sun SDN article

특히 (모질라 "적절한 버그를 작성하는 방법"페이지에서) :

버그 리포트의 개요

요약 : 버그를 60 자 미만으로 어떻게 설명 하시겠습니까? 제안 된 해결책이 아니라 문제를 설명 할뿐 아니라 버그 보고서를 빠르고 고유하게 식별해야합니다.

양호 :“파일 복사 대화 상자를 취소하면 파일 관리자가 충돌 함”

나쁨 : "소프트웨어 충돌"

나쁨 : "브라우저가 내 웹 사이트에서 작동해야합니다"

구성 요소 : 소프트웨어의 어느 부분에 존재합니까?이 필드는 버그 보고서를 제출해야합니다. 각 구성 요소에 대한 설명을 보려면 "구성 요소"라는 단어를 클릭하십시오. 적절한 것으로 보이지 않으면“일반”구성 요소를 강조 표시하십시오.

OS : 운영 체제 (OS)는 무엇입니까? (예 : Linux, Windows XP, Mac OS X) 예 :“버그가 둘 이상의 운영 체제 유형에서 발생하는 것을 알고 있다면“모두”를 선택하십시오. OS가 목록에 없으면 기타를 선택하십시오.

설명 : 다음을 포함한 문제점 보고서의 세부 사항 :

- 개요 : 요약에 대한보다 자세한 설명입니다. 예를 들면 다음과 같습니다. "페이지를 드래그하면 NSGetFactory 기능에서 Mac 빌드가 충돌합니다".

- 빌드 ID :이 위치를 찾으려면 위치 표시 줄을 통해 "about :"페이지로 이동하거나 MozQA의 Nightly Tester Tools 확장 프로그램이 있으면 Tools | 야간 테스터 도구를 선택하고 빌드 ID의 출력이 포함 된 옵션을 선택하십시오. “Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv : 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3”.

- 추가 빌드 및 플랫폼 : 버그가 다른 플랫폼 (또는 해당되는 경우 브라우저)에서 발생하는지 여부 "Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv : 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2에서는 발생하지 않습니다".

재현 단계 : 버그를 유발하는 최소화되고 따라하기 쉬운 단계. 필요한 경우 특별한 설정 단계를 포함해야합니다. 이에 대한 좋은 예는 다음과 같습니다. 1) 웹 페이지를 봅니다. 기본 샘플 페이지 인 http://www.google.com/을 사용했습니다 . 2) 페이지를 드래그하여 선택하십시오. 특히, 마우스 버튼을 누른 상태에서 브라우저 컨텐츠 영역의 아무 지점에서나 브라우저 컨텐츠 영역의 맨 아래로 마우스 포인터를 아래쪽으로 끕니다.

실제 결과 : 위 단계를 수행 한 후 응용 프로그램이 수행 한 작업 예 : 응용 프로그램이 충돌했습니다.

예상 결과 : 응용 프로그램이 수행해야 할 작업은 버그가없는 것입니다. 예를 들면 다음과 같습니다. 창이 아래로 스크롤되어야합니다. 스크롤 된 내용을 선택해야합니다. 또는 최소한 응용 프로그램이 중단되어서는 안됩니다.

Simon Tatham이 효과적으로 버그를 신고하는 방법 이 있습니다 . 경험이 부족한 사용자가 이해하기 쉽도록 설명합니다. 그러나 단점은 꽤 많은 텍스트라는 것입니다. 사용자가 문제를보고하려고하지만 문제를 설명하지 못하면 일반적으로이 모든 것을 읽도록 설득 할 수 없습니다.

유용한 보고서를 기대하기 위해 이해하기 쉽고 질문에 쉽게 대답 할 수 있습니다.

예를 들어 "이 오류 이전의 마지막 작업은 무엇입니까?", "이 오류 직전에 시도 했습니까?"

"내 비디오 드라이버가 최신 상태가 아닙니다. 그래픽 라이브러리가 이전 그래픽 드라이버와 호환되지 않을 수 있습니다."와 같은 버그 보고서를 작성하는 사용자는 없습니다.

사용자 기반이 사용자가 작성한 소프트웨어에 문제가있는 최종 사용자라고 가정합니다 ....

유능한 소프트웨어 엔지니어 또는 테스팅 전문가가되는 것은 사용자의 일이 아니므로 기 대해서는 안됩니다. 귀하의 사용자는 소프트웨어가 "제대로 작동"할 것으로 기대하는 평균적인 사람들입니다. 그렇지 않은 경우,주의를 끌기 위해 자신이 생각하는 것을보고합니다. 변경할 수 없으며 시도해서는 안됩니다. 전문가가 만들 것으로 예상되는 종류의 보고서를 고집하려고 시도하면 버그 보고서가 손실되고 고객은 "그 소프트웨어에 문제가 있었지만 나를 도와주는 대신 모두 작성했습니다. 아무 의미가없고 나에게 가치가없는 쓸모없는 형태입니다. 실제로 작동하는 소프트웨어를 찾을 것입니다. "

즉, 그것은 그들의 일이 아닙니다 .....

좋은 버그 보고서를 원하면 전문가를 고용하여 버그를 찾으십시오. 소프트웨어 개발자로서 고객을 다루는 데 어려움을 겪을 수 없다면 가능한 사람을 고용하십시오.