Investigación de Gartner: pruebas de API, virtualización de servicios y pruebas continuas

A medida que maduran las prácticas de desarrollo ágil y los principios de DevOps comienzan a infiltrarse en nuestras culturas corporativas, las organizaciones se dan cuenta de la oportunidad única de acelerar la entrega de software. Sin embargo, cuando acelera cualquier proceso, las áreas de práctica inmaduras y los obstáculos se vuelven mucho más pronunciados. Es la diferencia entre conducir sobre un tope de velocidad a 5 MPH versus 50 MPH… a 50 MPH, ese tope de velocidad va a ser bastante discordante.

Acelerar cualquier proceso comercial expondrá las restricciones sistémicas que encadenan a toda la organización a su componente de movimiento más lento. En el caso del SDLC acelerado, las pruebas se han convertido en la barrera más importante para aprovechar al máximo los enfoques iterativos para el desarrollo de software. Para que las organizaciones aprovechen estas estrategias de desarrollo transformadoras, deben pasar de la automatización de pruebas a las pruebas continuas. Hacer una distinción entre la automatización de pruebas y las pruebas continuas puede parecer un ejercicio de semántica, pero la brecha entre la automatización de las pruebas funcionales y la ejecución de un proceso de prueba continua es sustancial.

Hay muchos matices asociados con la transformación de las pruebas automatizadas a las pruebas continuas. En esta publicación, centrémonos en tres distinciones clave:

• Alinear la "prueba" con el riesgo empresarial
• Acceso ubicuo a entornos de prueba completos
• Automatización de pruebas extrema en la capa de API / mensaje

Alineación de prueba y riesgo empresarial

El cambio más fundamental que se requiere para pasar de lo automatizado a lo continuo es alinear la “prueba” con el riesgo comercial. Especialmente con DevOps y Continuous Delivery, el lanzamiento con velocidad y confianza requiere tener comentarios inmediatos sobre los riesgos comerciales asociados con un candidato de lanzamiento de software. Dado el costo creciente y el impacto de las fallas de software, no puede darse el lujo de lanzar una versión que podría interrumpir la experiencia del usuario existente o introducir nuevas características que expongan a la organización a nuevos riesgos de seguridad, confiabilidad o cumplimiento. Para evitar esto, la organización debe extenderse desde la validación de los requisitos ascendentes hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales.

Acceso ubicuo a entornos de prueba completos

Una de las mayores limitaciones asociadas con el ejercicio de pruebas significativas es acceder a un entorno de prueba completo, que incluye la miríada de sistemas dependientes con los que interactúa la aplicación bajo prueba (AUT). Dada la naturaleza compuesta de las aplicaciones actuales, es casi imposible organizar un entorno de prueba completo. Aquí es donde entra en juego la virtualización de servicios. La virtualización de servicios le permite emular el comportamiento de componentes específicos en aplicaciones heterogéneas basadas en componentes, como aplicaciones impulsadas por API, aplicaciones basadas en la nube y arquitecturas orientadas a servicios. Al simular las interacciones de AUT con las dependencias faltantes o no disponibles, Service Virtualization lo ayuda a garantizar que los datos, el rendimiento y el comportamiento sean consistentes en las diversas ejecuciones de prueba. Además, también le ayuda a "desplazarse a la izquierda" las pruebas para que puedan comenzar mucho antes en cada iteración y exponer los defectos cuando son más rápidos y fáciles de corregir.

Como regla general, debe realizar pruebas en el entorno más parecido a la producción al que pueda acceder ... si no es en producción. Sin embargo, esto generalmente presenta un desafío considerable en términos de costo, seguridad y privacidad. El uso de tecnologías de simulación como la virtualización de servicios le permite eludir las restricciones asociadas con los sistemas dependientes fuera de su control para ejecutar pruebas significativas de un extremo a otro.

Automatización de pruebas extremas en la capa de API / mensajes

Las pruebas en la capa de API / mensajes (servicios, colas de mensajes, capas de abstracción de bases de datos, etc.) ofrecen varias ventajas distintas para habilitar las pruebas continuas a la velocidad de DevOps:

• Estabilidad: si bien las pruebas de GUI a menudo fallan debido a cambios intrascendentes en la aplicación, una falla en el nivel de API / mensaje generalmente indica una falla fundamental en la lógica de la aplicación, algo que probablemente afectará la experiencia del usuario principal. Si está configurando una falla de la suite de pruebas para que sirva como una "puerta" a lo largo de la canalización de implementación automatizada, es importante asegurarse de que cada falla indique un problema verdaderamente espectacular.
• Velocidad: los métodos tradicionales de prueba, que dependen en gran medida de las pruebas manuales y las pruebas de GUI automatizadas que requieren actualizaciones frecuentes, no pueden seguir el ritmo de la velocidad requerida para DevOps. Las pruebas se retrasan hasta que la GUI esté disponible, lo que suele ser un proceso tardío. Además, las pruebas de GUI son notoriamente frágiles y requieren una actualización significativa con cada modificación de la aplicación. Las pruebas de API se pueden definir tan pronto como la descripción del servicio (por ejemplo, Swagger o RAML) esté disponible, se pueden ejecutar mucho antes en el proceso de implementación que las pruebas de GUI y requieren un mantenimiento mínimo.
• Evaluación de riesgos precisa: en las aplicaciones modernas, la funcionalidad expuesta en la capa GUI es solo la punta del iceberg. El núcleo de la lógica de la aplicación está controlado por la capa de mensajes / API. Sin pruebas exhaustivas de las transacciones críticas de los usuarios en la capa de API / mensajes, es difícil estar seguro de que los sistemas altamente distribuidos de hoy en día funcionan realmente como se espera.