top of page

Automation: Cómo demostrar su valor?

Actualizado: 4 oct 2022

Los managers están emocionados, se habla mucho en los pasillos... van a automatizar esa nueva aplicación que vienen desarrollando hace poco. Empiezan a investigar, se deciden por un par de herramientas. Ufa... son con suscripción y no queremos gastar plata. Bueno, vamos a contratar SDETs o Automation Testers que nos hagan un Framework de cero, que no vamos a pagar suscripción y seguramente ahorramos! Ufa... esos recursos son más caros por los sueldos que tenemos que pagarles!

Dos coworkers viendo una pantalla
Y acá ves cómo es más rápido hacerlo así...

El costo de Automation es, casi siempre, alto en el inicio y va bajando progresivamente a medida que el framework cubre más funcionalidad y el mantenimiento es mínimo. Es por eso que tenemos que hacer, entre otras cosas, las tareas bien desde un inicio y pensando a futuro. Y ojo, cuando digo mantenimiento me refiero a literalmente deuda técnica, no a hacer updates en los scripts porque la funcionalidad cambió. Eso lo hablo bastante en este otro post.


A esta altura tenemos a los managers y gente responsable del presupuesto cual globos pinchados, desmotivados y sin tanta charla en los pasillos. Lo que parecía una emocionante y redituable aventura con robots que iban a lograr recortar gastos, se convierte en un costo alto a corto plazo y un mediano y largo plazo inciertos porque dependen de qué tan bien eligieron las cosas y cómo las aplicaron... EL HORROR!


Y ahí es donde vos, como Test Lead o responsable del área de Automation, tenés que calcular y prometer. Si... prometer y calcular. Es básicamente lo que hago al arrancar cada proyecto como líder de Automation. Primero que nada hay que calcular el costo inicial, teniendo en cuenta qué herramientas vamos a usar, si son o no Open Source y por otro lado qué tipo de recursos vamos a necesitar para ponerlas en funcionamiento. No es lo mismo usar algo como Karate, Katalon o Ranorex que pueden ser usados por testers sin experiencia en desarrollo ni mucho background técnico, a tener que involucrar gente con conocimientos de Java, Javascript, Python o C# para poder crear desde cero algo con PyTest, Selenium, Cucumber, Specflow o Cypress/TestCafe.


Una vez que tenemos esos costos tenemos que pensar cómo vamos a ir entregando valor en formato de assets de test. Vamos a automatizar todo? Seguro que no, porque estuvimos leyendo los posts de The Free Range Tester y sabemos que es mala idea!


Vamos a automatizar sobre la UI, con todo el mantenimiento que eso trae aparejado ante el más mínimo cambio en el Front End? Seguro que no porque si llegamos a este puesto sabemos que es una mala idea!