Quais recursos são vitais para um bom software de rastreamento de bugs?

Quais recursos são vitais para um bom software de rastreamento de bugs e por que são importantes? O que, em particular, é necessário para você considerar esses recursos corretamente?

Simplicidade. Se for muito complicado ou muito longo para inserir ou classificar erros, ninguém vai querer usá-lo.

Integração com o SCM, para que qualquer correção possa ser rastreada até o código, e as alterações no código possam ser rastreadas para um problema. Isso exige vigilância para fazer o check-in apenas do código relacionado ao problema que está sendo promovido / verificado. ou seja, não "Adicionado recurso xyz e corrigidos erros aleatórios em 4 locais diferentes e um refator rápido do recurso zyx".

Outro bom recurso é o gerenciamento de fluxo de trabalho, para que o processo de negócios seja seguido com o código. Por exemplo, pode ter um caminho de fluxo de trabalho semelhante ao seguinte: Bug reportado -> Triaged for priority and validity -> atribuído a dev -> trabalhado -> atribuído ao controle de qualidade -> aprovado no teste -> marcado como fechado.

Propriedade forçada de bugs. Não deve ser possível ter um problema em aberto que não seja de responsabilidade de alguém. Fora isso, simples é melhor.

• Recursos de relatórios bons / rápidos. A gerência deseja acompanhar a tendência dos bugs.

• API para automação, notificação automatizada de email, integração com controle de origem, etc.

1. relatórios personalizados : capacidade de criar e salvar rapidamente consultas de tickets por todos os usuários e não apenas por administradores. todo mundo gosta da própria visão dos bugs. se isso for feito corretamente, não há necessidade de notificações, faça login na sua visualização favorita de 'tickets on my plate'
2. vincular ao controle de versão : deve ser fácil encontrar as alterações de código associadas a um ticket.
3. inteligência de fluxo : o sistema não deve permitir que os tickets cheguem aos estados em que eles caem nas falhas - portanto, se o status mudar para 'Rejeitado', deve impor a atribuição a alguém em desenvolvimento
4. personalizável : todo projeto é diferente, toda equipe é diferente. algumas equipes precisam de 8 status diferentes, outras apenas 3. mas a GUI deve permanecer
5. simples : mantenha os elementos principais do ticket grandes, diretos e simples. versão, título, descrição, status, proprietário
6. história : isso realmente se destaca quando é feito errado (estou olhando para você, Unfuddle); por isso deve ser apontado. o histórico de alterações no ticket precisa estar visível em um bom registro cronológico.

Eu acho muito importante poder vincular problemas (e especificar um tipo de link, por exemplo, Depende). Além dos suspeitos habituais da versão em que o bug foi encontrado, em qual versão pretendemos corrigi-lo (para que possamos orientar os roteiros), um campo de estimativa é bom para o planejamento do projeto / ágil.

É bom ter votos para o público, a capacidade de notificar os usuários sobre alterações no problema e ter um sistema bastante flexível de categorizar os problemas.

De fato, praticamente tudo o que o JIRA suporta fora da caixa :)

Qualquer recurso que executa uma tarefa para o programador. Não deveria realmente fazer parte do IDE? Há a lista de bugs. Escolha uma para trabalhar e todos os status e carimbos de hora serão atendidos. As alterações de código estão vinculadas. Testes necessários estão associados. Verifique como corrigido, atualize o status e informe a todos.

Habilidade para identificar semelhanças em tickets que já foram fechados.

Pode ser usado algoritmos de mineração de dados, talvez.

Consulta poderosa
O software de rastreamento de erros deve ajudar a gerenciar os projetos, aplicando rigoroso processo de desenvolvimento em cada estágio da resolução de problemas.