Um erro foi aberto, corrigido, verificado e fechado. Um mês depois, ele apareceu novamente em uma versão subsequente após várias iterações sem nenhuma regressão.
Desde que as características do bug sejam as mesmas, você reabriria o ID do bug existente ou abriria um novo com um link para o bug fechado?
Respostas:
Características não são iguais a causas. O novo bug pode ter um motivo subjacente diferente, embora pareça ser o mesmo. Portanto, abra um novo bug e aponte-o para o antigo para ajudar o desenvolvedor.
Se foi verificado e fechado, funcionou por um tempo e depois apareceu novamente depois que algo foi alterado, então não é o mesmo bug. Pode se manifestar da mesma forma que o bug antigo, mas sua causa pode muito bem ser diferente. Portanto, não é o mesmo bug. Então, eu abriria um novo, com um link para o bug fechado.
Abra um novo bug, sempre. Por quê? Suponha que ele seja idêntico ao bug anterior e você lançou a correção para o bug anterior. Suas notas de versão documentarão que "Corrigir bug XXX". Do ponto de vista do rastreamento de problemas e da clarificação das notas de versão, é preferível consultar o novo bug "Corrigir bug XXX + 1 (que era semelhante em causa e efeito ao Bug XXX)" em vez de "Corrigir bug XXX (novamente) "ou algo semelhante.
De um modo geral, abra um novo bug.
No entanto, se você puder fazer alguma investigação primeiro, eu verificaria seu histórico no código-fonte .
Se você trabalha em um ambiente de equipe, alguém pode ter um código antigo em seu sistema (ou seja, eles não fizeram o Get Latest após o check-in da correção original), fizeram alterações e fizeram o check-in sem fazer uma comparação. Má prática, claro, mas acontece "o tempo todo".
Examinar o histórico do (s) arquivo (s) em que o erro foi corrigido rapidamente confirmará ou eliminará isso como uma possibilidade.
all the time, não é o SCM que está quebrado, é a sua equipe de desenvolvimento ...
Concordo com a sugestão dos pôsteres anteriores de abrir um novo bug, pois ele pode não acabar sendo a mesma causa raiz.
Minha recomendação adicional seria garantir que você sempre adicionasse testes de unidade e integração que cobrem o bug, para que em versões futuras você consiga detectar o problema imediatamente antes que ele seja enviado aos seus clientes. Nada parece pior para um cliente do que ver o mesmo bug voltar.
Não é a melhor analogia - apenas porque os sintomas de duas pessoas são os mesmos, isso não significa que a doença / causa da doença seja a mesma.
Da wikipedia:
Um bug de software é um erro, falha, falha ou falha em um programa ou sistema de computador que faz com que produza um resultado incorreto ou inesperado ou se comporte de maneiras não intencionais. A maioria dos erros surgem de .....
Um bug é uma falha no código e apresenta sintomas / efeitos. Um bug não é o sintoma. Um bug é o erro no código. Só porque os sintomas são os mesmos, isso não significa necessariamente que a mesma falha está causando os sintomas.
Meu entendimento é que você deve reabrir um bug quando tiver certeza de que um bug foi causado devido ao mesmo pedaço de código. Isso pode acontecer quando o código se comporta corretamente em todos os cenários / casos de teste, mas não em um novo caso de teste ou caso de teste em que você não pensou antes. Esse tipo de cenário pode não ser comum.
O outro cenário é que os mesmos sintomas são causados por novas falhas, ou seja, novos erros em outras partes do mesmo código ou mesmo em outros sistemas que afetam esse código.
Portanto, a aposta mais segura é abrir um novo bug quando os mesmos sintomas ocorrerem. Se você perceber que o mesmo código antigo é responsável pelo bug, feche o novo bug e abra novamente o bug antigo. Caso contrário, deixe o novo bug permanecer e vincule-o ao antigo.