top of page

Si todo da Pass en tus automatizaciones...preocupate!

Actualizado: 4 oct 2022

Muchas veces uno tiene que lidiar con miles de problemas que hacen fallar a nuestros scripts automatizados. Algunos de esos problemas pueden ser propios de complejidades de la aplicación, mientras que otros son errores nuestros en el desarrollo de la herramienta. Es normal, natural y hasta saludable para que un equipo aprenda y progrese. Pero esto muchas veces termina llevando a que los testers se vean demasiado enfocados en que el código “pase”. A qué me refiero conque “pase”?

Lupa sobre teclado
A revisar por qué nada falla...

Que una excepción no esperada, que la inicialización de los elementos de Page Factory, que me trae null… un millón de cosas pasan mientras escribimos código. Resolver cada problema puede llevar menos o más tiempo, dependiendo de la complejidad y la habilidad de la persona haciendo el trabajo. Cuando se pasa un umbral de tiempo corrigiendo estas fallas, la mente del tester entra en lo que denomino una “visión de túnel del desarrollador”. Uno se enfoca demasiado en que pase lo que espera que pase, el “happy path” como le decimos en testing. Y no vemos todo lo que hay alrededor ni las mil maneras en que puede fallar ese código en caso de una falla verdadera en la aplicación.


Una práctica muy sana que todo tester realizando automation debería tener es la de, una vez contentos con la lógica y su funcionamiento, hacer que el test falle para ver cómo se comporta la automatización. Estamos manejando los errores de la manera correcta? Estamos escribiendo en consola la información necesaria para cuando las cosas no salgan bien, podamos dar con la causa lo más rápido posible?


Escribir un test, ver qué pasa y mandarlo como finalizado no es suficiente para darle luz verde, bajo ningún concepto. No es de quisquilloso, lo aprendí padeciendo el arreglar cosas que había hecho de esta manera hace años, con tiempo limitado y teniendo que responder por algo que, seamos honestos, fue un error mío. Piensen que es una inversión a futuro para el mantenimiento de sus frameworks.


Test Negativos.


Sumado al hecho de hacer que nuestra lógica falle para ver cómo se comporta y manejarlo de la manera más feliz posible, también es necesario contar con test negativos que cubran otra cosa diferente al Happy Path del usuario educado que hace todo tal cual lo dicta el manual. Intenten hacer todo lo contrario al manual y vean que la aplicación no lo permite. Saben cuál es una de las reglas para aprender ethical hacking? Ese: Lee el manual y hace todo lo contrario a lo que dice. Se sorprenderían de las cosas que el software no maneja al estar seguro que ningún desacatado va a hacer cosas disparatadas.