Te va a interesar!

6/recent/ticker-posts

El mantenimiento en Automation: Algo malo, necesario o bueno?

Quién no vio alguna vez, la recurrente crítica a Automation de que "hay que hacer mucho mantenimiento" o "cuesta mucho mantener y por eso terminó fracasando en el proyecto". Estoy seguro que más de uno! Pero qué hay de real y qué está distorsionado sobre este tema? De eso les vengo a hablar hoy.

De qué tipo de mantenimiento estábamos hablando?

Las aplicaciones cambian, es su naturaleza. Se introducen nuevas funcionalidades, se mejoran otras, se remueven algunas...pasa de todo. Acorde a eso, hay que actualizar los casos de prueba que usamos para validar el estado de la app. Mucha gente piensa no tiene en cuenta esto a la hora de calcular el retorno de la inversión del trabajo en automation y se da la cabeza contra la pared. Está la idea flotando de que lo que se automatiza no debería tocarse jamás, porque si se hace, significa mantenimiento y costo en lugar de entregar valor agregado. 

Este mantenimiento se tiene que tener en cuenta, como se tiene en cuenta el actualizar los casos de prueba que usan los tester funcionales en sus pruebas manuales. Es algo que ocurre y es necesario tener cubierto y hacerlo a conciencia para no tener un montó de pruebas automatizadas fallando inútilmente porque no se actualizan. 

Por supuesto que hay formas de minimizar los impactos que puedan tener los cambios en la aplicación en este tipo de mantenimiento y es algo que tenemos que tomar nota y hacer. Les hablé en más de un ocasión de las mejores prácticas, de la prioridad de automatizar en la capa de WebServices antes que en el E2E en UI y de cómo los tests de UI deberían ser lo suficientemente escasos y sencillos como para que no sea un infierno hacer el mantenimiento. 

Eso no nos va a salvar de que, si remueven una funcionalidad o cambian sustancialmente algo, no tengamos que hacer cambios en nuestros casos automatizados, pero si va a simplificar la tarea lo suficiente como para no perder tiempo en esto y poder seguir operativos a un ritmo aceptable. Y ojo, me refiero a "perder tiempo" cuando toma más de lo que debería, no a la tarea de actualizar las pruebas. Esa actualización es algo inherente a la naturaleza del SDLC. La app cambia, los criterios de validación también, las actualizaciones tienen que ser realizadas. Simple. No es culpa de Automation ni debe tomarse como algo negativo. 

Ahora...si por culpa de cómo se creó el framework notamos que cada vez que hay un cambio, el mantenimiento es una tarea enorme que termina llevando muchas horas de trabajo y atrasando la entrega de nuevos assets, ahí sí las cosas empiezan a verse mal.

Es este tipo de mantenimiento al que se suele referir como una de "las trampas de Automation" que hacen fracasar proyectos. La deuda técnica está íntimamente ligada a este problema. Pero la causa principal es la creación de proyectos no preparados para el cambio. Muchas veces se automatiza para que funcione y una vez da todo verde se deja abandonado. No se piensa a futuro, ni en cómo va a ser trabajar si hay que cambiar algo. Esto hace que cuando finalmente llega la hora de actualizar algo, todos lamenten no haber invertido tiempo en hacer las cosas bien. 

Y si, antes les mencioné sobre la prioridad de tests en WebServices sobre UI, pero es que también hay maneras de minimizar estos tiempos de actualización cuando hablamos de E2E: Page Object Model, buenas prácticas de herencia de clases y manejo de Test Data...todo eso va a ayudar a que, cuando tengamos que meter mano de nuevo en un proyecto, sea un paseo por el bosque y no un ascenso al Everest. 

Les cuento una anécdota de los últimos meses: Uno de los repositorios en los que trabaja el equipo tenía todas las clases de Page Objects y de Step Defs duplicadas para cada ambiente. Si, así como lo leen. El razonamiento fue que en un momento dado, estábamos testeando dos releases diferentes, en diferentes ambientes. Distinto comportamiento, distintos webelements...en fin, medio caótico todo. Mi sugerencia en el momento fue la de usar distintos branches con los distintos ambientes y, una vez los ambientes iban pasando al nuevo release, realizar el merge. Hubo miedo o dudas o vaya a saber uno qué, pero se decidió que era mejor duplicar todas las clases de steps y Page Objects. 

Al poco tiempo se dieron cuenta que era pésima idea y me llamaron para solucionarlo. A esa altura, los ambientes estaban en el mismo codebase a grandes rasgos y la UI no presentaba demasiadas diferencias. Aún así, el equipo tenía que duplicar cada nuevo método en cada ambiente, cada nuevo step...en fin, se imagina la cantidad de trabajo innecesario que significa esto. A todo esto, la línea de comando para la ejecución también requería que pasemos como parámetro qué environment glue estábamos usando para Cucumber, que a su vez tenía que matchear con qué ambiente estábamos usando para la Test Data...un desastre. Me titilaba el ojo, les juro.

La primera parte fue la más pesada: dejar una clase solamente pero con las actualizaciones que habían hecho para esa clase en cada ambiente. Porque si, no había necesariamente un ambiente más completo, sino que cada uno había agregado cosas en el ambiente que necesitaba en ese momento sin hacerlo en los otros. 

Una vez tuve una clase con todo, volé todas las clases duplicadas, dejé un solo paquete en lugar de uno por ambiente (hablamos de Java) y dejé el glue en el runner porque ahora era uno solo y no iba a cambiar. 

Eso hizo que, a partir de ese momento, cuando queríamos agregar casos para un nuevo ambiente que ya teníamos en otro, simplemente agregando la Test Data en el YAML ya saliese andando. Una maravilla...nada de andar duplicando cosas. También se logró así que, al crear algo nuevo o actualizarlo, eso funcionase para todos los ambientes. 

En los pocos casos que había diferencia entre ambientes, muy mínimos, se introdujo un condicional diciendo "si esta pantalla presenta esto, hacer aquello, sino, seguí con lo tuyo". Y listo. Agregar nuevos tests para ambientes es un paseo por el bosque y el equipo es capaz de entregar tests listos con una velocidad mucho mayor! 

Y vos? Cómo ves el tema del mantenimiento en Automation? Cuándo es aceptable y cuándo no? 

Publicar un comentario

0 Comentarios