Durante el ciclo de vida de un sistema se presentan diferentes etapas de maduración de sus componentes las cuales pueden afectar la funcionalidad o el nivel de cumplimiento de los requerimientos, especialmente en las etapas de pruebas (testing o QA), liberación (deployment) y mantenimiento (support). El sistema Mantis, es una herramienta BTS (Bug Tracking System) de código abierto que permite gestionar las últimas etapas y procesos del ciclo de vida de un sistema de una manera estructurada y sencilla para construir un historial de cambios y posteriormente un sistema de administración de conocimientos al mismo tiempo que permite a los administradores de los proyectos tener una visión sobre el comportamiento del desarrollo del sistema y las implicaciones de los defectos o incidentes y el desempeño del personal en los diferentes roles asociados.
En esta publicación describiremos el uso general de la herramienta a través de la descripción de algunos de sus campos y asumiremos la configuración predeterminada (default) de Mantis v2.25.5. Cabe destacar que el enfoque del sistema Mantis permite la personalización de muchos de sus campos y configuraciones para adaptarse a la dinámica de cada equipo.
Roles
Mantis define diferentes roles o perfiles de usuario para ayudar a administrar el proceso de gestión de defectos o incidentes. Los roles predeterminados son los siguientes:
- Administrador (Administrator): Tiene autorización para reconfigurar el Mantis así como todos los atributos de un desarrollador.
- Desarrollador (developer): Puede ver y modificar y crear incidentes.
- Informante (reporter): Puede crear incidentes nuevos pero no puede modificarlos.
- Consulta (viewer): Puede ver incidentes pero no modificarlos ni crearlos.
- Actualizador (updater): Puede actualizar incidentes pero no crear nuevos.
- Gerente (manager): Tiene autorizaciones especiales sobre un proyecto específico.
Para más información sobre los roles y permisos, puede consultar la documentación aquí.
Ciclo de vida de un incidente
La mayoría de los incidentes (“issues” o “bugs”) pasan por una serie de etapas denotados por su estado (status).
Al principio del ciclo de vida de un incidente, el informante o ingeniero de calidad crea un nuevo incidente describiendo de la manera más específica posible sus características. Este incidente tendrá el estado de “nuevo” hasta que sea asignado a un desarrollador. El administrador puede asignar los incidentes, pero un desarrollador puede asignárselos el mismo o el sistema puede hacerlo automáticamente si el proyecto o categoría del que se trata el incidente tiene un responsable asignado.
Cuando un incidente es asignado a un desarrollador, éste es notificado vía correo electrónico. El desarrollador tiene la responsabilidad de revisar el incidente, investigar las causas y explorar las posibles soluciones. Durante este tiempo, el desarrollador puede agregar notas que documenten el incidente, cambiar sus propiedades, agregar documentos adjuntos o asignar a otro desarrollador.
Una vez que el desarrollador encuentra la solución al incidente, debe llenar una nota especificando con el mayor detalle posible la solución dada y cambiar el estado del incidente a “resuelto”. El incidente será revisado por los analistas de calidad para verificar la solución y en su caso cambiarán el estado a “cerrado” o a retroalimentación (feedback).
La siguiente figura muestra un ejemplo del ciclo de administración de defectos utilizando la terminología predeterminada de Mantis:
Estados de un incidente
- Nuevo (new): significa que el incidente ha sido creado y que no hay ningún personal atendiéndolo.
- Asignado (assigned): significa que el incidente está siendo atendido por alguien y que esa persona es responsable de darle seguimiento (generalmente el desarrollador que hará la investigación y realizará el cambio).
- Resuelto (resolved): significa que el incidente ha sido resuelto provisionalmente y está en espera de ser verificado.
- Cerrado (colsed): significa que el incidente ha sido resuelto definitivamente y ha sido verificada su solución.
- Retroalimentación (feedback): significa que el incidente no sigue el ciclo de vida normal (como cuando el incidente tiene que volver a abrirse o se encuentra detenido por falta de información de un tercero). Luego el incidente puede cambiarse a asignado, resuelto, notificado, confirmado o cerrado según corresponda.
- Notificado (Acknowledged): Significa que el tercero involucrado en la resolución de un incidente (administrador, administrador de proyecto, cliente, etc.) está enterado de la situación y ha agregado la información necesaria para continuar con la resolución del incidente.
- Confirmado (Confirmed): Significa que el desarrollador o desarrolladores involucrados en la resolución de un incidente se dan por enterados de un cambio de estado del incidente y que tiene conocimiento de sus notas o material asociado.
Resolución de incidentes
El estado de un incidente está relacionado con una propiedad llamada “resolución“ (resolution), la cual por lo general es cambiada automáticamente por el sistema cuando el incidente sigue el ciclo normal; sin embargo, durante el proceso de revisión, el desarrollador puede darse cuenta de que el incidente no puede ser arreglado, por ello deberá cambiarse la propiedad de resolución como corresponda de acuerdo a la siguiente tabla:
| Tipo | Nombre | Descripción |
| Abierto | Open | El incidente sigue abierto |
| Resuelto | Fixed | El incidente ha sido resuelto |
| Reabierto | Reopened | El incidente se resolvió o cerró, pero está siendo reevaluado. |
| No se pudo reproducir | Unable to reproduce | El incidente no pudo ser reproducido por el desarrollador. |
| No se puede arreglar | Not fixable | No se puede dar solución debido a alguna situación (normalmente tiene que ver con el diseño, la implementación o una característica no funcional) |
| Duplicado | Duplicate | El incidente está duplicado (solo si está cerrado o resuelto) |
| No se requiere ningún cambio | No change required | No se requiere un cambio en el proyecto para resolver el incidente |
| Suspendido | Suspended | El incidente está suspendido o fue diferido. |
| No se va a arreglar | Won’t Fix | El incidente no se va a resolver por alguna otra razón dada por el desarrollador o el administrador del proyecto (ejemplo, costo-beneficio) |
Para más información sobre los flujos, pueden consultar la documentación aquí.
Relación entre incidentes
Algunos incidentes pueden encontrarse relacionados entre sí. Cuando un desarrollador o ingeniero de calidad detecta una relación entre 2 o más incidentes puede modificar las propiedades de estos para que se relacionen entre sí de manera jerárquica utilizando el campo de Relaciones “relationships” de acuerdo a los siguientes criterios:
- Padre de (Parent of): El incidente actual tiene una relación causa efecto con otro incidente, siendo el actual la causa.
- Hijo de (Child of): El incidente actual es consecuencia de otro incidente ya reportado.
- Duplicado de (Duplicate of): El incidente actual es el mismo que otro que ya existe (cambia el tipo de resolución del incidente automáticamente a duplicate)
- Tiene duplicado (Has duplicate): El incidente actual tiene un incidente correspondiente en un sistema o módulo con el cuál aparentemente no tiene ninguna relación. Este tipo de relación es posible determinarla a través de las reuniones entre administradores de proyectos (project managers) o de equipos de trabajo por ejemplo las reuniones de scrum.
- Relacionad con (Related to): Este tipo de relación se asigna a un incidente el cual se tiene la noción que involucra otro incidente registrado (es decir que se presume que existe una codependencia con otro incidente) pero no se ha determinado la relación precisa entre ambos.
Al cambiar la propiedad de relación es requisito incorporar el número de incidente con el cual tiene relación el incidente actual.
Prioridades
La prioridad tiene que ver con el tiempo de respuesta que se le dará a un incidente. Cuando el informante reporta un incidente, debe asignarle una prioridad de acuerdo con el nivel de importancia del proyecto según los siguientes criterios.
- Ninguna (None): El incidente no es importante, puede ser trivial, un “tweak” o una mejora cosmética, debe tratarse después de que todos incidentes con otra prioridad hayan sido arreglados debido a que no tiene impacto en la funcionalidad del proyecto o en las actividades de la organización. Por lo general corresponde a las severidades de característica “feature”, error de texto “typo”, y trivial.
- Baja (Low): No es necesario tratar el incidente de manera inmediata (por ejemplo un cambio en un mensaje o se trata de alguna función que no se usa muy frecuentemente) y deben tratarse después de cualquier incidente con prioridad normal o superior debido a que tiene poco impacto en la funcionalidad del proyecto o en las actividades de la organización. Por lo general corresponde a la severidad menor “minor”.
- Normal: El incidente debe tratarse como parte de las funciones diarias y debe tratarse después de los incidentes con prioridades altas, urgentes e inmediatas debido a que se trata de un proceso que ocurre día a día o que es reportado muy frecuentemente. Por lo general corresponde a las severidades menor “minor” y mayor “major”.
- Alta (High): El incidente tiene un impacto alto en la funcionalidad del proyecto o en las actividades de la organización y debe atenderse antes que los incidentes con prioridades menores. Por lo general corresponde a la severidad mayor “major”.
- Urgente (Urgent): El incidente tiene un impacto importante en uno o varios proyectos o funciones de la organización y debe atenderse lo más pronto posible. Por lo general corresponde a la severidad Caida “crash” o bloqueo “block”.
- Inmediata (Immediate): El incidente provocó la detención la funcionalidad de uno o más proyectos o actividades de la organización y debe atenderse de manera inmediata. Por lo general corresponde a la severidad Caida “crash” o bloqueo “block”.
Es común que los proyectos lleven a cabo sesiones de triage periódicas o bajo demanda para asignar las prioridades a los incidentes reportados.
Severidad
La severidad de refiere al impacto del incidente sobre la funcionalidad del sistema o las actividades de la organización, así como del número de usuarios afectados y debe asignarse de acuerdo a los siguientes criterios:
- Característica (Feature): Este tipio de severidad no indica un problema sino una función que se solicita se incorporare al sistema.
- Error de texto (Typo): Este tipo sugiere un cambio en alguna etiqueta o mensaje por causa de un error ortográfico.
- Trivial: Se refiere a un incidente extremadamente menor
- Menor (Minor): Se refiere a un incidente que no es trivial pero que tiene una solución temporal o existe una manera sencilla de evitar que ocurra (también llamada “work around”)
- Mayor (Major): Se refiere a un incidente que no se puede evitar que ocurra o para el que no hay una solución temporal definida.
- Caida (Crash): El sistema de software se cae como resultado de este incidente; sin embargo, esto sucede solo para el usuario que obtiene el error descrito.
- Bloqueo (Block): El incidente provoca que el sistema no responda y que ningún usuario pueda utilizar la funcionalidad que generó el error o el sistema completo.
En ocasiones, al momento de reportar un incidente no es posible identificar la severidad por lo que esta no necesariamente se puede asignar al reportarlo. Sin embargo es altamente recomendable que durante el ciclo de vida del incidente se realicen las indagaciones correspondientes, por ejemplo durante el proceso de RCA (ver publicación al respecto aquí), y que el defecto tenga siembre una severidad al ser cerrado.
Reproductibilidad
Esta propiedad es establecida por el informante que reporta el incidente como nuevo y se refiere a qué tan seguido se observa que ocurre el incidente. Esta propiedad puede ser cambiada posteriormente por el desarrollador como parte o resultado del proceso de investigación y corrección. La propiedad debe ser asignada de acuerdo con los siguientes criterios:
- Siempre (always): El incidente ocurre todas las veces que se sigue la secuencia de pasos indicada en la sección de pasos para reproducir el incidente (steps to reproduce).
- Algunas veces (sometimes): El incidente ocurre sólo cuando se sigue una serie de pasos definidos que no son requeridos para la funcionalidad principal del componente o módulo o cuando se combinan ciertas condiciones definidas en la sección de pasos para reproducir el incidente.
- Rara vez (Rarely): el incidente ocurre en ciertas ocasiones ya sea porque la funcionalidad no es utilizada frecuentemente o porque no se han determinado las causas probables o serie de pasos que provocan el incidente.
- No Disponible (N/A): no se tiene información de la reproductibilidad del incidente.
Categorías
Las categorías sirven como apoyo para clasificar un incidente de modo que se dirija al personal adecuado y se tenga una idea más precisa del tipo de recursos (elementos del servicio) que se van a utilizar para resolverlo. Un incidente solo puede ser asignado a una categoría y generalmente es seleccionada por el informante (quien crea el incidente); sin embargo, puede ser cambiada durante el ciclo de vida del incidente para que refleje la naturaleza apropiada del incidente.
Por lo general los proyectos tienen ciertas categorías predefinidas, y Mantis proporciona algunas por defecto; sin embargo estas pueden ser personalizadas de acuerdo al tipo de administración de proyectos o a la estructura funcional de la organización (ver post sobre propuesta de categorización).
Conclusión
Mantis BTS es una herramienta de manejo de defectos de software muy efectiva y confiable. Proporciona una interfaz fácil de usar y altamente personalizable para la gestión de incidentes y defectos, lo que permite que los equipos puedan identificar, priorizar y resolver problemas de manera eficiente, adaptando la herramienta a sus necesidades y procesos particulares de manera efectiva y confiable.
