Classificação de bug / defeito de software [closed]

4

Estamos tentando criar termos que descrevam melhor nossos bugs / defeitos. Para nós, o termo 'bug' ou 'defeito' é muito genérico e não reflete com precisão o que está acontecendo. Por exemplo, em vez de dizer que existe um bug (no sentido geral), preferimos dizer que tipo de erro (um erro, melhoria ou melhoria, etc.). Quais nomes você usa para descrever 'bugs'?

Encontramos o link que tem algumas boas classificações. Como você os classifica?

    
por Dustin Kendall 16.02.2011 / 02:30
fonte

7 respostas

15

Nós os classificamos como

  • solicitação de alteração (pequenas melhorias, mudança de comportamento)
  • design-change-request (grandes recursos que exigem um documento de design)
  • sw-bug (bug de software devido a erro do programador)
  • test-bug (não é realmente um bug de software, erro do testador em seu script)
  • solicitação de suporte (solicitação de informações / esclarecimentos, geralmente do campo)
  • inválido (o problema relatado não existe ou é o comportamento esperado)
  • duplicada (o mesmo problema já foi relatado)
  • doc-bug (erro de documentação, documentação precisa ser atualizada com o comportamento correto) (Obrigado ao Michael por apontar este)
por 16.02.2011 / 05:46
fonte
12

Ao projetar a classificação para nosso bugtracker, eu tentei estar muito consciente do propósito de cada campo. Aqui está o que acabamos com.

Quando vamos trabalhar nisso?

Este campo registra os resultados do nosso planejamento. É muito útil pesquisar e filtrar: quando um desenvolvedor está sem tarefas (tudo que é atribuído a ele é feito ou seu trabalho é bloqueado por qualquer motivo) ele pode simplesmente pegar um problema da lista de todos os erros não atribuídos classificados por "Quando ":

Nósfrequentementemovemosproblemasentre"Now" e "Next" e revisamos as tarefas "Soon" de tempos em tempos e depois de um lançamento. Ocasionalmente, passamos pelas tarefas "Mais tarde". "Se alguma vez" é o campo que usamos em vez de fechar os pedidos, não temos certeza de que iremos trabalhar.

Quanto tempo isso vai demorar para corrigir?

Este campo é a melhor estimativa de quanto tempo o trabalho pode levar. É notoriamente difícil ter uma ideia disso, mas, devido à escala logarítmica e à rugosidade de ordem de grandeza, raramente estamos fora de mais de uma entrada nesta lista:

Estecampoéusadoemváriascircunstâncias.Emprimeirolugar,éumaconsideraçãoimportantesobreoqueentranocampo"Quando" discutido acima. Eu gosto de usar este campo para escolher uma tarefa muito curta para começar em uma segunda-feira, se eu não estiver me sentindo muito motivado. Também é útil encontrar trabalho para um novo funcionário ou outra pessoa que não esteja motivada.

Qual a importância desta tarefa, no grande esquema das coisas?

Este campo é para quem faz o planejamento do projeto; os desenvolvedores não se importam. Isso ajuda a registrar o quanto achamos que esse trabalho é importante para o sucesso do nosso projeto:

Eleéusadojuntocom"Quanto tempo isso vai demorar" para decidir quando vamos trabalhar nessa tarefa.

Qual é o estado do bug?

Este campo é usado para fluxo de trabalho. Cada estado mostrado abaixo é um estado "aberto" ou "fechado". O bugtracker tem atalhos para mostrar apenas bugs abertos, e esse é o principal uso para este campo.

Asubdivisãoemaberto/fechadoéoobjetivoprincipaldestecampo,noentanto,cadaentradaindividual"fechada" atua para resumir o resultado. Isso pode frequentemente ser inferido de comentários também, mas ajuda a ter um local padrão onde esta informação possa ser encontrada.

Existe uma regra reforçada pelo bugtracker de que um bug duplicado deve ter pelo menos um link para dizer qual é o duplicado do bug.

Somos bastante explícitos sobre não usar um estado "em andamento" porque, devido à experiência passada, é muito difícil mantê-lo adequadamente atualizado e, como resultado, o estado pode fazer mais mal do que bem.

Sobre o que é esse bug?

Este é o mais próximo do campo "tipo de bug" convencional. Seu objetivo principal é descrever a entrada para um humano . Quase nunca procuramos ou filtramos neste campo. Ele está lá apenas para salvar palavras no título do bug. A lista varia um pouco de projeto para projeto, mas aqui está um exemplo representativo:

Camposvazios

Escolherumvalorparatodosositensacimanemsempreéfácil,porissopermitimosqueapessoaqueentranobugdeixevaziostodososcamposqueelesnãoconseguiramdescobriragora.Mantemosaatitudedequeissoestáperfeitamentebem,mesmoquevocêestejaapenascompreguiça,porque,docontrário,podemosacabarcomolixoneles.

Oscampos"Quando" e "Importância" geralmente são deixados em branco porque essas coisas são para o planejador do projeto decidir. Entradas com "Muito trabalho" em branco são revisadas de tempos em tempos, com possíveis responsáveis solicitados a estimar.

Específico do projeto

Embora projetos grandes usem todos os itens acima, alguns projetos pequenos acabam com menos. Se eles não tiverem utilidade para "Importância", insistimos que o campo seja excluído desse projeto. A ideia é que apenas os campos que estão sendo usados ativamente estejam presentes.

P.S. As capturas de tela acima são do YouTrack, o que eu realmente prefiro. Não teve nenhum problema com a gente se livrar de todos os campos internos e usar o nosso próprio.

    
por 08.10.2012 / 12:36
fonte
2

A seção "Teste de desenvolvedor" do Code Complete classifica os defeitos como:

  • Estrutural
  • Dados
  • Funcionalidade conforme implementada
  • Construção
  • Integração
  • Requisitos funcionais
  • Definição de teste ou execução
  • Sistema, arquitetura de software
  • Não especificado

(isto é originalmente de um estudo de 1990 da Beizer)

É claro que a classe do defeito só pode ser evidente com uma retrospectiva de ser corrigido!

Este esquema de classificação mantém o tipo de defeito distinto da sua gravidade (grave - > insignificante) e prioridade (eu preciso dele ontem - > sonho de cano).

Além disso, isso pressupõe que o tíquete já tenha sido classificado como DEFECT , em vez de ENHANCEMENT ou TASK (que são tipos muito comuns de tickets).

    
por 08.10.2012 / 00:01
fonte
2

Algo como classificação ortogonal de defeitos pode ser útil. A ideia é ter uma série de opções de tal forma que cada uma tenha apenas um único valor possível que faça sentido para toda e qualquer submissão. A IBM Research tem algumas páginas dedicadas ao conceito.

No que diz respeito a tipos de defeitos, a única coisa que eu realmente quero saber é se é um defeito ou se é um aprimoramento. Existe um defeito em um produto de trabalho que não está em conformidade com o artefato que o gerou. Por exemplo, um requisito que não capta adequadamente a intenção do stakeholder está com defeito. Da mesma forma, um design que não trata de um requisito ou de uma implementação que não realiza um design ou um requisito está com defeito. Uma solicitação de melhoria ou alteração seria uma modificação em um artefato que, de outra forma, atende aos requisitos especificados. Este poderia ser um novo requisito ou uma refatoração para reduzir a dívida técnica, como exemplos.

Acredito que qualquer esquema de classificação abrangente abordaria as seguintes questões. O que você realmente precisa capturar varia com base em como você está usando os dados - usar dados de defeitos para rastrear as tarefas precisa ser menos completo do que os dados de defeitos que são inseridos em um programa de métricas rigorosas.

  • Isso é um problema em um produto de trabalho existente ou um aprimoramento em um produto de trabalho? Qualquer item, seja um requisito, um documento ou um módulo de código, não está em conformidade com as especificações ou com as especificações quais os produtos de trabalho são baseados devem ser aprimorados.
  • Qual produto de trabalho é afetado? Isso afeta um documento (e qual)? É contra o código? Testes unitários? Dependendo do seu processo de liberação, ele também pode abordar quais versões são afetadas por esse defeito ou aprimoramento como um elemento de dados adicional.
  • Qual é a prioridade e / ou gravidade deste defeito? A prioridade é geralmente um elemento definido pelo cliente ou pelo usuário que aborda a rapidez com que eles precisam de algum tipo de resolução. Defeitos de maior prioridade precisam ser tratados primeiro. Observe que "endereçado" pode significar simplesmente analisar e desenvolver uma solução alternativa até que um defeito possa ser adequadamente resolvido. Gravidade normalmente define como o trabalho é afetado - baixa gravidade significa que ele tem um impacto mínimo no valor de negócios, enquanto uma severidade maior significa que os usuários estão tendo extrema dificuldade em realizar seus objetivos de negócios por causa do defeito.
  • Quando o defeito foi relatado? Quando foi finalmente resolvido? Isso pode ser usado para rastrear dados de tempo para fechamento, que podem estar relacionados a métricas de satisfação do cliente.
  • Onde o defeito foi encontrado e onde foi originalmente injetado? Isso só é necessário se você estiver capturando métricas de contenção de defeitos, como contenção total de defeitos (o número de defeitos encontrados / corrigidos em casa versus pós -release) ou eficácia de contenção de fase. Eu prefiro um conceito baseado em atividades (algo nos moldes de requisitos, arquitetura / design, implementação, teste, campo), negligenciando iterações, para que eu possa determinar quais atividades estão associadas a processos que são proficientes na captura de defeitos e onde preciso para melhorar meus processos.
  • O que causou a existência deste defeito ou a sua injeção? Como você define isso depende da sua organização, mas o PSP dá um bom ponto de partida . Você não quer nada tão complicado que não possa ser entendido, e de acordo com a Classificação Ortogonal de Defeitos, não queremos que os defeitos possam ser colocados em várias categorias.
  • Como posso identificar e referir-me a esse defeito? Normalmente, um identificador único e um título curto, legível por humanos, fornecem essas informações. Eles podem ser usados para fornecer informações a clientes / usuários sobre trabalhos em andamento e relatórios de status ou logs de confirmação para ajudar a rastrear defeitos no fechamento.

A maioria deles, exceto o motivo de existir, se aplica igualmente a defeitos e aprimoramentos.

    
por 08.10.2012 / 00:47
fonte
1

Antes de você tentar reinventar a roda (ou o idioma inglês), a ênfase não deve estar na descrição do erro?

'Bug' = não é bom / não desejado / erro / erro

Sim, é genérico, mas você não ganha nada inventando novas palavras para descrever algo ruim.

    
por 16.02.2011 / 04:31
fonte
1

Eu não diria que um aprimoramento ou uma melhoria seja um bug.

Geralmente, classifico problemas em um rastreador de problemas da seguinte forma:

  • Bug - Um problema no código que leva à saída inesperada.
  • Suporte - algo que precisa ser feito antes que outras questões possam ser analisadas. ie. Um bug que o gerador CSV está gerando erros é porque ainda não existe um gerador CSV adequado. Suporte - escreva um gerador CSV.
  • Recurso - um aprimoramento ou melhoria que gostaria de fazer. Pode ser grande ou pequeno.
  • Wish - Um recurso real do tipo "olho no céu" que provavelmente nunca verá a luz do dia - "Não seria ótimo se o software pudesse ler sua mente e direcioná-lo para o que você estava procurando automaticamente?" ! '
  • Todo - Algo que requer investigação / escopo antes que possa ser devidamente detalhado / classificado.

Prioridade é geralmente uma questão completamente diferente. Os erros podem ser de baixa prioridade a imediatos, mesmo com recursos, desejos e todos geralmente são sempre baixos.

    
por 16.02.2011 / 06:20
fonte
0

classifico-os como:

  • aberto
  • corrigido
  • pode reproduzir, ainda não foi corrigido
  • incapaz de reproduzir
  • aprimoramento / não bug
  • recurso / intencional

Classificações mais granulares podem ser úteis como um estudo empírico na taxonomia de erros ou para análises estatísticas de algum tipo, mas para fins práticos, só importa se eles são fixos ou não, podem ser reproduzidos ou não, ou são realmente bugs ou não.

Mais do que isso, e eu suspeito que você esteja brincando com a comida em vez de comê-la.

    
por 16.02.2011 / 15:44
fonte