La importancia del triaje de errores

No importa si trabajan con metodologías ágiles o no, en algunos proyectos o en todos tal vez hayan escuchado el término bug triage, en español sería algo así como triaje de errores o priorización de errores, esta es una gran reunión en donde, desde mi experiencia, deben estar tres o cuatro personas: líder técnico, dueño de producto (PO), gerente del proyecto y líder de QA.

Esta reunión tiene dos opciones para hacerse, al final del día o empezando el dia, yo prefiero siempre que sea al final del día, la idea es revisar todos los bugs o errores reportados durante el día o día anterior y verificar si están reportados correctamente, es decir, verificar que todos los campos están bien diligenciados, que hay un título y pasos claros para reproducir el error, ver la severidad y prioridad del mismo y ver si el bug se entiende. La idea aquí también es ver si la prioridad y severidad debe ser cambiada o no y actualizar el error para que sea más fácil de entender, esto con el fin de saber que bugs deben ser solucionados inmediatamente  y cuales pueden ser solucionados después, por supuesto esto depende de las prioridades o entregables del proyecto.

El otro propósito de la reunión es de alguna forma ver el progreso de QA durante el día y durante las pruebas de las áreas funcionales que fueron entregadas a QA, entre menos bugs en una historia de usuario o módulo, mejor. Puede llegar a pasar que un bug tenga errores de gramática, prioridad y severidad incorrecta o que el bug no se entienda, en ese caso, el bug es revisado por todos los miembros presentes en la reunión y se actualiza, puede llegar a pasar que se le pregunte al QA que reportó el bug que actualice el bug en cuanto a pasos para reproducir, imagen o video, etc (siempre se debe poner evidencia en todos los bugs)

Hay que tener en cuenta que el bug triage no debe tomar más de media hora para proyectos pequeños, tal vez pueda tomar una hora para proyectos grandes, la idea es hacer un barrido de todos los bugs y no pasar mucho tiempo en cada uno de ellos, he visto en el pasado como hay reuniones que se demoran más de una hora y no precisamente pasando por cada bug, sino que en un bug se demoran más de 15 minutos en discusiones y en entenderlo. También es importante que solo tres o cuatro personas estén invitadas a esta reunión, entre más gente más larga se vuelve la reunión, solo los líderes de cada disciplina deben estar presentes y si se requiere, preguntar a otras personas, la mayoría de los casos QAs, sobre bugs y estado de los mismos.

Quiero acotar que el bug triage no es una reunión obligatoria, es una reunión opcional que ayuda a dar visibilidad y el estado actual del proyecto, en esta reunión se sabe que necesita ser atacado inmediatamente y ayuda a tener claridad sobre las prioridades del proyecto. Dado el caso que alguna persona del proyecto esté algo perdida o no haya una meta clara o visibilidad de que está pasando, les recomiendo que hagan estas reuniones frecuentemente, dependiendo del proyecto puede ser cada dos días, cada semana o todos los días, esto ya depende del equipo de trabajo y como lo deseen hacer.

@LuchoAgileQA