Te va a interesar!

6/recent/ticker-posts

Las mejores prácticas no existen!

Quieto quieto! Tranquilo! Puedo notar como más de uno está saltando a mi yugular ahora mismo! Pero si, ustedes saben que me gusta hablar de casos del mundo real y de mis experiencias. Y hoy toca contarles cómo dos de los artefactos de Test más valiosos de mi actual cliente (que es ENORME), no siguen ninguna de las mejores prácticas y nunca dieron un solo problema.

Primero...qué son las mejores prácticas y por qué son importantes?

Bueno, las mejores prácticas son básicamente la voz de la experiencia que dice cómo deberíamos hacer las cosas en un contexto dado. Esto es para hacerlo de la manera más eficiente, con menor cantidad de problemas y que sea de fácil mantenimiento en el futuro. Siempre hablando desde la posición de Automation, claro está. 

Pero ahí mismo hay un problema: Este contexto dado, que es un requerimiento fundamental diría yo para poder aplicar las mejores prácticas, no siempre es lo que tenemos en nuestro lugar de trabajo. Es más, me atrevería a decir que nunca es el caso. De ahí a que haya tanto problema conque "Agile no sirve", "DevOps es una mentira!", "Automation es puro humo" y otras frases que vamos a escuchar y leer a menudo. 

Si tenemos la suerte de estar ante esta situación, lo que mejor podemos hacer es seguirlas. Pero es un arma de doble filo que, cuando NO estamos en la situación ideal...puede llevar a infinitos dolores de cabeza y un desastre atrás de otro para el proyecto. 

En el caso de Automation, sabemos que hay un par de decisiones lógicas que podemos tomar y vamos a estar seguros: Usar el Page Object Model para modelar el código y hacerlo más mantenible y reutilizable. Automatizar siempre que podamos en la capa de WebServices en lugar de la UI para evitar la fragilidad que tiene esta última...ustedes saben, lo conocido. 

Pero entonces...por qué decís que te fue mejor sin seguir estas mejores prácticas?

No es que me fue mejor en general, sino que dos de las últimas soluciones que implementé, sus artefactos de Testing, fueron engendros opuestos a todo lo que se conoce como Best Practices. Les paso a contar.

El primero de ellos fue para ayudar a alguien. Resulta que en su equipo, tenían que hacer cientos de llamadas a un WebService a diario para testear un componente de seguridad. Por un tema de tiempos y expertise del ingeniero de test de turno, no se podía hacer un framework a tiempo con Rest Assured porque implicaba el ramp up del recurso y la incertidumbre de si iba a poder hacerlo o no. 
La solución fue crear jobs en Jenkins con los comandos cURL que el ejecutaba y programarlos para que se corran todos los días antes de que él llegara. Con un poco de toqueteo para que el console output tuviese algo de sentido. Básicamente eran cientos de cURL con sus grep para validar el cuerpo de lo que respondía el servidor. 

Esa solución se implementó y le sacó las papas del fuego justo a tiempo. Anduvo tan bien que no hubo prioridad en mover todo eso a un framework apropiado con Rest Assured, cosa que se está haciendo recién ahora por insistencia mía. Si...me gustan las mejores prácticas, no crean que no!

El otro artefacto se puso algo más complejo. Resulta que trabajo para un cliente muy importante, con medidas de seguridad MUY estrictas, por lo que la red interna en la que se ejecuta es una selva de proxies, firewalls, puertos que si, puertos que no, Mutual TLS, Kerberos...en fin, ustedes me entienden, un montón de cosas que hacen que el más sencillo de los tests sea una odisea. 

El requerimiento era que se pudiese ejecutar un tests muy sencillo de logueo para hacer el flow similar del cliente. Pero...también tenía que medir el tiempo de login, el tiempo de carga de la página, el tiempo de logout y plasmar todo eso en un Dashboard de Grafana. 

Para sumar felicidad, esto se iba a ejecutar desde una plataforma en la nube, externa. Por lo que tenía que entregar un artefacto que corra y listo. Nada de clonar, buildear...directo a los bifes.

La primera cosa que pensé fue "bueno...uso JMeter porque para medir tiempos qué mejor, no?". Pero la cuestión era que tenía que hacer mímica de un cliente, por lo que el renderizado de la página y todo lo que es JavaScript no iba a ser contemplado en el muestreo. Había que hacer otra cosa...

Selenium iba a tener que ser...no quedaba otra! Para los muestreos del tiempo tenía una librería que exportaba el HAR y de ahí podía parsear, hacer un baile místico y sacar los tiempos. Pero...los tiempos eran tiranos, no querían todo el framework que tan lindo creé para usar como template y los requerimientos de la plataforma en la nube eran bastante estrictos. 

Vuelta a JMeter! Sobre todo porque tiene una integración muy feliz con influxDB y de ahí es sencillo consultar la data desde Grafana para construir el tan ansiado Dashboard del cliente. Pero no podía ser API, porque quería ser como un cliente. Así que si...metí Selenium en JMeter. Y no solo eso, PhantomJS (obsoleto hoy en día) en lugar de ChromeDriver en modo headless porque no podían añadir ChromeDriver al estar prohibido por el proxy. Un amor. 

Así que creé un solo JMX, en el que tenía una sola clase con todo el flow de login. Pasaba por la página principal, navegación a la de Login, validación en la landing y luego un logout. 3 Páginas diferentes....no Page Object Model a la vista. 

Eso se ejecutaba y, al tener la clase dividida en bloques, era fácil sacar los tiempos que tardó cada uno con JMeter y escribir eso en influxDB gracias a la integración que les contaba más arriba. 

Resultados

Este último ejemplo es, hoy en día, el asset de Automation que más se usa en todo el cliente. Está en cada piso, en cada pantalla gigante que veo. Con managers y gente de las altas esferas usando eso para monitorear la actividad y anticiparse a cambios inesperados en la performance o errores a través de los distintos ambientes...incluso Producción! 

Y lo mejor...no requirió mantenimiento alguno en más de medio año. Es un script sencillo, que hace algo muy importante en valor para los managers y ejecutivos, con una integración algo intrincada para acercarles un resultado fácil de interpretar para personas no técnicas. 

Y si...nada de ésto sigue las mejores prácticas, pero como les decía: Las mejores prácticas solo son las mejores en contexto. Muchas veces van a necesitar ser flexibles y no hacer las cosas de una manera solo porque "las mejores prácticas lo dicen". Especialmente si esto lleva a que empeore el mantenimiento! Este, amigos lectores, es uno de los errores que con más frecuencia veo en el mundo de Automation. 

Nunca dejen de aprender! 

Publicar un comentario

0 Comentarios