¿Qué sucede con un informe de error si no se ha corregido?

Si un informe de error no se ha corregido, pasa por las siguientes etapas en su ciclo de vida:

• Abierto (Open): Se crea un informe de error y se entrega al equipo de desarrollo.
• Asignado (Assigned): Se asigna la tarea de corregir el error a un desarrollador o equipo específico.
• Rechazado (Rejected / Declined): El error puede ser rechazado por varias razones:
  • No es un error (Not a Bug): El comportamiento descrito es funcional esperado.
  • Duplicado (Duplicate): El error ya fue registrado anteriormente.
  • No se puede reproducir (Cannot Reproduce): No es posible reproducir el error con los pasos proporcionados.
  • No se corregirá (Will Not Fix): El error no será corregido por decisión de la dirección (bajo prioridad, alto riesgo de corrección, falta de recursos, etc.).
  • Se necesita más información (Need More Info): Se requiere información adicional para reproducir o entender el problema.
• Aplazado (Deferred / Postponed): La corrección del error se ha pospuesto para una versión o iteración posterior debido a prioridades más altas u falta de tiempo/recursos.
• Cerrado (Closed): En caso de rechazo o aplazamiento, el informe de error finalmente pasa a estado "Cerrado", pero sin corregir.

El destino final de un error no corregido depende de su estado y la decisión tomada:

• Si rechazado, el informe de error simplemente se archiva. Pueden añadirse comentarios justificativos.
• Si aplazado, puede ser reabierto en el futuro cuando exista la posibilidad de corregirlo, o cerrarse definitivamente si la decisión de no corregirlo se vuelve definitiva.

Es importante que en el sistema de gestión de errores exista un historial claro de cambios de estado y comentarios que expliquen las razones de cada transición.