¡Esta es una revisión vieja del documento!


Sistema de seguimiento de errores (bugtracker)

Objetivo

El sistema de seguimiento de errores tiene dos objetivos: localizar y corregir errores y gestionar la solititud de nuevas funcionalidades.

Constituye una de las formas de garantizar la corrección de errores; Hasta que un error conocido no ha sido corregido aparece en el bugtracker. Gracias a este sistema se hace imposible olvidarse de ellos.

Las solicitudes de nuevas características o mejoras también se gestionan desde el bugtracker. Aunque para las características no resulte la herramienta ideal, es verdaderamente práctico utilizar la misma herramienta para la resolución de errores. Todo queda centralizado en la misma plataforma.

Descripción del sistema

El sistema de seguimiento de errores está basado en Mantis. Esta herramienta dispone de multitud de útiles herramientas, por ejemplo, poder generar de forma automática listas de errores corregidos y funciones añadidas para una versión de Piwigo determinada verlo en acción.

Porqué no se usa el foro para tal cometido?

La diferencia entre el foro y el bugtracker es el nivel de especialización. Aunque el foro es una herramienta de análisis muy genérica, el bugtracker está centrado en tiquets de seguimiento (corrección de problemas o petición de características). Si se usara el foro para el seguimiento de errores, los usuarios tendrían que ser mucho más metódicos con cada proceso. Con el bugtracker, la herramienta marca la pauta a seguir para el usuario de forma precisa para realizar cada proceso. Los usuarios sólo tienen que rellenar un conjunto completo de información y seguir el proceso establecido.

Uno de los propósitos de la bugtracker es mantener información útil y relevante a largo plazo.

Ventajas de usar la herramienta bugtracker frente al foro:

  • Sigue el estado de un error
  • Informa de quién es el responsable de arreglarlo
  • Informa de quién está interesado en cada error (cualquiera puede suscribirse a un error)
  • Informa en qué versión se ha corregido un error

Utilización

Reglas

Para informar de un error
  • Registrarse es obligatorio para poder reportar errores, pero no para poder consultarlos. El bugtracker, el foro y la wiki no comparten las cuentas de usuario.
  • Al informar de un problema, ser precisos y rellenar tantos campos como os sea posible.
  • Indicar vuestra versión es útil solamente si reportáis errores. No es necesario hacerlo para la petición de nuevas características. Al informar de un error en versiones en desarrollo (trunk), indicar la versión o la revisión de Subversión.
Para los programadores
  • Target version. Establecer “target version” para características, no para errores. target version debe ser una versión “superior”, como “Butterfly” (que se convirtió en 1.8.0) o Alligator (que se convirtió en 1.7.0), y no la 1.7.2 (en la cuál no se planeó la adición de características en una rama de versión estable. Si no se ha decidido planificar una característica para una versión mayor, no debe establecerse la “target version”. Sólo significa que la función no se encuentra en la hoja de ruta (roadmap).
  • Cuando un programador resuelve/cierra un error, se procede a introducir la mejora en la revisión de la Sebversión en la que ha sido aplicada.

Estado del problema (Issue status)

Errores

+--------------+
|     new      | (nuevo) enviado y notificado a los programadores
+--------------+
       |
+--------------+
|   feedback   | (respuesta) el problema está en espera de comentarios (discussion session)
+--------------+
       |
+--------------+
|   confirmed  | (confirmado) el error puede reproducirse y está en espera de un programador
+--------------+
       |
+--------------+
|   assigned   | (asignado) un programador se encarga de dicho error
+--------------+
       |
+--------------+
|   resolved   | (resuelto) El error está reparado en la rama correspondiente a la versión informada
+--------------+
       |
+--------------+
|    closed    | (cerrado) la corrección al error está aplicada al trunk
+--------------+

Petición de características

+--------------+
|      new     | (nuevo) enviado y notificado a los programadores
+--------------+
        |
+--------------+
|   feedback   | (respuesta) el problema está en espera de comentarios (discussion session)
+--------------+
        |
+---------------
| acknowledged | (reconocido) solicitud de característica aprobada y en espera de programador
+--------------+
        |
+--------------+
|   assigned   | (asignado) un programador se encarga de dicho error
+--------------+
        |
+--------------+
|    closed    | (cerrado) la corrección al error está aplicada al trunk
+--------------+
 
Ir hasta arriba
acerca_de/sistema_de_seguimiento_de_errores.1368981817.txt.gz · Última modificación: 2013/05/19 16:43 por albertparera
 
 
github twitter newsletter Donar Piwigo.org © 2002-2024 · Contacto