Se abrió, corrigió, verificó y cerró un error. Un mes después, apareció nuevamente 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?
Respuestas:
Las características no son iguales a las causas. El nuevo error podría tener una razón subyacente diferente, aunque parezca ser el mismo. Entonces, abra un nuevo error y apúntelo al anterior para ayudar al desarrollador.
Si se verificó y cerró, y funcionó durante un tiempo, y luego apareció de nuevo después de que algo cambió, entonces no es el mismo error. Puede manifestarse de manera similar al error anterior, pero su causa bien puede ser diferente. Entonces no es el mismo error. Entonces 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 lanzado la solución para el error anterior. Sus notas de la versión documentarán que "Fix Bug XXX". Desde el punto de vista del seguimiento de problemas y de aclarar las notas de la versión, es preferible consultar el nuevo error "Fix Bug XXX + 1 (que era similar en causa y efecto al Bug XXX)" en lugar de decir "Fix Bug XXX (otra vez) "o algo similar.
En términos generales, abra un nuevo error.
Sin embargo, si se le permite investigar primero, verificaría su historial en el código fuente .
Si trabaja en un entorno de equipo, alguien puede tener un código antiguo en su sistema (es decir, no realizó un Get Latest después de que se revisó la corrección original), realizó cambios y luego se registró 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.
all the time, no es el SCM el que está roto, es tu equipo de desarrollo ...
Estoy de acuerdo con la sugerencia de los pósters anteriores de abrir un nuevo error, ya que puede no ser la misma causa raíz.
Mi recomendación adicional sería asegurarme de que siempre esté agregando pruebas de unidad e integración que cubran el error para que en futuras versiones detecte el problema de inmediato antes de que se lo comunique a sus clientes. Nada le parece peor a un cliente que ver el mismo error volver.
No es la mejor analogía: el hecho de que los síntomas de dos personas sean 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 un programa o sistema de computadora que hace que produzca un resultado incorrecto o inesperado, o que se comporte de manera no intencionada. 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 el mismo defecto esté causando los síntomas.
Según tengo entendido, debe volver a abrir un error cuando sepa con certeza que un error se debe al mismo 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 pensó anteriormente. 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 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 anterior es responsable del error, cierre el nuevo error y vuelva a abrir el error anterior. De lo contrario, deje que el nuevo error permanezca y vincúlelo con el anterior.