Conseguir que os usuários escrevam relatórios de erros úteis e decentes

Alguém conhece uma boa maneira de fazer com que os usuários escrevam um relatório de erro semi-decente (leia-se: útil ) ?

Queríamos colocar algo que faria sentido para a maioria dos usuários (seja fácil de ler e entender), mas também fornecer informações úteis para os desenvolvedores.

Não funciona quando clico no botão azul! Ahhh, acabei de perder uma semana de trabalho ... faça funcionar.

não é muito útil, como é.

Comecei a corrigir uma lista, mas pensei em verificar com vocês, se já existe um método semelhante.

A maneira mais eficaz de fazer com que os usuários escrevam relatórios de erros decentes e úteis é

1. para permitir que eles vejam seus relatórios on-line ...
   ^{[Sistema] Obrigado por reportar, você pode encontrar o status da sua solicitação aqui: ...}
2. ... junto com a avaliação e os comentários do engenheiro designado ...
   ^{[Engenheiro] Pedido rejeitado, pois os seguintes detalhes estão ausentes: ...}
3. ... com uma opção para editar / melhorar o relatório.
   ^{[Usuário] Os detalhes solicitados foram adicionados, reavalie: ...}

Eu chegaria ao ponto de afirmar que é a única maneira eficaz.

Vamos ser sinceros, a habilidade de escrever relatórios de erros efetivamente vem apenas com a experiência. É preciso aprender a ganhar experiência. Aprender envolve praticar, obter feedback e melhorar.

Os relatórios de erros on-line editáveis ​​pelo usuário são a maneira mais eficiente de ensinar os usuários a melhorar .

• ^{As opções alternativas acima são 1) para organizar sessões de aprendizado presencial com os usuários (sim, claro, especialmente quando existem milhares deles espalhados pelo mundo). Ou 2) explique as coisas pelo telefone ("veja, se você pudesse ver a porcaria que escreveu na linha 225 ..."). O quê mais? Oh 3) por e-mail, com certeza "no e-mail que você nos enviou há dois meses, você mencionou ... não, não esse e-mail, você nos enviou cinco e-mails hoje, três deles com assunto Re: clique no botão azul , olhe o segundo, aquele com captura de tela de 10 Mb anexado a ele ... o quê? você não consegue encontrá-lo? "}

Na minha opinião, o mais importante é usar o bug para estabelecer um contato significativo com o usuário. Escrever e entender relatórios de erros é uma habilidade, e meu conselho seria tornar o mais fácil possível para o usuário fazer o primeiro contato e, em seguida, aumentar progressivamente seus comentários, com mais valor, conforme necessário.

Por exemplo, obtenha o email do usuário e forneça um campo de texto sem formatação com o seguinte texto para concluir:

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

Depois de receber o email, faça uma resposta automática para confirmar se eles enviaram o bug, você o recebeu e o acompanhamento do bug está correto.

Você pode considerar usar algumas idéias da Mozilla e da Sun sobre este tópico:

• Diretrizes para escrever bugs - artigo da Mozilla MDN
• Como escrever um bug adequado - artigo Mozilla QMO
• Como escrever um relatório útil de erros - artigo Sun SDN

Particularmente (na página Mozilla "Como escrever um bug adequado"):

Esboço geral de um relatório de bug

Resumo : como você descreveria o erro com menos de 60 caracteres? Ele deve identificar rápida e exclusivamente um relatório de erro, além de explicar o problema, não a solução sugerida.

Bom : “O cancelamento da caixa de diálogo Cópia de arquivo trava o Gerenciador de arquivos”

Ruim : "Falhas de software"

Ruim : “O navegador deve funcionar com meu site”

Componente : Em qual subparte do software ele existe? Este campo é um requisito para enviar qualquer relatório de bug. Clique na palavra "Componente" para ver uma descrição de cada componente. Se nenhum parecer apropriado, realce o componente "Geral".

SO : Em qual sistema operacional (SO) você o encontrou? (por exemplo, Linux, Windows XP, Mac OS X.) Exemplo: “Se você souber que o bug ocorre em mais de um tipo de sistema operacional, escolha“ Todos ”. Se o seu sistema operacional não estiver listado, escolha Outro ”.

Descrição : os detalhes do seu relatório de problemas, incluindo:

- Visão geral : esta é uma atualização detalhada mais detalhada do resumo. Um exemplo seria: “A seleção de arrastar qualquer página trava, compilada pelo Mac, na função NSGetFactory”.

- ID da compilação : para encontrar isso, vá para a página “about:” através da barra de localização ou, se você tiver a extensão Nightly Tester Tools do MozQA, vá para Tools | Ferramentas do Nightly Tester e selecione a opção que contém a saída do ID da compilação. Ele deve ter a seguinte aparência: "Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3".

- Construções e plataformas adicionais : se o bug ocorre ou não em outras plataformas (ou navegadores, se aplicável). Deve ter a seguinte aparência: "Não ocorre no Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; pt-BR; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2".

Etapas para reproduzir : Etapas minimizadas e fáceis de seguir que acionarão o bug. Se necessário, inclua etapas especiais de configuração. Um bom exemplo disso seria o seguinte: 1) Visualize qualquer página da web. (Usei a página de amostra padrão, http://www.google.com/ ). 2) Arraste e selecione a página. Especificamente, enquanto mantém pressionado o botão do mouse, arraste o ponteiro do mouse para baixo de qualquer ponto na região de conteúdo do navegador até a parte inferior da região de conteúdo do navegador.

Resultados reais : o que o aplicativo fez depois de executar as etapas acima. Um exemplo seria: O aplicativo travou.

Resultados esperados : o que o aplicativo deveria ter feito, caso o bug não estivesse presente. Um exemplo seria: A janela deve rolar para baixo. O conteúdo rolado deve ser selecionado. Ou, pelo menos, o aplicativo não deve falhar.

Há como relatar erros de maneira eficaz por Simon Tatham. Explica bem as coisas, facilitando o entendimento para usuários menos experientes. No entanto, a desvantagem é que é um pouco de texto. Quando você tem um usuário tentando relatar um problema, mas falhando em explicá-lo, geralmente não será capaz de convencê-lo a ler tudo isso.

Você pode pedir perguntas fáceis de entender e fáceis de responder aos usuários para que esperem relatórios úteis.

Por exemplo, "Qual foi sua última ação antes deste erro?", "Você tentou ... imediatamente antes deste erro?".

Nenhum usuário escreveria um relatório de erro como: "Meu driver de vídeo não está atualizado. Sua biblioteca de gráficos pode não ser compatível com drivers gráficos antigos".

Supondo que a base de usuários são usuários finais que tiveram um problema com o software que você escreveu ....

Não é tarefa do usuário se tornar um engenheiro de software ou um profissional de teste proficiente, e você não deve esperar que eles o façam. Seus usuários são pessoas comuns que esperam, com razão, que o software "apenas funcione". Quando isso não acontecer, eles reportarão tudo o que acharem necessário para chamar sua atenção. Você não pode mudar isso e não deve tentar. Qualquer tentativa de insistir no tipo de relatório que um profissional deve fazer resultará na perda do relatório de erro e no cliente - "Eu tive um problema com esse software, mas, em vez de me ajudar, eles devem preencher todos os tipos de formas inúteis que não significam nada e não têm valor para mim. Vou procurar algum software que realmente funcione. ".

ou seja, não é o trabalho deles ...

Se você deseja um bom relatório de erros, contrate profissionais para encontrar seus erros. Se você, como desenvolvedor de software, não pode se incomodar em lidar com clientes, contrate alguém que possa.