04. Gestión de Bugs e Incidentes
La gestión de incidentes es un aspecto clave de eficiencia dentro de un equipo de desarrollo. A partir de cómo se gestionan los errores, es fácil saber si los testers y desarrolladores de una empresa se sienten parte del mismo equipo y comparten los mismos objetivos. Esta afirmación no está dirigida solo a los desarrolladores instando a que colaboren mejor con los testers, sino también a estos últimos. Los testers deben evitar quejarse (como lo hacen a veces) cuando un error que informaron no se soluciona y deben comprender que no es necesario solucionarlo todo, acorde a la visión global del equipo.
Una mala práctica de gestión de incidentes que nos desagrada en Abstracta, es que con los cientos de herramientas disponibles para la gestión de bugs e incidentes, algunos equipos aún eligen el e-mail como canal para informar errores. O peor aún, no usan nada en absoluto, y el tester simplemente "toca el hombro del desarrollador" después de encontrar un error.
¿Cuál es el problema de reportar errores sin registrarlos con una herramienta adecuada?
Básicamente, es imposible hacer un seguimiento, llevar un registro, saber el estado de cada incidente (si ya fue resuelto, verificado, etc.), o incluso, si hay un equipo de testers, tener claro qué cosas ya fueron reportadas por otro tester que no deban ser reportadas de nuevo.
Por supuesto, incluso cuando se utiliza una herramienta de gestión de bugs, seguirá siendo necesario hablar cara a cara para ayudar a aclarar ciertos aspectos. Puedes mostrar en el momento las fallas que encontraste y lo acontecido, así estarás comunicando los incidentes de manera más efectiva.
El siguiente diagrama muestra el posible ciclo de vida de un bug (podría haber mil variaciones de este, según la estructura del equipo, tamaño, etc.):
Uno de los errores más típicos en la gestión de incidentes que nuestro equipo ha visto al trabajar con diferentes empresas en entornos tradicionales y ágiles, es cuento un bug se considera “solucionado” y el desarrollador lo marca como cerrado.
¡Es importante recordar que el tester debe verificar dos veces que un error se haya solucionado correctamente antes de cerrarlo!
Primero, el tester lo informa y luego el desarrollador lo resuelve, pero la persona que finalmente debe determinar si se ha resuelto es el tester que lo informó en primer lugar. ¿Qué sucede si el desarrollador cree que se ha resuelto, pero después de realizar más pruebas, todavía está allí? ¿Qué sucede si se ha creado un nuevo error? Un tester siempre debe regresar y comprobar que el incidente ya no exista para minimizar los riesgos.
Hay otras variaciones válidas de este flujo. Por ejemplo, podría haber alguien con la responsabilidad de revisar las incidencias que van surgiendo y decidir cuáles arreglar y cuáles no. Esta situación podría funcionar dentro del flujo anterior, ya sea el tester o el desarrollador que marque un error como “resuelto”, “no se solucionará” mediante una conversación (a través de la herramienta o un medio diferente), tanto el tester y el desarrollador podrían decidir juntos cuál es la decisión adecuada, mostrando mutuo acuerdo entre ambos.
En este punto, es posible que te preguntes: “¿Por qué es esto importante para el testing continuo?” Como se mencionó anteriormente, este es el principal punto de interacción entre testers y desarrolladores, ya sea que estén en la misma oficina o en países lejanos. Además, existen herramientas como Jira que permiten la trazabilidad entre los incidentes reportados en la herramienta y el código, por lo que, para aprovechar al máximo estas funcionalidades, todo debe estar bien configurado.
Los equipos de testing más maduros tienen una “máquina” de resolución de incidentes perfectamente aceitada (utilizando una herramienta de gestión de bugs), ya que la mayor interacción entre testers y desarrolladores se da en el vaivén de estos procesos.
