Pasos para mantener una buena base de datos de errores

Mantener una base de datos de errores es importante para cada proyecto. Estoy acostumbrado a almacenar lo siguiente en la base de datos de errores

• Fecha de emisión hora
• A quién está asignado
• Si se ha resuelto o no
• Si se resuelve entonces, fecha y hora resueltas

¿Son suficientes para mantener una buena base de datos de errores?

Una buena base de datos de errores puede tener los siguientes

// Fecha Hora Relacionado

• Fecha de emisión hora del error
• Fecha prevista de arreglo / resolución
• Si se resuelve entonces, fecha y hora resueltas

// Asignado por + a

• Asignado por (detectado por)
• Asignado a

// Comportamiento de errores

• Comportamiento observado (con errores)
• Captura de pantalla (es posible)
• Complete los pasos para reproducir el error
• Comportamiento esperado

// Prioridad

• Prioridad del error

// Enlace, estado y otros

• Enlace de errores relacionados
• Estado del error
• Si se ha resuelto o no
• Si se resuelve entonces, ¿cómo se resuelve con una explicación?

EDITAR: también quiero recomendar

• ¿En qué revisión / rama se descubrió el error?
• ¿En qué revisión / rama se ha solucionado el error?

EDITAR: Me gusta el comentario de @ jgauffin

• No arreglará, no es un error, duplicado, resuelto

EDITAR: Un buen sistema de base de datos de errores también mantiene

• Matriz de asignación de responsabilidad

Es posible que haya varios campos personalizados que deba registrar, según las necesidades del proyecto. Se me ocurrió la siguiente lista que es posible que deba considerar también:

• Emisión DateTimede error / defecto
• Descripción del error: pasos para volver a crear.
• Entorno donde se encontró (Dev, QA, QC, Staging, Prod)
• Captura de pantalla del problema
• Quién lo registró (detectado por)
• A quién se le asigna (asignado por)
• Severidad del insecto (bajo, medio, alto)
• Resolución esperada DateTime
• Triaje estatal (propuesto, en progreso, resuelto, cerrado)
• Error cerrado DateTime: cuando un error se resuelve y se cierra
• Asignado para ser probado (probado por)

Editar: La mayoría de la información común que tiene valor para ser rastreado está bien descrita en softwares como Bugzilla . Bugzilla es un rastreador de errores de uso general basado en la Web y herramienta de prueba desarrollada y utilizada originalmente por el proyecto Mozilla, y licenciada bajo la Licencia Pública de Mozilla, y es GRATUITA . Recomiendo encarecidamente que los tome como ejemplo principal y lo extienda a las necesidades de su proyecto.

La mayoría de los campos útiles parecen haber sido cubiertos por otras respuestas, pero algunos que encuentro útiles son:

• ¿En qué revisión / rama se descubrió el error?
• ¿En qué revisión / rama se ha solucionado?

Esto es un poco más específico que en qué fecha / hora se descubrió / solucionó el error.

Si su software se ejecuta en varias plataformas (SO o hardware), es posible que también desee un campo que enumere las plataformas donde se produce el error.

Pero hay más para mantener una base de datos de errores que los campos que debe contener. También debe considerar cómo usa la base.

Intente mantener el número de errores abiertos / no resueltos lo más bajo posible. Esto puede parecer obvio, pero puede ser más difícil de lo esperado, al menos para proyectos más grandes. A menudo veo personas demasiado temerosas para cerrar problemas que no son reproducibles o que el remitente original del problema nunca proporciona información faltante. Además, los errores que han estado presentes por siempre y que se vieron por última vez en versiones antiguas del software no deberían dejarse ahí. Esto hace que la base de datos crezca con problemas que pueden o no ser problemas reales, y ralentiza el desarrollo.

A menudo necesitaría ver el historial de un error _ puede resolverse, luego reabrirse, luego resolverse nuevamente, etc. Por lo tanto, además de lo que ya se sugirió, le aconsejaría que tenga una tabla separada para realizar un seguimiento del historial de un error cada vez que se (re) abre. La tabla estaría en una relación de muchos a uno con la tabla de errores y probablemente tendría campos como:

• Fecha de apertura
• Abierto por
• Fecha resuelta
• Resuelto por
• Tiempo usado
• ¿Cómo se resolvió?
• etc.

También puede necesitar una tabla similar para rastrear a quién y cuándo se asignó (re) el error, especialmente si trabaja en un gran equipo.

También le sugiero que eche un vistazo a los sistemas existentes. En mi humilde opinión, Jira es uno de los mejores sistemas de seguimiento de problemas. Tiene características muy ricas, y podría usar algunas de ellas como guía para su propio sistema.

El proceso de seguimiento de errores es tan importante como los datos. Intenta pensar en lo siguiente también:

• ¿Cómo informan los usuarios del error?
• ¿Quién ingresa el error en el repositorio?
• ¿Quién puede confirmar que existe el error?
• ¿Quién puede confirmar que se solucionó el error?
• ¿Quién informa al usuario final que el error está resuelto?

Cree una tabla RACI para que todos los miembros de su equipo (incluidos los usuarios finales conozcan sus responsabilidades. Combine esto con las técnicas de ingreso de datos adecuadas y verá mucho más valor con el pequeño esfuerzo adicional).