La forma correcta de reportar fallos o bugs

Cada uno, como QA, tester, desarrollador, gerente de proyecto, dueño del producto, o cualquier rol que tenga en la compañía se puede encontrar o puede estar relacionado con fallos del sistema (bugs) reportados por el equipo de trabajo, estos bugs o fallas tocan a todos los miembros del equipo porque en alguna fase o en algún momento, todos tendrán que ver los bugs reportados y revisarlos.

Primero que todo, aclaremos algo, los bugs no tienen la intención de criticar el trabajo de los desarrolladores o de resaltar un mal trabajo, los bugs tienen como objetivo encontrar fallas antes de que el cliente o partes interesadas lo hagan, si esto pasa, causaría un impacto negativo en la compañía y el proyecto, lo cual tambien causaría la perdida de confianza por parte del cliente. Esto no es una competencia sobre cuantos bugs QA encuentre y no es más senior o experimentada la persona que encuentra más bugs, un buen QA no se mide por esto. Tampoco estoy de acuerdo en que si en un día no se reportan fallos es porque QA no hizo nada, tal vez hubo muchas reuniones, QA estaba en fase de diseño o haciendo casos de prueba, o simplemente no hubo bugs en los entregables del día y los desarrolladores entregaron muy bien.

Existen muchas herramientas para el manejo de fallos como Jira, Mantis, BugZilla, incluso Excel o Google Docs (por favor intenten no usar Excel, Word o Google Docs para esto). Hay muchas herramientas y algunas son gratis, úsenlas, además, muchas de ellas tienen muchas configuraciones para hacer la vida más fácil para todos.

Siempre que hago una entrevista, pregunto cuales son las partes de un bug y he recibido muchas respuestas, algunas muy básicas, algunas con muchos detalles, para mi un gran bug debe tener la siguiente información:

• Resumen o título
• Severidad
• Prioridad
• Reportador
• Persona a cargo de solucionar el bug
• Ambiente en el cual fue encontrado el bug (QA, desarrollo, producción, etc)
• Tipo de bug (funcional, visual, seguridad, rendimiento, etc)
• Pasos para reproducir el bug
• Resultado obtenido al seguir los pasos
• Imagen o video adjunto (es mejor no subir muchas imagenes si un video lo dice todo)
• Versión afectada por el bug
• Fase o sprint en la cual se encuentra el proyecto

Las personas constantemente confunden la severidad con la prioridad, este es un error muy común, pero no olviden que la severidad es el impacto del bug (mayor, menor, crítico) y prioridad es el orden en el que el bug se debe arreglar (inmediatamente, no urgente o también se puede poner como prioridad alta, media o baja). También se debe saber muy bien que es un bug crítico, mayor o menor, hay muchas páginas web con esta información, no voy a hablar de esto hoy.

Se puede agregar más información al bug, como la fecha en la cual debe estar arreglado, componentes, etiquetas (realmente me gusta usar etiqutetas, ayudan a filtrar más rápido y sirven para separar o diferenciar bugs, como bugs de front end, back end, diseño, etc, si tienen la opción de usar etiquetas, úsenlas) y más campos que se puedan imaginar, pero para mi, la información mencionada arriba tiene todos los campos necesarios para que una persona entienda un bug.

Quiero también aclarar algo y es que QA debe dar una buena descripción del bug y adjuntar evidencias, pero no debe explicarle al desarrollador como resolver el problema (esto es un valor agregado),  a veces pueden haber casos de integración o funcionalidad complicada o incluso algún dato incorrecto en la base de datos que pueden llegar a ser la causa del error, no olviden que un bug es la consecuencia de algo y no la causa, QA debe enfocarse en el problema y evidenciarlo con una gran descripción y detalle y el desarrollador se debe enfocar en la solución basado en lo que el QA reportó.  

Todos en el proyecto deben exigirle a QA que reporte bugs de manera correcta y detallada, recuerden que los bugs son vistos por todo el equipo de trabajo si se necesita, y sí otro QA empieza a trabajar en el proyecto, él o ella debe enternder los bugs, no se deben escribir bugs para uno sino para el equipo.

Asegurémonos de reportar bugs de manera correcta sin importar sí no es un QA, los bugs son para todos no solo para QA y desarrollo.

@LuchoAgileQA