Un error fue abierto, corregido, verificado y cerrado. Un mes después, volvió a aparecer en una versión posterior después de varias iteraciones sin ninguna regresión.
Siempre que las características del error sean las mismas, ¿volvería a abrir el ID de error existente o abriría uno nuevo con un enlace al error cerrado?
Las características no son iguales a las causas. El nuevo error podría tener un motivo subyacente diferente, aunque parezca ser el mismo. Por lo tanto, abra un nuevo error y apúntelo al anterior para ayudar al desarrollador.
Si se verificó y cerró, funcionó por un tiempo y luego apareció nuevamente después de que se cambió algo, entonces no es el mismo error. Puede manifestarse de manera similar a como lo hizo el viejo error, pero su causa puede ser diferente. Así que no es el mismo error. Así que abriría uno nuevo, con un enlace al error cerrado.
Abre un nuevo error, siempre. ¿Por qué? Supongamos que resulta ser idéntico al error anterior, y ha liberado la solución para el error anterior. Sus notas de lanzamiento documentarán que "Solucione el error XXX". Desde el punto de vista del seguimiento de problemas y de hacer que las notas de publicación sean más claras, es preferible referirse al nuevo error "Solucionar el error XXX + 1 (que fue similar en causa y efecto al Error XXX)" en lugar de decir "Solucionar el error XXX (De nuevo) "o algo similar.
En términos generales, abre un nuevo error.
Sin embargo, si se le permite hacer una investigación primero, verificará su historial en el código fuente .
Si trabaja en un entorno de equipo, es posible que alguien tenga un código antiguo en su sistema (es decir, que no haya realizado un Get Latest después de que se haya registrado la revisión original), haya realizado cambios y luego se haya registrado sin hacer una diferencia . Mala práctica, claro, pero sucede "todo el tiempo".
Mirar el historial de los archivos donde se solucionó el error lo confirmará o eliminará rápidamente como una posibilidad.
Estoy de acuerdo con la sugerencia de los carteles anteriores de abrir un nuevo error, ya que puede que no sea la misma causa raíz.
Mi recomendación adicional sería asegurarse de que siempre esté agregando pruebas de unidad e integración que cubran el error, de modo que en futuras versiones detecte el problema de inmediato antes de que llegue a sus clientes. Nada se ve peor para un cliente que ver el mismo error volver.
No es la mejor analogía: solo porque los síntomas de dos personas son los mismos, no significa que la enfermedad / causa de la enfermedad sea la misma.
De wikipedia:
Un error de software es un error, falla, falla o falla en una computadora Programa o sistema que hace que se produzca una incorrecta o inesperada resultado, o comportarse de manera involuntaria. La mayoría de los errores surgen de .....
Un error es una falla en el código y tiene síntomas / efectos. Un error no es el síntoma. Un error es el error en el código. El hecho de que los síntomas sean los mismos no significa necesariamente que la misma falla esté causando los síntomas.
Entiendo que debe volver a abrir un error cuando esté seguro de que se debe a un error debido a la misma pieza de código. Esto puede suceder cuando el código se comporta correctamente en todos los escenarios de prueba / casos de prueba, pero no en un nuevo caso de prueba o caso de prueba en el que no haya pensado antes. Este tipo de escenario podría no ser común.
El otro escenario es que los mismos síntomas son causados por nuevas fallas, es decir, nuevos errores en otras partes del mismo código o incluso en otros sistemas que afectan a ese código.
Entonces, la apuesta más segura es abrir un nuevo error cuando ocurren los mismos síntomas. Si ve que el mismo código antiguo es responsable del error, cierre el nuevo error y vuelva a abrir el antiguo. Si no, deja que el nuevo error permanezca y vincúlalo al anterior.
Lea otras preguntas en las etiquetas project-management issue-tracking agile