Te va a interesar!

6/recent/ticker-posts

Las peores 5 prácticas de Automation que no te van a dejar dormir por la noche.


Automation suele ser algo que, muchas veces, se toma a la ligera. Se decide que hay que "automatizar" los casos de prueba y no se piensan muchas cosas que, si no se plantean al inicio, van a llevar a la larga o a la corta, a la completa ruina del test Automatizado. A lo largo de mi más de 10 años de experiencia automatizando, creo que he pasado por la gran mayoría de pitfalls que se puedan imaginar relacionados a Automation Testing y es por eso que hoy les quiero contar sobre las peores prácticas capaces de terminar con toda la fe (y el presupuesto) en la automatización!

Automatizar absolutamente todo lo que se cruce.


Si no es la más nefasta de las prácticas, le pega en el palo. Y es que cuando se piensa en automation, inicialmente, en la cabeza de muchos está la romántica idea de que es sumamente sencillo y buena idea automatizar todos los tests con los que contemos. Esa funcionalidad que no usa nadie y que va a ser removida en la próxima release? Automatizar! Validar los colores de letra de la página es un test? Automaticen! El café ese que te hacés a las 10 de la mañana mientras hablás con tus compañeros? Automatizalo también! 
Fuera de broma, he estado en proyectos que se jactaban de tener "miles de casos de prueba automatizados" al usar esta filosofía. Se imaginan cómo terminaron, no?
Las razones por lo que esto no es viable son sencillas: El mantenimiento de test cases frágiles y que no aportan valor termina siendo un costo que tira todo el ROI (retorno de la inversión para los amigos) al garete. En ese momento, sea quien sea que esté pagando por el equipo de automation dice: "A ver...estoy pagando 100 por algo que me ahorra 20 cada tanto debido a que 80 tengo que reinvertirlo en mantener los tests que no me encuentran nada." 
Es un viaje de ida que termina inevitablemente en la pérdida de confianza en automatizar. Ver que automation no ahorra tiempo ni dinero es malo, muy malo...
También lleva a una carrera desenfrenada por la cantidad más que por la calidad, ya que cuando no hay una priorización, el tener más tests sin importar de qué son se convierte en el foco.

No utilizar las herramientas adecuadas.


Una vez, debido a que no se sabía cómo automatizar webservices REST con Java y Rest Assured, me encontré con toda una suite de regresión hecha en JMeter. Si, JMeter...la herramienta para pruebas de performance. Usar herramientas que no están hechas para el fin que necesitamos es un presagio oscuro amigos, tan oscuro que al cabo de un tiempo vamos a darnos cuenta, en el peor caso, de que las limitaciones para lo que necesitábamos hacen inútil todo el esfuerzo de automatizar o, en el mejor caso, de que había una herramienta adecuada y que se tiene que rehacer todo con ella. Ambas son un Critical hit para un proyecto de automatización y, de nuevo, la asignación de presupuesto por parte de las altas esferas. 

Hacer las cosas más complejas de lo que deberían porque, HEY, YO QUERIA SER DESARROLLADOR!

señora calculando

De los mismos productores de la película de "automaticen todo", tenemos a "no me importa mucho el foco de mi tarea, la cuál es facilitar las tareas de testing con mis scripts de automation, sino que quiero pensar que soy un dev y voy a hacer un código que ni te cuento!" Ok, es un nombre largo para una película, pero que la vi mil veces la vi mil veces. Esto suele pasar cuando tenemos a un desarrollador que lo pasan a testing. Y no me refiero a que se pasa porque cree que testing es tan necesario como cualquier otra cosa en el SDLC, sino porque o lo metieron a la fuerza o bien no era tan bueno como dev y consideró que testing iba a ser más sencillo. 
Esto lo expuse largo y tendido en ESTE post, pero para ir al grano y lo que me interesa decirles en esta oportunidad, decir que este tipo de mindset por parte del ingeniero de test termina haciendo que su mente esté en producir código más que tests. Muchas veces llegando tan lejos como el crear librerías de cosas ya existentes, complicarse con el versionado y generación de artefactos que, obviamente y por terminar siendo otro proyecto de desarrollo más, contiene errores. Y saben qué? Ahora el código que generó testing necesita testing! 

Record and playback...me produce escalofríos!

Selenium Webdriver vs Selenium IDE

Ahora estamos pasando por un revival de este tipo de herramientas, como Selenium IDE (volvió...en forma de fichas!), la extensión del recorder de Katalon Studio, algunas plataformas en la nube que permiten también grabar y otras. Yo creía que ya habíamos concluido en que no son eficientes y terminan generando automatizaciones frágiles, que requieren muchísimo mantenimiento y que están llenas de basura digital que complica cualquier intento de meter mano para arreglar cosas. 
Les cuento una que, por suerte, acaba de pasar a mejor vida. Hace unos 8 años, comencé a automatizar con Coded UI y Visual Studio. El workflow era grabar con un recorder, el cual generaba dos clases hermanas, una llamada ".designer" y la otra ".cs" porque, hey, Microsoft! La cuestión era que la primera, no se modificaba, ya que autocompilaba cada vez que se grabase algo y se sobreescribía, no permitiendo modificar nada. Para eso, teníamos la clase .cs, la cuál mediante un simpático editor podíamos modificar para cambiar la manera en que se localizaban elementos, las acciones, assertions y demás. Obvio que, en la simplificación que plantea todo recorder, hace cosillas demás, porque mejor que sobre y no que falte. El tema era las clases apocalípticas que terminaban siendo creadas, con pilas y pilas de código incomprensible que, al momento de necesitar editar algo que había cambiado era un dolor de cabeza que ni les cuento. 

No establecer una política de branching adecuada: I'm Groot! 

Jenkins Blue Ocean

Si bien me van a leer muchas veces diciendo que testing es testing y desarrollo es desarrollo, también lo van a hacer diciendo que el Test Engineer necesita tener el cinturón de herramientas de un dev, pero con mindset de Tester. Cuando no se establece una política adecuada de Source Control, exponemos todas nuestras preciadas horas de trabajo al cataclismo que supone un error en cambiar una clase, en una ínfima modificación que rompe todo. Y ahora qué hacemos? Me han tocado clientes que planteaban mandarnos el proyecto zipeado, modificarlo y reenviarlo. Se imaginan mi cara leyendo eso? 
Tener, mínimo, la posibilidad de hacer un rollback al estado previo en que estaba funcionando, modificar el código o añadir lo necesario en un Branch y generar Pull Requests para el peer review de colegas debería ser mandatorio en todo proyecto de automatización. Ahorra muchísimos problemas en fases tempranas, nos ayuda a mejorar como profesionales y mantiene nuestro proyecto sano como si hubiese comido una manzana al día. 

Esto es todo por hoy! Quería comentarles sobre las peores prácticas que he visto a lo largo de los años con ejemplos y el por qué no son viables, para luego hacer un post más optimista con las mejores prácticas para rockear proyectos de Automation! 

The Free Range Tester 

Publicar un comentario

0 Comentarios