Como você aplica ou mantém a qualidade dos relatórios de bugs em seu rastreador de bugs?

Question

Relatórios de bugs de alta qualidade são essenciais para um rastreamento eficaz de bugs - em um mundo ideal, todos os relatórios de bugs conteriam informações essenciais, como qual versão do software ele afeta e uma descrição passo a passo sobre como reproduzir o bug.

Na realidade, porém, os bugs relatados podem variar muito em qualidade.Eles podem ser on-lines ("o recurso X não funciona, conserte!"), solicitações de recursos, PEBKACs ou ininteligíveis.

Como você aplica ou mantém a qualidade dos relatórios de bugs em seu rastreador de bugs para permanecer eficaz?

Answer 1

Concordo com Jon Limjap - seu pessoal de controle de qualidade deve ser competente o suficiente para postar relatórios de bugs apropriados, com o treinamento básico e as diretrizes corretas.No entanto, existem maneiras de impor e incentivar melhores relatórios de bugs:

• A maioria dos softwares de rastreamento de bugs tem uma maneira de marcar alguns campos do relatório de bugs como obrigatórios, de modo que o relator tenha que escolher o valor apropriado para criar o bug com sucesso.
• Geralmente existe a possibilidade de incluir um modelo básico para o relatório de bug, algo como

Cenário:

Resultados esperados:

Resultados reais:

Observações:

• Você pode (e deve) fornecer uma ferramenta de relatório de bugs que será executada na máquina problemática, reunirá as informações relevantes e compactará-as em um arquivo compactado (e talvez colocá-lo na área de trabalho).Você então instrui sua equipe a executá-lo sempre que encontrar um bug que deseja relatar e anexar o arquivo ao bug.Esta ferramenta deve ser fácil de usar (apenas executando um executável) para que eles anexem as informações de diagnóstico a qualquer bug sem ter que pensar se é relevante ou não.Essa ferramenta geralmente também é muito útil para os clientes.
• Por último mas não menos importante - “educação, educação, educação”.As pessoas aprendem melhor com a experiência - apenas certifique-se de que sempre que alguém abrir um bug sem as informações adequadas incluídas, a pessoa que lida com o bug vá conversar com quem abriu o bug e explique o que está faltando e por que isso é importante.

Estas são práticas que temos utilizado com bastante sucesso no meu local de trabalho atual e acredito que sejam bastante universais para se adaptarem à maioria dos ambientes de trabalho.

Answer 2

Eu costumava pensar que a qualidade do relatório de bug era equivalente.Eu ainda acho que sim...os bugs que relato contêm muito mais informações úteis do que aqueles inseridos pelo controle de qualidade ou pelas operações.No entanto, comecei a admirar o modelo do FogBugz.É extremamente simples inserir um bug.O simples fato de saber que há uma condição de erro é útil, mesmo que não haja muitas informações de apoio.Além disso, os usuários sentem que algo está sendo feito.

Answer 3

Escreva um tutorial bom, mas não muito longo, sobre como usar o rastreador e o que é necessário para cada campo.Faça um exemplo de referência de uso geral que outras pessoas possam usar se tiverem dúvidas.

Eu tenho uma cópia de referência para editar as páginas de manual do Docbook e, usando-a repetidamente, já sei de cor a maior parte da sintaxe.

Answer 4

Isso depende se você está falando de uma revisão de controle de qualidade fechada e de uma versão beta pública.

Se for uma versão beta pública, não é aconselhável permitir que os usuários editem diretamente sua lista de bugs.Alguém deve ser designado para agregar comentários e relatórios de usuários e discernir quais são bugs reais e quais são duplicados e quais fornecem algum tipo de pista sobre como replicá-los.

Se este, entretanto, for um item de bug postado por seu pessoal legítimo de controle de qualidade, você terá um problema de competência em relação aos seus funcionários.Diretrizes adequadas devem ser definidas sobre como relatar bugs, especialmente para esclarecer as etapas de replicação.

Answer 5

Pergunta difícil.Eu tentaria ver se o sistema tem alguma maneira de garantir que determinados campos necessários sejam inseridos, tentar fazer com que quaisquer bugs críticos apareçam em seus olhos de alguma forma (e-mail, rss) para que você possa atacar rapidamente, mas principalmente isso sua equipe conhece o padrão de qualidade e o cumpre, as diretrizes são publicadas e públicas, esse tipo de coisa.

Supondo que seja sua equipe:Se você puder ter uma determinada estrutura que seja usada sempre em um campo de comentários, do que é esperado quando for inserido, então isso também seria bom - melhor ainda se o seu software tiver um esboço de notas padrão onde você possa definir essa estrutura em um formulário em branco.

Até certo ponto, porém, cabe ao indivíduo, ele deve estar ciente de que isso faz parte dos padrões de comunicação, é esperado como um requisito do trabalho e que é responsável por todos os outros membros da equipe - porque outras pessoas deveriam ' Não estarei em posição de caçá-los para descobrir mais detalhes, caso isso possa ser evitado.

Especialmente porque o tempo de resposta para corrigir bugs em itens de menor prioridade pode levar algum tempo e as pessoas tendem a se esquecer dos detalhes.

Supondo que sejam usuários:Você não pode, em alto grau, mas eu tentaria - se possível, fazer perguntas de qualquer forma, de uma forma que as pessoas pudessem entender.

Não inteiramente sobre este tópico, mas de uma forma do tipo "como você faz as perguntas", esta postagem no blog 37 Signals - Texto do link

Mesmo que você precise de outro formulário para fazer as perguntas visíveis aos seus usuários, que apenas alimenta principalmente os dados para o programa de bugs, eu faria isso apenas para fazer as perguntas certas.

Qual produto?Qual versão (fotos mostrando como encontrá-la)?Seria útil incluir um despejo de tela, se eles pudessem abrir o programa e pressionar um botão para enviar um arquivo de log automaticamente, se isso os impedisse de realizar mais trabalhos, se perdesse suas alterações, etc.

Para os usuários, provavelmente é mais sobre como você faz as perguntas e informa que você precisa que certas perguntas sejam respondidas ou quais você acharia mais úteis, então provavelmente obteria respostas melhores.

Answer 6

Use algo como Voz do usuário para os usuários finais relatarem bugs e solicitações de recursos.As entradas do rastreador de bugs realmente deveriam ser internas - elas são muito técnicas para os usuários finais e também, IMHO, expõem muito o funcionamento interno.