stringtranslate.com

Sistema de seguimiento de errores

Un sistema de seguimiento o sistema de seguimiento de defectos es una aplicación de software que realiza un seguimiento de los errores de software notificados en proyectos de desarrollo de software. Puede considerarse un tipo de sistema de seguimiento de problemas .

Muchos sistemas de seguimiento de errores, como los que se utilizan en la mayoría de los proyectos de software de código abierto , permiten a los usuarios finales introducir informes de errores directamente. [1] Otros sistemas se utilizan solo internamente en una empresa u organización que realiza el desarrollo de software . Normalmente, los sistemas de seguimiento de errores están integrados con otro software de gestión de proyectos .

Un sistema de seguimiento de errores suele ser un componente necesario de una infraestructura de desarrollo de software profesional, y el uso constante de un sistema de seguimiento de errores o problemas se considera uno de los "sellos distintivos de un buen equipo de software". [2]

Haciendo

Un componente importante de un sistema de seguimiento de errores es una base de datos que registra datos sobre errores conocidos. Los datos pueden incluir la hora en que se informó un error, su gravedad, el comportamiento erróneo del programa y detalles sobre cómo reproducir el error, así como la identidad de la persona que lo informó y de los programadores que puedan estar trabajando para solucionarlo. [3]

Los sistemas de seguimiento de errores típicos respaldan el concepto del ciclo de vida de un error, que se rastrea a través del estado asignado al error. Un sistema de seguimiento de errores debe permitir a los administradores configurar permisos basados ​​en el estado, mover el error a otro estado o eliminarlo. El sistema también debe permitir a los administradores configurar los estados de los errores y hasta qué punto se puede mover un error en un estado particular. Algunos sistemas enviarán un correo electrónico a las partes interesadas, como el remitente y los programadores asignados, cuando se agreguen nuevos registros o cambie el estado.

Uso

El principal beneficio de un sistema de seguimiento de errores es proporcionar una visión general clara y centralizada de las solicitudes de desarrollo (que incluyen tanto errores como mejoras; el límite suele ser difuso) y su estado. La lista priorizada de elementos pendientes (a menudo denominada backlog) proporciona información valiosa para definir la hoja de ruta del producto o, tal vez, simplemente "el próximo lanzamiento".

En un entorno corporativo, se puede utilizar un sistema de seguimiento de errores para generar informes sobre la productividad de los programadores a la hora de solucionarlos. Sin embargo, a veces esto puede arrojar resultados inexactos porque los distintos errores pueden tener distintos niveles de gravedad y complejidad. La gravedad de un error puede no estar directamente relacionada con la complejidad de solucionarlo. Puede haber diferentes opiniones entre los gerentes y los arquitectos.

Un rastreador de errores local (LBT, por sus siglas en inglés) es generalmente un programa informático que utiliza un equipo de profesionales de soporte de aplicaciones (a menudo, un servicio de asistencia técnica ) para realizar un seguimiento de los problemas comunicados a los desarrolladores de software. El uso de un LBT permite a los profesionales de soporte realizar un seguimiento de los errores en su "propio idioma" y no en el "idioma de los desarrolladores". Además, un LBT permite a un equipo de profesionales de soporte realizar un seguimiento de información específica sobre los usuarios que han llamado para quejarse; esta información puede no ser siempre necesaria en la cola de desarrollo real. Por lo tanto, hay dos sistemas de seguimiento cuando se implementa un LBT.

Parte de los sistemas integrados de gestión de proyectos

Los sistemas de seguimiento de errores y problemas suelen implementarse como parte de los sistemas de gestión de proyectos integrados . Este enfoque permite incluir el seguimiento y la corrección de errores en un proceso general de desarrollo de productos, la corrección de errores en varias versiones del producto, la generación automática de una base de conocimiento del producto y notas de la versión.

Seguimiento de errores distribuido

Algunos rastreadores de errores están diseñados para usarse con software de control de versiones distribuido . Estos rastreadores de errores distribuidos permiten leer los informes de errores, agregarlos a la base de datos o actualizarlos cómodamente mientras un desarrollador está desconectado. [4] Fossil y Veracity incluyen rastreadores de errores distribuidos.

Recientemente, los sistemas comerciales de seguimiento de errores también han comenzado a integrarse con el control de versiones distribuido . FogBugz , por ejemplo, permite esta funcionalidad a través de la herramienta de control de código fuente, Kiln. [5]

Aunque los wikis y los sistemas de seguimiento de errores se consideran convencionalmente tipos distintos de software, ikiwiki también se puede utilizar como un rastreador de errores distribuido. Puede gestionar documentos y código también, de manera distribuida e integrada. Sin embargo, su funcionalidad de consulta no es tan avanzada ni tan fácil de usar como la de otros rastreadores de errores no distribuidos, como Bugzilla . [6] Se pueden hacer afirmaciones similares sobre org-mode , aunque no es un software wiki como tal.

Seguimiento de errores y gestión de pruebas

Si bien las herramientas de gestión de pruebas tradicionales , como HP Quality Center e IBM Rational Quality Manager, vienen con sus propios sistemas de seguimiento de errores, otras herramientas se integran con sistemas de seguimiento de errores populares. [ cita requerida ]

Véase también

Referencias

  1. ^ Bogomil Shopov (8 de septiembre de 2014). «Implementar informes de errores del lado del cliente». Archivado desde el original el 13 de noviembre de 2014 . Consultado el 17 de noviembre de 2014 .
  2. ^ Joel Spolsky (8 de noviembre de 2000). "Painless Bug Tracking" (Seguimiento de errores sin dolor) . Consultado el 29 de octubre de 2010 .
  3. ^ Kaner, Cem (julio de 2000). "Bug Advocacy" (PDF) . kaner.com . págs. 81, 98 . Consultado el 19 de mayo de 2021 .
  4. ^ Jonathan Corbet (14 de mayo de 2008). «Seguimiento de errores distribuido». LWN.net . Consultado el 7 de enero de 2009 .
  5. ^ "Características de FogBugz". Fogbugz.com . Archivado desde el original el 5 de julio de 2013. Consultado el 29 de octubre de 2010 .
  6. ^ Joey Hess (6 de abril de 2007). "Seguimiento de problemas integrado con Ikiwiki". NetworkWorld.com . IDG . Consultado el 10 de noviembre de 2014 .

Enlaces externos