title: Sistema de seguimiento de errores
text: # Sistema de seguimiento de errores
  
  Un sistema de seguimiento de errores es una aplicación informática diseñada para ayudar a asegurar la calidad de software y asistir a los programadores y otras personas involucradas en el desarrollo y uso de sistemas informáticos en el seguimiento de los defectos de software. El término usado en inglés es Bug Tracking System, y frecuentemente se usa el acrónimo BTS. Puede considerarse como un tipo especial de sistema de seguimiento de incidentes. Son usados intensivamente por cualquier empresa o institución que realice desarrollo de software.
  
  Si bien muchos sistemas de seguimiento de errores de software libre permiten que los usuarios directamente den de alta la incidencia detectada, en muchas empresas de desarrollo de software se usan de manera estrictamente interna. Muchos de los sistemas de seguimiento de errores de software se integran frecuentemente con otras herramientas, como pueden ser correo electrónico, control de versiones, y otras herramientas de gestión administrativa.
  
  ## Componentes
  
  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.
  
  ## Clasificación de errores
  
  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.
  
  ## Uso
  
  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).
  
  