Te va a interesar!

6/recent/ticker-posts

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


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”?

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.

Toda suite de automation que se precie debería contar con una sana cantidad de tests negativos en su set de regresión. A veces van a tener que hacer cosas poco ortodoxas para decirle al código que la excepción debería ser lanzada en el Try en lugar del Catch (lo he hecho, no me juzguen!), pero ese espíritu 70% curioso y 30% malicioso de todo tester debería estar ahí para cubrir esos frentes.

Está todo bien en nuestra herramienta de CI: Todo da verde, todo el tiempo, todo el año (mientras producción está en llamas).

Hace no mucho estaba en una reunión, entre gente de todos lados del mundo, con mi mate y termo. Ya se acostumbraron a esa imagen. Mirando por las paredes de vidrio fuera de la sala, veía el monitor gigante con las métricas y jobs de Jenkins con sus estados. Todo pass, todo el tiempo. Last Failure en el año del jopo. Me quedé pensando “pero…qué fue del defecto en producción de hace unos días por el que hubo un emergency fix y gente queriendo saltar por los balcones?”. Nada…esos tests cubrían la nada misma. Muchos tests, cubriendo el happy path más absurdo y simple que se les ocurra, con mucha data distinta que no necesariamente aportaba variedad a los resultados.

No hagan eso mis queridos lectores. Con los dos puntos anteriores a este que les mencioné, deberían tener una cobertura digna y un panorama realista del estado de salud del producto. Ver que todo está bien todo el tiempo, a pesar de deploys y releases grandes, es señal de que algo no estamos haciendo bien como testers. Los programadores son unos avatares del código que no se equivocan casi nunca? No importa, creen casos cubriendo más complejidad, elijan test data que cubra un gran territorio en lo que diversidad respecta en lugar de cantidad por cantidad…busquen romper la aplicación tal cual lo hace un tester manual, después de todo nosotros contamos con una legión de autómatas ayudándonos en la destrucción! Hagamos buen uso de ellos.

Nunca dejen de aprender.

Publicar un comentario

0 Comentarios