Enmilocalfunciona

OBJETIVO

Parece simple, parece obvio, pero me he encontrado de todo en varios clientes y varios proyectos.

La gestión de los bugs, ver cómo se están gestionando, nos dan pistas importantes para el futuro y presente del equipo, además de por supuesto, tener la lista de cosas por arreglar con mayor o menor prioridad.

Como en todo, podemos ver qué se puede mejorar en este sentido y cómo intentar ponerle solución anticipándonos y siendo proactivos.

LO QUE NOS PUEDE OCURRIR, WOW!!

1.- ¿Cuántos tenemos? No tenemos un modo fácil de saber cuales son todos los bugs no cerrados, o su historial. Si alguien viene a preguntarme cuantos bugs quedan por arreglar, ¿puedo contestar?

Solución: Preguntar si ya alguien hizo este trabajo en algún dashboard de Jira o de otra herramienta, y en caso de no existir, comenzar desde ya a crear un panel a la vista de todo el equipo sobre lo que queda pendiente, los que se han ido arreglando, para poder contestar a preguntas sobre ellos.

2.- ¿Se entienden? Una vez encontrados estos bugs, debemos fijarnos en cómo están escritos, cómo hemos definido los pasos para reproducirlos y si cualquiera podría entender cual es el motivo del fallo. Escoger varios de ellos, de los más recientes a alguno más antiguo para hacer este análisis. Si el resultado no es satisfactorio lo suyo es intentar mejorarlo, porque nosotros estamos exigiendo calidad a los demás, así que debemos predicar con el ejemplo de aportar toda la información relevante sobre el bug. Hay que tener en cuenta que un bug mal informado se quedará sin resolver, o perderemos mucho tiempo preguntando aquí y allá cómo se reproduce, y al final esto se traduce en tiempo y el tiempo es dinero.

Solución: Si vemos que algunos de ellos dejan que desear, hay una serie de normas que nos pueden ayudar a definirlos bien, una plantilla que todo el equipo debe conocer y seguir. Esto lo he redactado en otro artículo específico sobre cómo tener calidad en la redacción de nuestros propios bugs.

3.- ¿Son muy antiguos? Tenemos bugs muy antiguos en el tiempo, y por una razón u otra siguen allí o al menos si se arreglaron nadie fue a cerrar el bug en la herramienta donde los damos de alta.

Solución: Si tenemos este caso y realmente son bugs de hace más de un año, podemos aplicar la filosofía lean y cerrar los que ya sean más antiguos de determinada fecha, porque si vuelven a ocurrir se volverán a dar de alta y si nadie les prestó la suficiente atención en su momento por algo será. El tener listas largas de bugs desanima y no te deja centrarte bien en los últimos casos importantes.

4.- ¿Tienen todos la misma prioridad? Observar las prioridades de los bugs, ¿tenemos un poco de todo? De lo que hay que huir es de tener todos o casi todos los bugs con la misma prioridad, porque entonces es lo mismo que no tener marcadas las prioridades y no resolveremos primero los más urgentes.

·        Blocker: no deja hacer las operativas debido a este fallo.

·        Critical: Caida de la aplicación o pérdida de datos.

·        Major: Pérdida importante en una operativa concreta

·        Minor: Pérdida leve en una operativa concreta

·        Trivial: Suelen ser aspectos de Interfaz gráfica que no bloquean.

Solución: Recordar al equipo que los QA bajo su criterio asignarán al bug una prioridad, pero luego se puede modificar si se observa que es más urgente de lo que parecía o viceversa. Es responsabilidad de todos respetar estas prioridades para solucionar antes lo más urgente.

5.- ¿En cuanto tiempo los resolvemos? Tiempo de resolución de los bugs. Esta pista es importante analizarla junto a cual fue la prioridad de este bug. En teoría, al menos los bugs bloqueantes y critical deberían tener un tiempo de resolución muy corto. Los mayor algo razonable según estime el equipo y los minor y trivial ir arreglandolos conforme se puedan incorporar en los sprint.

Solución: El equipo puede definir el tiempo máximo de resolución de un bug según su prioridad, y establecer algún modo de aviso o revisión cuando algún bug está tardando mucho en solucionarse. En las reuniones diarias se puede añadir un tiempo leve para hablar sobre la situación de los bugs.

6.- ¿Cuantos bugs son añadidos en cada nueva release? Los testers hacen las pruebas manuales de los nuevos desarrollos o modificaciones en entornos previos, y puede ocurrir que tengamos una gran cantidad de nuevos bugs, de forma que aunque se arreglaron 10 por ejemplo, se han añadido otros 10 más o incluso 12 ( sí, esto lo he visto yo)

Solución: Esto es claramente signo de que el equipo no está trabajando correctamente. Las cosas deberían llegar más probadas a QA o más refinadas con criterios de aceptación mejores, para que no se tengan que abrir tantos nuevos bugs que alimentan la lista y deprimen al equipo que no ve bajar el número de incidencias. Establecer dentro del proceso criterios de aceptación claros de la tarea, exigir evidencias de las pruebas realizadas por el desarrollador, más comunicación entre el tester y el desarrollador para una vez tengamos el plan de pruebas el desarrollador pueda ver qué vamos a probar... algo se podrá mejorar, seguro. Si no se da tiempo a desarrollar con calidad también luego ocurre que no se prueba casi y se le pasa al tester, pero entonces es más tarde cuando aparecen estos bugs y cuanto más tarde más coste. Intentemos introducir a qa lo más pronto posible para anticipar a estos posibles errores cuanto antes.

7.- ¿Tenemos bugs duplicados? A veces no observamos lo que los demás compañeros están dando de alta y no nos damos cuenta y lo informamos por partida doble.

Solución: Antes de dar de alta uno nuevo intentar revisar si ya tenemos algo similar dado de alta buscando por palabras clave. No nos los tenemos que saber todos de memoria, pero leer de vez en cuando cuales son los añadidos recientemente no está de más para poder tenerlos frescos y poder hablar de ellos o levantar la mano en alguna reunión sobre alguno de ellos. Si no encontramos nada similar darlo de alta. Si encontramos alguna vez alguno repetido no dejarlo pasar y eliminar uno de ellos.

8.- ¿Reaparecen nuestros bugs? Los arreglan pero no se sabe porqué al poco tiempo los volvemos a tener ahí.

Solución: Para darse cuenta de esto, de la frecuencia en la que un bug aparece hay que llevar constancia o revisar los bugs que ya se arreglaron. Mira el histórico de bugs arreglados similares al que te llama la atención porque te "suena". Habla con el equipo porque no se ha compartido la información de este problema y quizá otro programador cae en el mismo fallo.... seguro que más pronto o tarde se encuentra el motivo de la repetición del bug.

CONCLUSIONES

Si intentamos mejorar en los puntos anteriores ( y nadie ha dicho que sea de la noche a la mañana ), tendremos mejor control de los bugs y a la larga el equipo funcionará mejor. Una lista controlada de bugs significa que el equipo está trabajando bien, y una lista descontrolada quiere decir ( y nos está hablando ) que debemos mejorar o la cosa irá a peor haciendo bola de nieve.

Ventajas de tenerlo controlado: el Product Owner podrá elegir correctamente qué bugs añadir al sprint para entregar mejor valor( si no no sabrá qué elegir de tanto que hay), no llegarán tantos bugs a producción pese haber sido detectados en entornos previos, el equipo se sentirá mejor porque ven que la lista no crece y crece, sino que cada vez son menos y la calidad de las entregas mejor.

Pero, ojo, que no es controlarlo una vez y ya está, sino que se necesita un mantenimiento constante de observación para ver si cada vez vamos a mejor o a peor.... mostrando gráficas de situación de cómo estábamos hace un año y cómo estamos a día de hoy. ¿Quién dijo fácil ? Pero no imposible, nos gustan los retos.

Happy testing!!(●'◡'●)