Te va a interesar!

6/recent/ticker-posts

Reportar defectos: Un arte en extinción?


Tu compañero pasó toda la semana automatizando la UI con unos elementos bastante complejos. La aplicación no es de las más sencillas y todo parece ser una piedra en el camino de Automation. Finalmente, después de mucho renegar y quejarse, logra hacer funcionar todo.

El job en Jenkins da la bendita burbuja azul, diciéndonos que todo está bien. Este proceso involucró muchas idas y vueltas: Cambios en el código, commits, pushes, crear el Pull Request, asegurarse que todo esté pasando porque la app está bien, que no haya falsos positivos... en fin, muchas cosas que se llevan el grueso de la energía del Test Engineer.

Un buen día, la burbuja azul en Jenkins está roja: Hay un defecto. Revisan el log de la consola, el reporte generado en Cucumber y sí, se confirma que realmente es un defecto en la aplicación. Qué hacemos?

Se perdió el foco de reportar los defectos de manera completa y correcta.

Primero que nada, noten que vengo hablando de un defecto encontrado con Automation. Afortunadamente, creo que Testing Manual sigue fuerte en este apartado y es justamente una de las cosas que mas tenemos que valorar y devolver al testing cuando trabajamos como SDETs o Automation Testers

Pero en Automation, el reporte de defectos suele ser un vacío nutrido de varias variables:
  • Falta de conocimiento funcional de la app por parte de los que automatizan. 
  • Falta de experiencia en testing puro y duro de los que automatizan. 
  • Falta de interés en cualquier cosa que no sea Automation. 
Estos puntos que cito son, seamos sinceros, más frecuentes de lo que todos se animan a confesar. Lo he visto numerosas veces y otras tantas he sido yo el que estuvo en uno de esos grupos.

Un defecto tiene que ser, en mi opinión, un documento hecho para que el desarrollador o el recipiente tenga la menor cantidad de excusas para
  1. Rechazarlo por inválido.
  2. Devolverlo por falta de información. 
No sé ustedes, pero a mí no me gusta trabajar demás. Ambos puntos que cito arriba están directamente relacionados con trabajar demás. Para evitar esto, es vital entender un par de cosas. Primero, tenemos que ser capaces de entender la aplicación a fondo primero, para saber cuándo algo es un defecto en la aplicación, cuándo es culpa del ambiente de pruebas y cuándo es culpa de las Test Data que estamos usando para evitarnos malos ratos.

Y qué tiene que tener un Defecto cuando lo reportamos? Cómo evitarnos un ida y vuelta o el rechazo por invalidez?

El arte de reportar un defecto: Lo que hay que saber.

Cuando encontramos algo que parece un defecto, tenemos que contrastarlo contra la documentación oficial de lo que ya está vigente en el ambiente que estamos probando. También confirmar que la versión del software es la correcta en el ambiente de pruebas.

Luego, tenemos que verificar la data que se ha usado para ver si el defecto se puede reproducir con otra data distinta. Está relacionado a un usuario en particular? Pasa con todos? Si es aislado, qué tienen en común los que causan la falla?

Para eso vamos a tener que revisar los logs en el servidor posiblemente, o en la aplicación. Ahí vamos a ver detrás de escenas qué es lo que no le gustó al sistema y vamos a tener más información para añadir a nuestro reporte.

Consultar con un SME si existe uno en el equipo va a ser fundamental también. Sino, con un desarrollador o líder de desarrollo para ver si algo se nos pasó por alto.

Una vez tenemos todo en línea y super confirmado, vamos a empezar a escribir un completo reporte con, primero que nada, qué test data se usó, en qué ambiente y cuándo. Luego vamos a añadir un paso a paso, bien detallado y sin omitir nada, de cómo llegamos al defecto.

Un expected result, es decir, qué esperábamos que pase según la documentación y, contrastando, qué fue lo que pasó realmente. Vamos a linkear la documentación pertinente para que cualquier revisando el defecto pueda mirarla rápidamente y despejar cualquier duda del comportamiento deseado en el sistema.

Todos esos logs que tenemos del servidor y los de la ejecución de Automation? Vamos a añadirlos! Especialmente si son tests de integración y en los logs tenemos los detalles del Request enviado, cuerpo del POST, endpoints usados, headers, etc. Es fundamental tener un log completo cuando automatizamos para que, en caso de fallas, tengamos la información necesaria para fundamentar nuestro reporte.

Algo muy útil es usar también las herramientas de desarrollador de Chrome o Firefox y, en la sección de "Network", explorar qué requests se enviaron, qué responses estuvimos recibiendo, qué headers, qué cuerpo tuvo la llamada, etc.
Finalmente, screenshots o, dependiendo el caso, un video de cómo paso a paso llegamos al defecto. Otra razón para tener esto implementado en nuestro framework de Automation (siempre que hablemos de UI Automation, ya que API Automation tendría unas screens un poco...aburridas.).

Conclusión.

Cuando automatizamos, es importante foguearnos en el testing funcional de la aplicación. Arremangarnos cuando algo falla y probarlo manualmente on demand con distinta data, sutiles diferencias, todo lo necesario para aislar las condiciones que se tienen que dar para reproducir el defecto.

Esto nos va a dar muchas ventajas, como conocer la aplicación en mayor profundidad, lo que se va a traducir en mejores tests automatizados y mejores reportes de defectos que, sin dudas, tu equipo de desarrolladores y managers van a agradecer.

Y vos, cómo reportás los defectos? Déjame tu comentario!

Publicar un comentario

0 Comentarios