Sistema de seguimiento de errores

Uno de los componentes principales de un sistema de seguimiento de errores es la base de datos donde se almacenan los hechos e historia de un fallo de software. Los hechos pueden ser una descripción detallada del fallo, la severidad del evento, forma de reproducirlo y los programadores que intervienen en su solución así como información relacionada al proceso de administración de la corrección del fallo como puede ser personal asignado, fecha probable de remedio y código que corrige el problema.

La mayor parte de los sistemas de seguimiento de errores identifican un ciclo de vida al cual se le da seguimiento mediante el estado del problema desde su descubrimiento y reporte hasta su solución final. De la misma manera, son regularmente configurables para permitir que diferentes personas consulten o editen diferentes aspectos del reporte, así como permitir a los administradores clasificar los diferentes estados del problema.

No todos los grupos de desarrollo de software están de acuerdo en la clasificación o gradación de la severidad y prioridad de un problema de software. Bugzilla y GNOME proponen la siguiente clasificación de severidad:

• Bloqueador: Inhibe la continuidad de desarrollo o pruebas del programa.
• Crítico: Crash de la aplicación, pérdida de datos o fuga de memoria severa.
• Mayor: Pérdida mayor de funcionalidad, como menús inoperantes, datos de salida extremadamente incorrectos, o dificultades que inhiben parcial o totalmente el uso del programa.
• Normal: Una parte menor del componente no es funcional.
• Menor: Una pérdida menor de funcionalidad, o un problema al cual se le puede dar la vuelta.
• Trivial: Un problema estético, como puede ser una falta de ortografía o un texto desalineado.
• Mejora: Solicitud de una nueva característica o funcionalidad.

En un entorno corporativo, un sistema de reporte de errores puede ser utilizado para generar reportes de la productividad de programadores al reparar errores. Sin embargo, esto puede a veces producir resultados inexactos debido a que diferentes errores pueden tener diferentes niveles de gravedad y complejidad. La severidad de un error puede no estar relacionada directamente a la complejidad de resolver el error. Puede haber distintas opiniones entre administradores y arquitectos.

Un sistema local de reporte de errores (local bug tracker, LBT) es generalmente un programa utilizado por un equipo de profesionales de soporte (a veces un help desk) para mantener registro de incidentes reportados a los desarrolladores de software. El uso de un LBT permite a los profesionales de soporte llevar registro de los incidentes en su "propio lenguaje" y no en el "lenguaje de los desarrolladores". En suma, el uso de LBT permite a un equipo de profesionales de soporte reportar información específica acerca de los usuarios que han llamado a quejarse de aquello que no siempre puede ser necesario en la lista de tareas pendientes de desarrollo (así, hay dos sistemas de registro cuando un LBT está disponible).

• Bugzilla
• Sistema de seguimiento de incidentes

• Software de seguimiento de problemas en el Directorio Abierto
• Integria IMS. Sistema de seguimiento de errores
• Directorio de herramientas de seguimiento de defectos
• Directorio de sistemas de seguimiento de errores con comparación de la característica
• Otro software de gestión de incidencias
• Software libre de gestión de incidencias en entorno web
• Software libre de gestión de incidencias en entorno web (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).
• ALTM que incorpora Gestión de Incidencias entres sus funcionalidades. Tiene integración con otros gestores de incidencias.