Devo registrar um bug que descobri e corrigi?

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?

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.

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.

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.

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.

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.

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.

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.

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.