Flyr es una aerolínea noruega. Dispone de 5 equipos de desarrollo de unas 6 personas cada uno.
Llevan a cabo releases de manera programada entre cada 2 semanas y 1 mes.
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.
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:
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.
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.
En 2 meses con un nuevo framework.
Añadiendo tests mobile y tests de servicio.