Pruebe de manera más inteligente, no más difícil: cambie las pruebas hacia la izquierda y hacia la derecha con el análisis de impacto de la prueba

El análisis de impacto de las pruebas significa centrar las pruebas específicamente en los cambios realizados durante cada iteración y probar exactamente lo que se debe probar de forma automática. Los equipos que aprovechan esta tecnología pueden optimizar su esfuerzo de pruebas en desarrollo con comentarios instantáneos sobre lo que se debe hacer.

Confirmado con frecuencia por encuestas e informes de la industria, las pruebas de software siguen siendo un cuello de botella, incluso después de la implementación de procesos de desarrollo modernos como Agile, DevOps y Continuous Integration / Deployment. En algunos casos, los equipos de software no están probando lo suficiente y tienen que lidiar con errores y vulnerabilidades de seguridad en las últimas etapas del ciclo de desarrollo, lo que crea una falsa suposición de que estos nuevos procesos no pueden cumplir su promesa. Una solución para ciertas clases de problemas es la prueba de cambio a la derecha, que se basa en monitorear la aplicación en un entorno de producción, pero requiere una infraestructura sólida como una roca para revertir nuevos cambios si surge un defecto crítico.

Como resultado, las organizaciones aún no cumplen con los plazos y la calidad y la seguridad se ven perjudicadas. ¡Pero hay una forma mejor! Para realizar pruebas de forma más inteligente, las organizaciones están utilizando tecnología llamada análisis de impacto de prueba para entender exactamente qué probar. Este enfoque basado en datos admite tanto prueba de desplazamiento a la izquierda y pruebas de cambio a la derecha.

Agile y DevOps y el cuello de botella de las pruebas

La prueba en cualquier proceso iterativo es un compromiso de cuántas pruebas se pueden realizar en un tiempo de ciclo limitado. En la mayoría de los proyectos, es imposible hacer una regresión completa en cada iteración. En su lugar, se realiza un conjunto limitado de pruebas y exactamente qué probar se basa en las mejores conjeturas. Las pruebas también se cargan en el ciclo, ya que generalmente no hay suficientes funciones nuevas completadas para probar. El gráfico resultante de esfuerzo versus tiempo termina como un diente de sierra, como se muestra a continuación en la Figura 1. En cada ciclo, solo se ejecuta un conjunto limitado de pruebas hasta que el ciclo final está completo. pruebas de regresión es interpretado.

Desafortunadamente, ningún proyecto llega al ciclo final sin errores y sin vulnerabilidades de seguridad. Encontrar defectos en esta etapa agrega retrasos a medida que los errores se corrigen y se vuelven a probar. E incluso   esos retrasos y todo, muchos errores todavía se abren camino en el producto implementado, como se ilustra a continuación.

Esta situación ha dado lugar a la adopción de lo que se ha denominado “pruebas de desplazamiento a la derecha”, en las que las organizaciones continúan probando su aplicación en la fase de implementación. La intención de las pruebas de desplazamiento a la derecha es aumentar y extender los esfuerzos de prueba, siendo las pruebas más adecuadas en la fase de implementación, como el monitoreo de API, la alternancia de funciones en producción y la recuperación de comentarios de la operación de la vida real.

¿Qué es la prueba de desplazamiento a la derecha?

Las dificultades para reproducir entornos de prueba realistas y utilizar datos y tráfico reales en las pruebas llevaron a los equipos a utilizar entornos de producción para monitorear y probar sus aplicaciones. Existen beneficios para esto, por ejemplo, poder probar aplicaciones con tráfico de producción en vivo que admiten tolerancia a fallas y mejoras de rendimiento. Un caso de uso común es el llamado lanzamiento canario, en el que una nueva versión del software se lanza primero a un pequeño subconjunto de clientes y luego se implementa a un grupo cada vez más grande a medida que se informan y solucionan los errores. Roku, por ejemplo, hace esto para actualizar el firmware de su dispositivo.

Las pruebas de cambio a la derecha se basan en una infraestructura de desarrollo que puede revertir una versión en caso de defectos críticos. Por ejemplo, una vulnerabilidad de seguridad grave en una versión canary significa revertir la versión hasta que esté lista una nueva versión actualizada, como puede ver en la ilustración aquí:

Pero existen riesgos al usar entornos de producción para monitorear y probar software y, por supuesto, ¡La intención de las pruebas de cambio a la derecha nunca fue reemplazar las prácticas de prueba de la unidad, la API y la IU antes de la implementación! La prueba de cambio a la derecha es una complementario práctica, que extiende la filosofía de las pruebas continuas a la producción. A pesar de esto, las organizaciones pueden abusar fácilmente del concepto para justificar la realización de menos pruebas unitarias y de API durante el desarrollo. Para evitar esto, debemos realizar pruebas durante las fases de desarrollo para que sean más fáciles, más productivas y produzcan software de mejor calidad.

Pruebas más inteligentes, no más difíciles, al enfocar sus pruebas

La mayoría del software no está completamente probado, y la decisión de qué probar se basa esencialmente en las mejores conjeturas de los desarrolladores sobre qué es la funcionalidad crítica. Durante un sprint SCRUM, o una iteración en otros procesos, es difícil determinar qué probar, porque, por supuesto, "probar todo" no es una opción. Dado que los plazos son cortos, solo se pueden probar partes del software que se actualizaron con la última funcionalidad, pero generalmente se desconoce exactamente qué código se ve afectado. La automatización de pruebas ayuda, pero sin comprender exactamente dónde y qué probar, la cobertura de prueba es inadecuada.

Análisis de impacto de prueba

Estas deficiencias se pueden superar utilizando análisis de impacto de prueba, que es un análisis multivariado de la cobertura de la prueba, los cambios de código y las dependencias que identifica exactamente qué código debe probarse. Además, estas pruebas exactas se pueden programar y ejecutar automáticamente.

El análisis de impacto de prueba funciona a nivel de desarrollador dentro del IDE, recopila información sobre qué código se ejerce mediante qué pruebas, y aplica esa información dentro del IDE del desarrollador a medida que el desarrollador cambia el código, lo que permite al desarrollador identificar y ejecutar fácilmente las pruebas específicas que debe ejecutarse para verificar que el código modificado no interrumpe ninguna prueba. Además, realizar un seguimiento de las pruebas afectadas que se han ejecutado, las que han pasado y las que han fallado, facilita al desarrollador determinar qué pruebas aún deben ejecutarse o qué pruebas han fallado y deben abordarse. Una vez que todas las pruebas se han ejecutado y están aprobadas, el desarrollador sabe que es seguro enviar su código y seguir adelante.

El análisis de impacto de prueba funciona dentro de un proceso de CI / CD al integrarse sin problemas en el sistema de construcción de un proyecto, como Maven o Gradle, para obtener comentarios inmediatos sobre los cambios. El análisis de impacto de la prueba identifica qué código ha cambiado desde la compilación de referencia (es decir, la compilación de la última noche), determina qué pruebas deben ejecutarse para ejercitar ese código y luego ejecuta solo ese subconjunto de pruebas. Este flujo de trabajo permite a los equipos configurar trabajos de CI que solo ejecutan pruebas en función de los cambios de código más recientes, lo que reduce la cantidad de tiempo que lleva ejecutar un trabajo de CI de horas a minutos.

El análisis de impacto de las pruebas proporciona los siguientes beneficios clave:

• Comprenda lo que cubre cada prueba. Al correlacionar automáticamente los datos de ejecución de la prueba con los datos de cobertura de la prueba, el análisis de impacto de la prueba proporciona un mecanismo para identificar qué pruebas deben ejecutarse, según el código que se está desarrollando actualmente. Los usuarios ahorran tiempo sin tener que ejecutar pruebas innecesarias y los equipos se benefician de la retroalimentación inmediata durante el desarrollo y después del registro del código.
• Comprende lo que ha cambiado. Los desarrolladores a menudo no saben qué pruebas ejecutar para validar los cambios de código, por lo que (a) verifican su código sin ejecutar ninguna prueba (una muy mala práctica), (b) ejecutan solo una o dos pruebas que conocen ( que fácilmente pasa por alto algunos), o (c) ejecutar todas sus pruebas (lo que pierde tiempo). El análisis de impacto de las pruebas resuelve esto identificando inmediatamente qué pruebas están relacionadas con qué código cambia, y da un paso más al ejecutarlas automáticamente. El código registrado se vuelve más estable ya que se ha probado minuciosamente antes del registro.
• Céntrese en pruebas que validen los cambios y las dependencias afectadas. Identificar y ejecutar solo el conjunto de pruebas necesarias para verificar todos los cambios de código y las dependencias afectadas, que se han comprometido desde la última compilación de línea de base (generalmente la compilación nocturna), disminuye significativamente la cantidad de tiempo que lleva ejecutar CI. Esto permite que los equipos se beneficien de un verdadero proceso de CI.
• Retroalimentación inmediata y continua. Al identificar no solo las dependencias directas entre las pruebas y el código, sino también las dependencias indirectas, el análisis de impacto de las pruebas ayuda a los equipos a comprender lo antes posible después de que se verifica el código si el código rompió alguna prueba.

Resumen

Para disminuir en gran medida el cuello de botella de las pruebas en el desarrollo y mejorar la eficiencia del esfuerzo de “dientes de sierra” que los probadores ponen en cada iteración, los equipos de desarrollo pueden beneficiarse de la tecnología de análisis de impacto de pruebas. La automatización de pruebas con análisis de impacto de pruebas significa centrar las pruebas específicamente en los cambios realizados durante cada iteración y probar exactamente lo que se debe probar de forma automática. Estos equipos optimizan su esfuerzo de prueba en desarrollo con comentarios instantáneos sobre lo que se debe hacer, qué código falla en la prueba y qué otro código se ve afectado por los nuevos cambios.