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

8

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?

issue-tracking

— Casebash
fonte

19

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

— Guillaume
fonte

Você tem exemplos do que você considera muito complexo?

— Casebash 5/10

O produto mais recente que tive que usar: Mantis. Muitas etapas necessárias para editar e reatribuir ou fechar um ticket. Isenção de responsabilidade: a versão em uso não era atualizada há muito tempo. Talvez as coisas tenham melhorado desde então.

— Guillaume

Bem, eu usei o Mantis extensivamente, e nossa versão (também bastante antiga) levou dois cliques para reatribuir um bug e três cliques para fechar (além de inserir um motivo). Então, eu realmente não posso reclamar.

— S1 # s01e1

@Casebash - Bugzilla é muito complexo.

— mouviciel 14/09/11

4

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.

— Hugo
fonte

2

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.

— Dan Dyer
fonte

1

Rastrear itens pode de fato não ser responsabilidade de ninguém.

— David Thornley

Como você vê isso funcionando? Poderia haver um intervalo de tempo antes de ser atribuído? Ou haveria alguma maneira de determinar quem está disponível?

— JeffO

Quando um bug é criado, ele é atribuído à pessoa padrão que decide o que fazer com ele (pode ser o líder do projeto ou o gerente do projeto).

— Dan Dyer

Isso depende do seu processo. Se, por exemplo, os erros são triados na chegada e depois colocados em uma lista de pendências priorizada, não há necessidade de um proprietário. De fato, ter um proprietário parece-me um pouco conflitante com a idéia de uma equipe multifuncional e pode introduzir um gargalo artificial.

— sleske

2

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.

— grokus
fonte

2

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'
vincular ao controle de versão : deve ser fácil encontrar as alterações de código associadas a um ticket.
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
personalizável : todo projeto é diferente, toda equipe é diferente. algumas equipes precisam de 8 status diferentes, outras apenas 3. mas a GUI deve permanecer
simples : mantenha os elementos principais do ticket grandes, diretos e simples. versão, título, descrição, status, proprietário
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.

— Alex Fairchild
fonte

1

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 :)

— Martijn Verburg
fonte

0

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.

— JeffO
fonte

2

Pode fazer parte do IDE, mas também deve ter uma parte que possa ser acessada sem o IDE, pois pode haver outras pessoas envolvidas no projeto que não usem o IDE.

— Victor Hurdugaci

@ Victor Hurdagaci - bom ponto. Ele precisa ser acessível a todos que precisam dele de forma apropriada.

— JeffO

0

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

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

— Pagotti
fonte

0

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.

— Catherine Sea
fonte

1

Esta resposta pode ser mais útil se você fornecer mais detalhes. Consulte também as Perguntas frequentes em programmers.stackexchange.com/faq para obter conselhos sobre a melhor forma de responder a perguntas com pouco, não muita informação.

— DeveloperDon