top of page

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.

Escritorio y café
A la hora de reportar un defecto...

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.


</