Devo gravar um bug que descobri e corrigido?

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

Se for apenas olhado internamente pelos desenvolvedores, para saber o que precisa ser corrigido, então não se incomode. É apenas barulho nesse ponto.

Lista não exaustiva de motivos para fazer login de qualquer maneira:

• As notas de lançamento incluem informações sobre erros corrigidos (até um limite que esse bug atende) - especialmente se houver uma vulnerabilidade exposta por esse bug
• O gerenciamento deseja uma noção de "Tempo gasto na correção de erros" / "Contagem de erros detectados", etc.
• Os clientes podem ver o estado atual do bugtracker (para ver se seu problema é conhecido, etc.)
• Os testadores obtêm informações sobre uma alteração que eles devem testar.

Eu diria que isso depende do fato de o seu produto ter sido lançado com o bug ou não.

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

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

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

Também é útil se você fizer revisões de código, em que normalmente o código seria escrito para alguma tarefa e, em seguida, revisado. Nesse caso, é melhor ter essa correção de bugs isolada, o que pode exigir que você coloque algo em sua lista de tarefas e faça todo o trabalho.

Isso depende de vários fatores.

Tanto Pieter B como 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 para um registro em um rastreador de problemas.

Além disso, às vezes até as correções de bugs triviais não são tão triviais e inocentes quanto aparecem pela primeira vez. Se você agrupar silenciosamente uma correção desse tipo para a entrega de um problema não relacionado, e o bugfix posteriormente for problemático, isso tornará muito mais difícil rastrear, quanto mais isolar ou reverter.

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

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

A única razão óbvia que vejo é que o esforço para preencher o relatório de bug, comprometê-lo e fechá-lo é de magnitude maior do que o tempo para consertar o bug.

Neste caso, o problema não é que o erro seja tão fácil de consertar, mas que a documentação demore demais. Realmente não deveria. Para mim, a sobrecarga para criar um ingresso Jira está pressionando c , inserindo um breve resumo de 1 linha e pressionando Enter . A descrição não está sobrecarregada, pois posso recortar e colá-la na mensagem de confirmação, juntamente com o número do problema. No final, . c <Enter> e a questão está encerrada. Isso resume-se a 5 teclas pressionadas.

Eu não sei sobre você, mas isso é o suficiente para tornar uma política, mesmo em projetos pequenos, gravar todas as correções de erros 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 fonte. Você definitivamente quer suas correções de bugs lá, para aprender sobre possíveis desenvolvimentos, como um influxo cada vez maior de pequenas correções de bugs de 1 linha, o que poderia lhe fornecer algumas dicas sobre os problemas do processo ou o que quer que seja. Por exemplo, por que você tem que fazer pequenas correções de bugs com frequência (supondo que isso aconteça com frequência)? Pode ser que seus testes não sejam bons o suficiente? A correção de erro foi uma alteração de domínio ou um erro de código? Etc.

A regra que eu sigo é que se a seção em que você está trabalhando nunca foi lançada e nem sequer roda e nenhum usuário a viu, corrija cada pequeno bug que você vê rapidamente e siga em frente. Uma vez que o software tenha sido lançado e esteja em produção e algum usuário tenha visto, cada 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. Corrigindo bugs sem ter esses bugs revisados, eu poderia estar criando um bug em vez de consertá-lo. Coloque no relatório do bug as linhas que você alteraria para corrigir o bug e seu plano sobre 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 de corrigi-lo.

Sim .

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

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

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 perguntar a opinião de um colega ... e depois, em alguns casos, lamentar que você não o fez porque alguém está perguntando sobre isso e se você teve o relatório já você poderia apenas apontá-los para que
• basta criar o relatório

Criar o relatório é mais rápido e, se não for ... automatizá-lo.

Como automatizar isso? Supondo que o seu rastreador suporte 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 bug e fechá-lo como "implementado" imediatamente, com a revisão de confirmação associada ao rastreamento. / p>     

Eu vou concordar que todas as outras respostas oferecem boas regras práticas e vários até mesmo tocam neste ponto, no entanto eu acho que há apenas uma resposta realmente segura aqui.

Basta perguntar ao seu gerente . Bem, seu gerente ou, alternativamente, líder de projeto ou de scrum, etc., dependendo de como o 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 como se fosse uma conversação de corredor de um minuto: "Ei (chefe), se eu consertar um bug menor que leva apenas alguns minutos, vale a pena fazer um ingresso para isso ou devo apenas mencionar na minha mensagem de commit? " e você terá certeza. Toda a boa prática no mundo é inútil se esse método irritar sua equipe e seu gerente.