¿Quién no se queda sin tiempo para testear? 

Y sí, a todos nos pasa. En nuestro caso, teníamos 10 aplicaciones que debíamos testear en simultáneo. Unas estaban productivas y otras estaban por salir a producción. ¿Cómo llegar en tiempo y forma asegurando la calidad? ¿Cómo cumplir la demanda del cliente cuando se trata de un equipo pequeño de automatización? 

Todas estas incógnitas nos llevaron al primer paso: hacer una radiografía del estado del equipo, las tecnologías manejadas y las metodologías de trabajo.  

Los Rayos X  

Primero analizamos las aplicaciones y, encontramos que teníamos componentes de UI que son comunes a todas ellas. Estos componentes están hechos en React Redux y, al ser muy dinámicos, se montan y desmontan, entran y salen todo el tiempo de lo que es el Document Object Model (DOM), lo que implicaba un desafío para automatizar. No es lo mismo automatizar algo que va a ser siempre estático que algo que va a ser dinámico por la aplicación y la tecnología. 

Todas estas aplicaciones son domain specific, lo que se traduce en que cada una de ellas se encarga de algo específico. Entonces, cada vez que aparece una app nueva, hay que entenderla bien en cuanto a su lógica de negocio, porque a veces en estilo pueden lucir más o menos iguales.  

Testing Manual 

Después continuamos analizando el testing manual, haciendo un relevamiento de dónde estaban los cuellos de botella.  

Nos encontramos con que, debido a la constante mutación de los datos, el cliente pedía que se hicieran Daily Checks, cuyos procesos consistían en probar los distintos features de la aplicación todas las mañanas. Se trataba de corridas de smokes y regresiones largas e indefinidas que costaban mucho tiempo y esfuerzo. ¿Cómo hacés si no tenés nada automatizado o no llegás a automatizar todo lo que necesitás? 

Parte del testing incluía evaluar que se indexaran periodicamente nuevos documentos al sistema y que se mantuviera la experiencia de usuario y su usabilidad, lo que denominábamos Document Count & User Experience Monitoring.  

¿Qué teníamos hasta ese momento armado en el proyecto? 

Seguimos viendo qué era lo que ya estaba automatizado. Contábamos con: 

•  .Net Framework. La solución estaba creada en .NET usando C# como lenguaje y NUnit como biblioteca de testing.  
• Selenium (POM) + Restsharp, para UI y WebApi utilizando Page Factory para el Page Object Model.  
• Jenkins detrás orquestando los jobs que corrían las automatizaciones y, generando reportes en HTML que se enviaban por mail.  
• Amazon Web Services utilizando instancias EC2 para correr los tests. 

Lo que definimos con la radiografía 

Con este escáner pudimos establecer algunas metas: 

Objetivos de testing para el equipo: 

Identificar y reducir los cuellos de botella del testing manual.  

Automatizar los daily checks, smokes, regresiones y tareas administrativas.  

Insertarnos en el proceso de Continuous Delivery/ Continuous Integration creando un dashboard centralizado y conectado con los pipelines de Jenkins y los procesos de QA.  

Objetivos de testing para el cliente:  

• Generar reportes claros que manifiesten el coverage de la solución y el estado de la misma.  
• Demostrar que los procesos que se están siguiendo son los correctos.  

A partir de lo anterior, fijamos un roadmap para el alcance de tales objetivos: 

Refactorizacion de Page Factory a Dynamic POM: Page Factory es una biblioteca que tiende a tener más control de las instancias, pero, si un componente cambia en el DOM luego de su inicialización, hay que forzar su actualización. En cambio, con Dynamic POM puede delegarse el control de las instancias de los elementos a través del poder de lamba expressions para reducir exceptions.  

Implementamos herramientas como Allure, que cuenta con todo lo necesario para generar reportes de calidad con historiales, pasos de reproducción, capturas de pantalla, videos, coverage sheet, timeline, etc. 

Levantamos un sistema de clusters para correr grandes volúmenes de tests en menor tiempo. En ese sentido, empleamos Selenoid, que tiene la capacidad de correr tests basados en browser y mobile, usando Docker para generar containers, con mucho potencial para autoescalar. Por el contrario, Selenium GRID tiende a ser más inestable y necesitar más mantenimiento. Es también más difícil de autoescalar y en general no tiene el mismo rendimiento. 

Establecimos marcos de trabajos claros: para eso creamos un dashboard customizado que centralizara todos estos reportes (por aplicación), con progression chart, versionado y ejecutor de jobs por categorías. También pasamos a Kanban para tener más flexibilidad.  

El resumen de las tecnologías que usamos: 

El retorno de inversión 

Se preguntarán ahora cuáles fueron los resultados. Pues, en los últimos 2 años hubo un incremento del 75% en la performance de la solución, reduciendo tiempos de regresiones de hasta 3 horas por aplicación a tan solo 1 hora, siendo el pico máximo de 3 horas en total para las 10 aplicaciones (utilizando 10 containers). Anteriormente, el tiempo total era de 12 horas para la misma cantidad de tests. 

¿Qué aprendimos de esto? 

Muchos clientes suelen resolver rápidamente una problemática en común, accediendo a productos o servicios pagos. Si bien uno de los puntos fuertes de las opciones pagas es el soporte, las herramientas y tecnologías open source suelen tener un gran apoyo de sus comunidades y esto puede ser un deal breaker a la hora de ir por una solución. A excepción de Amazon Web Services, toda nuestra solución está construida con bibliotecas, herramientas y tecnologías open source.   

Y puntualmente aprendimos: 

• Cómo automatizar inteligentemente: no automatizar todo, sino solo lo que ayude a aumentar el bandwith de los equipos.  
• A pensar en grande: ¿1 millón de tests en paralelo? ¿Por qué no? El ensayo y error es imprescindible para aprender a generar soluciones escalables. 
• Que los desarrolladores son amigos: la mejor interacción entre los equipos se da cuando se trabaja codo a codo con los equipos de desarrollo. 

Queremos saber tu experiencia automatizando tests simultáneos. ¿Cómo lo viviste? ¿Qué tecnologías usaron? ¿Qué aprendieron?