En 2 meses, reducimos un 80% el tiempo de ejecución de las pruebas para Flyr

2. Problema

Se disponía de un set de pruebas automáticas en Java, ejecutado por medio de una herramienta compleja y legacy, instalada por una empresa externa junto a otros módulos que venían con el paquete y nunca llegaron a usarse.

Las pruebas automáticas no estaban integradas en el pipeline de desarrollo.

Las subidas a producción para arreglar defectos eran constantes. El tiempo necesario para validar correctamente las subidas era excesivo debido a la regresión necesaria.

Había áreas funcionales sin cubrir por pruebas automáticas como los servicios API o la aplicación móvil. Esto implicaba un tiempo adicional de pruebas manuales en cada release.

3. Solución

Se propone, tras un análisis de riesgos, priorizar las pruebas a automatizar comenzando por la app web y llevando a cabo previamente una migración de las pruebas antiguas a un nuevo framework, moderno y opensource.

En paralelo se inicia también:

• La automatización de las pruebas de servicio, que se integran en parte con las de User Interface.
• La automatización de las pruebas de la app móvil

Todas las pruebas se lanzan tras detectar un cambio en el repositorio y de manera programada a una hora determinada cada madrugada. También es posible lanzarlas manualmente en cualquier momento.

4. Resultado

Tras dos meses de programación el nuevo framework sustituye al antiguo reduciendo el tiempo de ejecución en un 80% y ampliando la cobertura con pruebas críticas.

El tercer mes cubrimos el 100% de las pruebas críticas de móvil y el cuarto mes se añadió el 100% de las de servicio.

Todas las pruebas están incluidas en el pipeline de desarrollo, generando un informe de resultados tras cada ejecución.

La frecuencia de entrega de valor se aumenta al reducir el tiempo necesario para llevar a cabo las pruebas de regresión. Al mismo tiempo, se ha reducido el número de defectos reportados por los usuarios finales de la aplicación.