적절한 버그 보고서를 제출하는 방법에 대해 회사의 나머지 부분을 교육하는 방법에 대한 팁과 조언을 얻고 싶습니다. 현재 다음과 같은 티켓을받습니다 :
누구나 가능한 많은 정보를 제출하도록 사용자를 안내하는 버그 제출 프로세스 / 양식이 있습니까?
답변:
우리 조직에서는 버그가 제출 될 때 다음 정보가 필요한 버그 템플릿을 사용합니다.
이것은 필요한 최소 정보입니다. 또한 해당 버그에 적합한 스크린 샷과 응용 프로그램 로그 파일을 요청합니다.
우리는 버그 리포터가 가능한 한 사용자 관점에서 버그를보고하도록 노력합니다. 따라서 버그의 중요도를보다 빠르게 평가할 수 있으므로 우선 순위를 지정할 수 있습니다.
실제로 버그를 제출하는 방법을 모르는 고객과 함께 일하면서, 고객에게 올바른 방법을 설명하는 데 성공하지 못했습니다. 그러나 어떤 사람들은 특히 똑같은 질문을 반복해서 반복하거나 안내하는 경우 그들이 잘못하고 있음을 알 수 있습니다.
예를 들면 다음과 같습니다.
버그 보고서 1 : 왼쪽 패널이 브라우저에 올바르게 표시되지 않습니다.
버그 보고서에 대한 답변 1 : 버그를 제출해 주셔서 감사합니다. 사용하신 브라우저의 이름과 버전 및 문제의 스크린 샷을 알려주시겠습니까? 감사합니다.
버그 보고서 2 : "주문 제출"페이지의 "제출"버튼 위로 마우스를 움직이면 아래 텍스트가 사라집니다.
버그 보고서 2에 대한 답변 : 버그를 제출해 주셔서 감사합니다. 사용하신 브라우저의 이름과 버전 및 문제의 스크린 샷을 알려주시겠습니까? 감사합니다.
...
버그 리포트 1024 : Firefox 4.0 Release Candidate를 사용할 때 홈페이지에 버그가 있다고 생각합니다. 측면 패널을 가리키면 색상이 검은 색으로 유지되는 반면 Firefox 3.6 및 Internet Explhorr 8에서는 색상이 진한 파란색으로 바뀝니다. 아래 스크린 샷을 참조하십시오.
반복적 인 일을하도록 요청 받았을 때 고객은 다음 번에 스스로 더 쉽게 할 수 있다는 것을 어느 정도 이해합니다.
요청을 복사하여 붙여 넣는 것이 매우 중요합니다. 매번 요청을 다르게 공식화하면 고객이 모든 유사한 버그에 대해 동일한 요청을하는 것을 더 오래 알 수 있습니다.
고객을 "교육"하는 데 많은 도움이되는 것이 있으면 자동 답변을 보내야합니다. 버그 제출을 위해 제품을 사용하는 경우 어려울 수 있지만 자체 버그 추적 시스템을 수행 한 경우 쉽지 않을 수 있습니다.
자동 응답은 더 강한 반복 느낌을주기 때문에 도움이되고 결정적인 동작은 응답이 동일하다는 것을 의미합니다. 당신이 인간에게 무언가를 요구하고 그녀가 그것을 거부하면, 당신은 일주일에 같은 것을 요청할 수 있습니다. 로봇이 무언가를 거부하면 몇 년 동안 같은 것을 반복해서 거부 할 가능성이 있습니다.
자동화 된 답변과 사람이 만든 답변을 쉽게 구분할 수 있습니다. 예 (수년 동안 알고 있고 고객과 매우 가까운 고객을 상대한다고 가정 해보십시오) :
인간의 반응
버그 보고서 256 : 안녕. 요구 사항의 변경으로 인해 어제 링크 수정을 요청했지만 링크의 절반은 여전히 동일합니다. 문제가 있습니까?
버그 리포트 256에 대한 답변 : 아, 죄송 합니다만, 귀하가 말하는 링크는 무엇입니까? 요구 사항의 영향을받는 열 페이지를 확인했는데 아무런 문제가 없습니다.
봇의 응답
버그 보고서 256 : 안녕. 요구 사항의 변경으로 인해 어제 링크 수정을 요청했지만 링크의 절반은 여전히 동일합니다. 문제가 있습니까?
버그 보고서 256에 대한 답변 : 다음과 같은 이유로 시스템에서 버그 보고서를 수락하지 않았습니다.
영향을받는 페이지의 URI가 지정되지 않았습니다.
불편을 드려 죄송합니다. 요청 된 정보를 제공하여 버그를 다시 제출할 수 있습니다.
다시 한 번 버그보고 시스템을 사용자 정의 할 수 있다면 몇 가지 지침과 힌트를 추가하는 것이 좋습니다.
사용자가 텍스트 영역을 채우고 "제출"을 클릭하는 대신 몇 가지 마법사를 만들거나 일반적인 상황에서 필수 필드로 양식을 작성하십시오.
예를 들어, 웹 사이트 프로젝트의 경우 다음 필드를 사용하여 "렌더링 문제"양식을 작성하십시오.
야.
조직 수준에서이 작업을 수행하는 것이 어려울 수 있지만 이와 같은 보고서를 제출 한 사람들과 함께 워크샵을 진행하는 것이 유용합니다. 당신은 그것들을 쌍으로 묶고 서로 버그 보고서를 '제출'하도록 요청합니다. 한 사람이 다른 사람에게 버그보고를 한 후, 버그보고를받은 사람에게 문제를 재현하도록 요청하십시오. 그들이 어떤 정보가 중요한지 확인하기 위해 세부 사항을 해결하게하십시오. 그들 사이의 역할 전환보다.
지침과 같은 것이 필요한 경우 다음과 같은 경험과 간단한 Google 검색 결과를 기반으로 문서를 만드십시오 .
때때로 당신은 단지 개별적으로 또는 세미나에서 사용자와 함께 앉아서 발권 시스템을 안내해야합니다. 그리고 사용자가 잘못된 티켓을 제출하면 전화를 걸어서 대화하고 물건을 채우는 방법을 설명하십시오.
우리는 지난 몇 년 동안 그런 노력을 기울였습니다. 물론, 일대일로 많은 시간을 보냈지 만 장기적으로는 티켓 제출에 능숙한 사용자 기반이 생겼습니다. 사용자 입장에서는 티켓이 좋을수록 버그 수정 및 기능 구현에 소요되는 시간이 더 빠르다는 것을 알았습니다.
또한 응용 프로그램에 자동 충돌보고를 추가하여 버그 추적을 시작할 수 있습니다. 사용자가보고하지 않은 충돌 버그 또는 퍼지 정보로보고되는 버그를 찾기 위해 충돌 보고서 데이터를 마이닝하는 것이 정말 유용 할 수 있습니다.
