Devo registrar um bug que descobri e corrigi?

68

Suponho que essa seja uma situação comum: testei algum código, descobri um bug, corrigi-lo e cometo-o no repositório. Supondo que muitas pessoas trabalhem nesse projeto, devo primeiro criar um relatório de bug, atribuí-lo a mim mesmo e me referir a ele na mensagem de confirmação (por exemplo, "Corrigir bug #XYZ. O bug ocorreu devido a X e Y. Corrigido por Q e R ")? Como alternativa, posso pular o relatório de erros e confirmar com uma mensagem como "Corrigido um bug que causava A quando B. O bug era devido a X e Y. Corrigido por Q e R".

O que é considerado uma prática melhor?

David D
fonte
4
Depende do tamanho da sua empresa e equipe, e das características do bug. Em equipes pequenas e rápidas, isso simplesmente não é necessário, pois você pode se comunicar com seus colegas desenvolvedores apenas gritando com eles. Em grandes equipes, grandes organizações, ambiente de desenvolvimento distribuído, é bom registrar seu trabalho, mas também é uma sobrecarga que reduzirá seu nível de produção se você trabalhar em vários pequenos bugs. A menos que seja um bug sério, que é sempre bom ter documentado, testado em unidade para evitar regressão e fechado.
Machado
15
Não esqueça que alguns bugs não ficam corrigidos - eles reencarnam espontaneamente se você os ignorar por um tempo. Saber como alguém tentou corrigi-lo da última vez pode ser valioso. No mínimo, deve haver alguma documentação dizendo o que você fez com o código e por quê, mesmo que seja apenas nos comentários no código.
alephzero
5
Além dos comentários anteriores, também depende se o bug foi lançado na natureza, mas você teve a sorte de não ter clientes o encontrando ou se ele foi introduzido e corrigido dentro de um ciclo de lançamento.
Whatsisname
3
Em caso de dúvida, grite. Para mim, nunca é demais abrir e fechar um relatório de erro. Em algumas circunstâncias, é bom ter essas coisas documentadas e oficiais.
Phresnel # 21/16
11
Relacionado ao comentário de @ alephzero, algo que aconteceu comigo recentemente: a correção de um bug em uma parte do código revelou erros em outros lugares. Sem querer, eles se cancelaram na parte que eu não havia tocado, e o primeiro instinto do mantenedor foi desfazer minha correção.
Izkata

Respostas:

71

Depende de quem é o público de um relatório de erro.

Se ele for analisado apenas internamente pelos desenvolvedores, para saber o que precisa ser corrigido, não se preocupe. É apenas barulho nesse ponto.

Lista não exaustiva de razões para registrar de qualquer maneira:

  • As notas de versão incluem informações sobre bugs corrigidos (até um limite que esse bug atenda) - especialmente se houver uma vulnerabilidade exposta por esse bug
  • A gerência deseja uma noção de "Tempo gasto na correção de bugs" / "Número de bugs detectados" etc.
  • Os clientes podem ver o estado atual do rastreador de erros (para saber se o problema é conhecido, etc.)
  • Os testadores obtêm informações sobre uma alteração na qual devem testar.
Caleth
fonte
56
O local mais provável para a ocorrência de um bug é o local que ocorreu anteriormente. Eu recomendo gravá-lo em praticamente todos os cenários.
corsiKa
18
# 4: Os testadores usam o rastreador de erros para orientar seus testes. Eles vão testar se a correção funciona e se não causou novos erros ou regressões.
precisa saber é o seguinte
2
@corsiKa Quando o medicamento é pior que a doença? ;-)
hBy2Py 21/10
11
@ hBy2Py Encontre um novo médico e grave-o.
corsiKa
2
@BradThomas para reformular o que você citou: "O rastreador de erros é usado como uma lista TODO e nada mais" + "Bug corrigido" -> "sem TODO". Concordo em quase todas as outras situações, você quer um registro
Caleth
52

Eu diria que depende se o seu produto foi lançado com o bug ou não.

Se for lançado com o bug encontrado, crie um relatório de erros. Os ciclos de lançamento geralmente podem ser longos e você não deseja que seu bug seja relatado como um novo problema enquanto você já o corrigiu.

Se o seu bug ainda não foi enviado, não seguiria o mesmo caminho. Agora você terá pessoas tentando recriar seu bug, o que eles não podem, porque ele ainda não está em uma versão, essencialmente desperdiçando seu tempo.

Pieter B
fonte
2
Além disso, se você estiver verificando o código dos itens de trabalho, considere fazer o check-in da correção de bugs do item de trabalho original ao corrigir bugs que não foram lançados no lançamento do produto.
Wablab
24

Você deve fazer isso se for um bug que possa ter sido relatado por um cliente. Pior caso: você corrige o bug, mas ninguém sabe. O cliente relata o erro. Seu colega tenta corrigir o erro, mas não pode reproduzi-lo (porque você já o corrigiu). É por isso que você deseja um registro do bug.

Também é útil se você fizer revisões de código, onde normalmente o código seria escrito para alguma tarefa e depois revisado. Nesse caso, é melhor isolar esse bug, o que pode exigir colocar algo em sua lista de tarefas e depois fazer todo o trabalho.

gnasher729
fonte
9

Isso depende de vários fatores.

Tanto Pieter B quanto Caleth listam algumas em suas respostas:

  • O bug fez parte de um lançamento oficial?
  • O número de bugs / tempo gasto neles é rastreado especificamente?

Também pode haver procedimentos internos a serem seguidos, geralmente apoiados pelos requisitos de uma certificação. Para determinados certificados, é obrigatório que todas as alterações no código sejam rastreáveis ​​a um registro em um rastreador de problemas.

Além disso, às vezes até as correções de aparência trivial não são tão triviais e inocentes quanto parecem. Se você agrupar silenciosamente uma correção desse bug na entrega de um problema não relacionado, e a correção mais tarde se mostrar problemática, isso tornará muito mais difícil rastrear, muito menos isolar ou reverter.

Restabelecer Monica
fonte
2
É claro que você deve mencionar a correção de erro na mensagem de confirmação e, de preferência, fazer uma confirmação separada para a alteração que corrigiu o erro. (E talvez uma solicitação de recepção ou série de patches separada, se for uma alteração independente). A única exceção a isso seria se o bug fosse corrigido como um efeito colateral da alteração de algo por um motivo diferente (mas ainda o mencione na mensagem de confirmação). A única questão é se devemos nos preocupar com o rastreador de bugs, não se devemos juntar a mudança com outras coisas em um único commit!
22816 Peter Cordes
3

Esta pergunta só pode realmente ser respondida pelo líder do projeto ou por quem estiver encarregado do "processo de venda".

Mas deixe-me perguntar de outra maneira: por que você não registrou um bug que corrigiu?

A única razão fatomable que vejo é que o esforço para arquivar o relatório de erro, comprometê-lo e fechá-lo, é uma ordem de magnitude maior que o tempo para corrigi-lo.

Nesse caso, o problema não é que o bug seja tão fácil de corrigir, mas que a papelada demore muito. Realmente não deveria. Para mim, a sobrecarga para criar um ticket Jira é pressionada c, depois é inserido um breve resumo de uma linha e pressionado Enter. A descrição nem sequer é aérea, pois posso recortar e colar na mensagem de confirmação, junto com o número do problema. No final, . c <Enter>e o problema está encerrado. Isso se resume a 5 pressionamentos de tecla no alto.

Eu não sei sobre você, mas isso é pouco o suficiente para torná-lo uma política, mesmo em pequenos projetos, para registrar todas as correções dessa maneira.

O benefício é óbvio - existem muitas pessoas que podem trabalhar facilmente com um sistema de tickets como o Jira, mas não com o código-fonte; também há relatórios gerados a partir do sistema de tickets, mas não da origem. Você definitivamente deseja que suas correções de erros estejam lá, para aprender sobre possíveis desenvolvimentos, como um influxo cada vez maior de pequenas correções de uma linha, o que pode lhe fornecer uma visão sobre os problemas do processo ou o que seja. Por exemplo, por que você precisa fazer pequenas correções de erros com frequência (supondo que isso ocorra com frequência)? Pode ser que seus testes não sejam bons o suficiente? A correção de bug foi uma alteração de domínio ou um erro de código? Etc.

AnoE
fonte
2

A regra que sigo é que, se a seção em que você está trabalhando nunca foi lançada e ainda nem foi executada e nenhum usuário a viu, corrija todos os bugs que você vê rapidamente e siga em frente. Depois que o software é lançado e está em produção e algum usuário o vê, todo bug que você vê recebe um relatório de bug e é revisado.

Eu descobri que o que eu acho que é um bug é um recurso para outra pessoa. Ao corrigir bugs sem que eles sejam revisados, posso estar criando um bug em vez de corrigi-lo. Coloque no relatório de erros quais linhas você alteraria para corrigir o erro e seu plano de como ele deve ser corrigido.

Em resumo: se este módulo nunca esteve em produção, corrija todos os erros que você vê rapidamente e siga as especificações. Se o módulo já estiver em produção, relate cada bug como um relatório de bug a ser revisado antes da correção.

Russell Hankins
fonte
1

Sim .


Já existem algumas respostas que expõem situações nas quais vale a pena criar um relatório de erro. Algumas respostas E eles diferem.

A única resposta é que ninguém sabe. Pessoas diferentes, em momentos diferentes , terão opiniões diferentes sobre o assunto.

Então agora, ao encontrar um bug, você tem duas soluções:

  • pondere se vale a pena abrir um relatório de bug ou não, talvez peça a opinião de um colega ... e depois, em alguns casos, lamento que você não tenha feito isso porque alguém está perguntando sobre isso e se você já tinha o relatório, poderia basta apontá-los para isso
  • basta criar o relatório

A criação do relatório é mais rápida e, se não for ... automatize-o.


Como automatizá-lo? Supondo que seu rastreador suporta scripts, basta criar um script que você possa chamar e que usará a mensagem de confirmação (título e corpo) para enviar um relatório de erro e fechá-lo como "implementado" imediatamente, com a revisão de confirmação associada ao rastreamento.

Matthieu M.
fonte
0

Vou concordar que as outras respostas oferecem boas regras de ouro e várias até tocam nesse ponto, no entanto, acho que há apenas uma resposta realmente certa aqui.

Basta perguntar ao seu gerente . Bem, seu gerente ou, alternativamente, líder de projeto ou mestre de scrum, etc., dependendo de como seu grupo está estruturado.

Existem muitos sistemas diferentes de boas e más práticas, mas a única maneira de saber que você está fazendo a coisa certa para sua equipe é perguntar.

Algo parecido com uma conversa de um minuto no corredor faria: "Ei (chefe), se eu corrigir um bug menor que leva apenas alguns minutos, vale a pena fazer um ingresso para ele ou devo mencioná-lo na minha mensagem de confirmação? " e você saberá com certeza. Todas as boas práticas do mundo são inúteis se esse método irritar sua equipe e seu gerente.

Validade
fonte