As características não são iguais. O novo bug pode ter um motivo subjacente diferente, embora pareça ser o mesmo. Então, abra um novo bug e aponte para o antigo para ajudar o desenvolvedor.
Um bug foi aberto, corrigido, verificado e fechado. Um mês depois, ele apareceu novamente em uma versão subseqüente após várias iterações sem qualquer regressão.
Desde que as características do bug sejam as mesmas, você
As características não são iguais. O novo bug pode ter um motivo subjacente diferente, embora pareça ser o mesmo. Então, abra um novo bug e aponte para o antigo para ajudar o desenvolvedor.
Se foi verificado e fechado, e funcionou por um tempo, e depois apareceu novamente depois que algo foi alterado, então não é o mesmo bug. Pode se manifestar de maneira semelhante à do bug antigo, mas sua causa pode ser diferente. Então 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ê tenha liberado a correção para o bug anterior. Suas notas de lançamento documentarão que "Corrigir Bug XXX". Do ponto de vista do rastreamento de problemas e tornando as notas de versão mais claras, é preferível se referir ao novo bug "Corrigir Bug XXX + 1 (que era semelhante em causa e efeito ao Bug XXX)" em vez de dizer "Corrigir Bug XXX (de novo) "ou algo similar.
De um modo geral, abra um novo bug.
No entanto, se você puder fazer uma investigação primeiro, eu verificarei 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 um Get Latest após a correção original ser registrada), fizeram alterações e fizeram check-in sem fazer um diff . Má prática, claro, mas acontece "o tempo todo".
Examinar o histórico do (s) arquivo (s) onde o bug foi corrigido irá confirmar ou eliminar rapidamente isso como uma possibilidade.
Concordo com a sugestão dos pôsteres anteriores de abrir um novo bug, pois ele pode não ser a mesma causa raiz.
Minha recomendação adicional seria garantir que você esteja sempre adicionando testes de unidade e integração que cobrem o bug, para que, em versões futuras, você veja o problema imediatamente antes que ele seja enviado para seus clientes. Nada parece pior para um cliente, então ver o mesmo bug voltar.
Não é a melhor analogia - Só 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:
A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Most bugs arise from.....
Um bug é uma falha no código e tem 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 esteja causando os sintomas.
Meu entendimento é que você deve reabrir um bug quando tiver certeza de que um erro foi causado devido à mesma parte do código. Isso pode acontecer quando o código se comporta corretamente em todos os cenários de teste / casos de teste, mas não em um novo caso de teste ou caso de teste em que você não pensou anteriormente. Esse tipo de cenário pode não ser comum.
O outro cenário é que os mesmos sintomas são causados por novas falhas, isto é, novos erros em outras partes do mesmo código ou mesmo em outros sistemas que afetam esse código.
Então, a aposta mais segura é abrir um novo bug quando os mesmos sintomas ocorrerem. Se você ver que o mesmo código antigo é responsável pelo erro, feche o novo bug e reabra o bug antigo. Caso contrário, deixe o novo bug e vincule-o ao antigo.