Fitch ofrece alta cobertura de código y calidad para aplicaciones de microservicios

Vea una vista previa de la presentación de Fitch en la reciente Cumbre de Calidad y Pruebas de Software Automatizado. Descubra cómo administraron las dependencias para más de 200 microservicios y cómo aumentaron la cobertura del código con las pruebas unitarias.

PRESENTACIÓN COMPLETA DISPONIBLE AQUÍ >>

Los desafios

Fitch tenía tres problemas principales que resolver:

• Tiempo de inactividad no planificado
• Falta de comentarios para los desarrolladores
• Ciclos de lanzamiento rígidos de dos semanas

Tiempo de inactividad no planificado

En 2019, Fitch tuvo 18 incidentes que provocaron la caída de su sitio web debido a roturas en el entorno de producción. Estas interrupciones no planificadas se relacionaron con sus propias API u otros productos que alojan. Dieciocho incidentes promediaron más de una vez al mes. Esas son malas noticias para los acuerdos de nivel de servicio (SLA) y sus clientes.

Falta de comentarios para los desarrolladores

El equipo de desarrollo de software de Fitch Solutions es fluido. Los desarrolladores se mueven de un proyecto a otro, por lo que es común que trabajen y se hagan responsables de microservicios desconocidos para ellos. Agregar funciones a código desconocido fue difícil porque hubo un número bajo de pruebas para ofrecer resultados y ayudar a los desarrolladores a comprender el comportamiento esperado. Además, los expertos en la materia (PYME) a ​​menudo no estaban disponibles para realizar consultas.

Todos estos factores combinados —los desarrolladores que cambian de equipo con frecuencia, no tienen acceso a las PYMES y tienen una cobertura de prueba baja de aproximadamente el 20 %— llevaron a la falta de retroalimentación. La información faltante obstaculizó la capacidad del equipo para mantener los servicios en funcionamiento y agregar nuevas funcionalidades. Es por eso que Fitch tomó medidas para alcanzar un nivel más alto de cobertura de pruebas.

Ciclos de lanzamiento rígidos de dos semanas

Los ciclos de lanzamiento de dos semanas son el proceso de desarrollo estándar en Fitch. Los desarrolladores no pudieron lanzar en su propio horario. Entonces, si el desarrollo de una nueva función se completaba antes del final del ciclo de implementación, tenía que esperar hasta el final del sprint para avanzar al control de calidad. Idealmente, necesitaban poder desarrollar e implementar una función siempre que se implementara y probara. Hacer esto les permitiría lanzar nuevas funciones con más frecuencia y acelerar su tiempo de comercialización.

El enfoque

Fitch Solutions consideró estos tres grandes desafíos y buscó un denominador común entre los tres. Se hizo evidente que los tres estaban relacionados con la falta de pruebas, lo que resultó en una cobertura de código deficiente. Decidieron aumentar la cobertura del código para asegurarse de que estaban probando completamente sus microservicios y ayudar a sus desarrolladores a entregar un mejor código a un ritmo más rápido.

Una buena cobertura de código en un microservicio significa que la mayoría, si no todas, las rutas a través del código se ejecutan. Crear un conjunto de pruebas para cada microservicio que cubra todas las diferentes funciones significa que el código no probado no está expuesto a los clientes. Para cualquier cambio futuro, las pruebas de regresión automatizadas brindan a los desarrolladores retroalimentación instantánea sobre si algo en el código se rompió.

Este enfoque eventualmente reduce las interrupciones. Es más efectivo y eficiente probar la funcionalidad nueva y actual antes de pasar a producción. Este enfoque ayudó a Fitch Solutions a reducir la dependencia de su grupo de control de calidad para organizar y probar nuevas funcionalidades y desacoplar el desarrollo de características del ciclo de lanzamiento de dos semanas.

Un enfoque doble para aumentar la cobertura del código

El plan que ideó Fitch Solutions fue lograr una cobertura de prueba unitaria del 90% (específicamente cobertura de línea). ¡Esta fue una gran tarea ya que tienen más de 200 microservicios! El equipo estuvo a la altura del desafío y utilizó un enfoque doble para abordarlo.

Cree muchas pruebas nuevas

El primer aspecto del enfoque fue aumentar retroactivamente la cobertura de prueba de todo el código existente. Para alcanzar el objetivo de cobertura de código del 90%, necesitaban crear muchas pruebas nuevas. Reunieron un equipo dedicado para abordar esto. El equipo fue responsable de escribir pruebas unitarias exclusivamente para construir la cobertura del código y probar completamente los microservicios existentes de Fitch Solutions.

Siga las pautas de prueba unitaria

El segundo aspecto de este enfoque fue asegurarse de que los desarrolladores que escriben nuevas funciones sigan las pautas de prueba unitaria y logren los objetivos de cobertura del código a medida que se escribe el nuevo código. Estas pautas se aplicaron en toda la organización para que todos los desarrolladores las pusieran en práctica. El equipo introdujo puertas de calidad para garantizar que la calidad del código se fusionara en la rama de producción principal.

Adoptar una herramienta de prueba de Java integrada para lograr objetivos

Para lograr sus objetivos de pruebas, cobertura y calidad, Fitch Solutions adoptó Prueba J de Parasoft. Encontraron particularmente útil utilizar tanto las capacidades de cobertura de código como la asistente de prueba de unidad en Parasoft Jtest. Si los desarrolladores estaban escribiendo nuevas funciones o volviendo a probar servicios heredados, primero midieron la cobertura del código para medir qué tan extensas eran las pruebas existentes. Utilizaron los informes de cobertura de código de Jtest en todos los niveles diferentes para descubrir dónde faltaban sus pruebas, incluida la investigación de la cobertura faltante en el nivel de archivo y línea de código.

El asistente de pruebas unitarias ayudó a Fitch Solutions a llenar el vacío de las pruebas unitarias. Los desarrolladores crearon nuevas pruebas unitarias con solo hacer clic en un botón mientras pasaban el mouse sobre un método en el código. Unit Test Assistant crea un archivo de prueba, un arnés y talones / simulaciones según sea necesario. Los desarrolladores simplemente agregan afirmaciones para verificar el comportamiento y ajustar las simulaciones, y una nueva prueba unitaria está lista.

Todo el equipo aceleró la creación y ejecución de pruebas utilizando Parasoft Jtest. Fue especialmente útil para los desarrolladores junior que necesitaban orientación sobre la creación de pruebas unitarias.

Beneficios de la solución

Fitch Solutions todavía está en su camino para mejorar sus pruebas de software. Ya están experimentando los beneficios de su solución Parasoft.

• Una forma confiable de medir y mejorar la cobertura del código.
• Creación y mantenimiento de pruebas unitarias aceleradas.
• Reducción del tiempo de inactividad.
• Mayor productividad del desarrollador.

Los resultados

Para el tercer trimestre de 3, Fitch Solutions mejoró sus pruebas del 2020% de los microservicios a su objetivo de una cobertura de código del 10%. Aunque todavía están en su camino para alcanzar sus objetivos de cobertura, han pasado 90 días sin ningún tiempo de inactividad en su sistema de producción. Es su racha más larga desde que adoptaron su nuevo enfoque de pruebas unitarias. Vince Recupito, ingeniero de software senior de Fitch Solutions, dijo: “Lo más emocionante es que hemos pasado 100 días sin tiempo de inactividad en nuestro sistema de producción. Algo que estaba sucediendo más de una vez al mes ".

Fitch Solutions se comprometió con una empresa externa que se especializa en medir la productividad de los desarrolladores. El análisis en profundidad utiliza acceso directo a los repositorios de código para medir el historial de confirmaciones y encontrar tendencias y métricas basadas en las actividades de los desarrolladores.

El gráfico anterior se creó a partir de los datos de productividad recopilados que muestran la cantidad promedio mensual de tiempo que los desarrolladores dedican a escribir código por día.

Los datos muestran que el equipo de Fitch pasaba aproximadamente dos horas por día simplemente escribiendo en un teclado, escribiendo código. Se espera que la caída en enero se deba a las vacaciones. La parte interesante es el comienzo de su nuevo esfuerzo de prueba en julio.

En este punto, el equipo estaba revisando sus microservicios heredados, evaluando y aumentando la cobertura del código. También es el punto en el que el equipo insistió en que todas las funciones nuevas se probaran correctamente.

Después de esta caída inicial, el equipo volvió al desarrollo de código a una tasa un 12% más alta que en el mismo período de 2019. Esta fue una buena señal, ya que los desarrolladores dedicaban más tiempo a codificar y menos a reuniones. Sin embargo, la causa principal de este aumento de productividad fue la disminución significativa en el tiempo de inactividad del sistema de producción.

“Una de las conclusiones que sacamos es que nuestros desarrolladores dedican menos tiempo a solucionar problemas de producción y más tiempo a escribir código. Además de eso, a medida que los desarrolladores escriben más pruebas, es de esperar que encuentren errores antes de entrar en el control de calidad ".

—Vince Recupito, ingeniero de software senior de Fitch Solutions

Fitch Solutions no solo vio una reducción en el tiempo de inactividad del sistema de producción, sino también una reducción en la "extinción de incendios" de los desarrolladores para resolver problemas de producción. Además, el nuevo régimen de pruebas tuvo poco impacto en la productividad de sus desarrolladores con un aumento observado en la productividad del 12%.

Además de estas ganancias, los desarrolladores de Fitch Solutions están escribiendo más pruebas y encontrando errores antes, antes de ingresar al control de calidad. Encontrar errores antes también significa menos ida y vuelta con el control de calidad y menos tiempo en el proceso de control de calidad en general.