Te va a interesar!

6/recent/ticker-posts

El Retorno de la Inversión en Automation: Cómo demostrar su valor?


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!

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!

Entonces vamos a pasar a definir la cantidad de funcionalidad que vamos a estar cubriendo, cada una en su capa adecuada, sean WebServices o UI, y cuánto va a llevar a cada una. Yo particularmente soy amigo de Jira. Si, qué quieren que les diga? Mucha gente odia Jira y dicen cosas feas, pero a mi me sirve. Planificar sprints, con una poker planning meeting con un puntaje que van a ir afilando de acuerdo a lo que puedan entregar semana a semana (o por ahí hacen sprints de dos semanas, da igual), con tareas puntuadas a conciencia y ahí ya empezamos a ver algo que toma forma.

A medida que vamos entregando automatizaciones, ya quedan ahí, siendo útiles sin mantenimiento. Ahí es dónde el que pone la plata ve que valió la pena y sigue apoyando el proyecto. Esto hace que la curva que inició alto en el eje de costo, vaya bajando progresivamente a medida que pasan los sprints.

La importancia del monitoreo y de vender nuestro trabajo.

Pero todo este baile técnico de cálculos y signos de dólar es una parte, muy importante eso si, de batear el Retorno De La Inversión fuera del estadio. Algo que entendí que es vital y muy positivo sobre todo para los que trabajan creando los assets de Automation es mostrar los reportes, las ejecuciones, los monitoreos de la aplicación siendo creados por Automation.

Para esto no hace falta más que un monitor grande, o televisión y tener nuestros dashboards de Jenkins a la vista. Ver cómo los tests se ejecutan todos con una agenda precisa y nos devuelven enseguida el estado de nuestra aplicación es algo que siempre maravilla a los que creen que automation es magia negra.

Incluso tests sencillos de performance pueden ser mostrados en herramientas gratuitas como Grafana, proveyendo una manera visual y sencilla para que cualquiera que pase por ahí sepa de inmediato si todo está bien o algo anda mal. Y todo ésto sin la necesidad de saber la intrincada implementación detrás.

Conclusión.

Probar el ROI (Return of Investment) de Automation es algo que generalmente quita el sueño a los proyectos. Es algo donde muchos no saben cómo afrontar el problema y se termina cayendo en el olvido al no contar con el presupuesto porque "no se ven los resultados". Como vimos en este post, a veces es justamente eso: La literal necesidad de VER los resultados en una pantalla, lo que separa un "NO HAGAN MAS ESTO" de un "SIGAN CON AUTOMATION QUE ME ENCANTA!" Como respuesta!

Nunca dejen de aprender...

Publicar un comentario

0 Comentarios