X
BLOG

Las aplicaciones en la nube se inician más rápido. ¿La automatización de pruebas también puede alcanzar la velocidad de escape?

Las aplicaciones en la nube se inician más rápido. ¿La automatización de pruebas también puede alcanzar la velocidad de escape? Tiempo de leer: 5 minutos

Sería difícil encontrar una empresa viable que no tenga ninguna estrategia de migración a la nube.

Las empresas de vanguardia adoptarán un enfoque de todo o nada para esta migración, insistiendo en que todas las funciones comerciales deben resolverse eventualmente en el consumo de algún tipo de nube elástica, ya sea en un IaaS líder como AWS o Azure, o en las instalaciones o a medida. sabores de la nube privada.

Incluso los rezagados del mercado tienen un plan para mover al menos una aplicación a una instancia en la nube bajo demanda: sumergir un dedo del pie en el agua antes de dar el paso.

Las empresas pueden acelerar el desarrollo y modernizar el entorno de entrega utilizando la nube, pero una cosa nunca cambia: los clientes aún esperan que el software funcione y se desempeñe como se espera en la producción, sin importar dónde se implemente.

Necesitan que las aplicaciones sean altamente disponibles, seguras y resistentes, o se irán a otra parte. Eso deja la automatización de pruebas como una función de activación crítica para el éxito.

Cuando la tasa de lanzamiento de la nube supera las pruebas

Una empresa de servicios financieros de Global 500, John Hancock, anunció recientemente el lanzamiento de un estimado Proyecto de transición de 142 millones de dólares a una IaaS de nube privada

No se equivoque, gran parte de ese presupuesto no son tarifas de la nube, es mano de obra. La reestructuración de las aplicaciones empresariales para la nube, obviamente, no es una tarea fácil. Se requiere una enorme cantidad de trabajo para integrar, probar y validar continuamente las aplicaciones, y este trabajo a menudo se repite cuando se mantienen las pruebas después de cada versión.

Pero eso no es nada nuevo. Estos costos de reelaboración ciertamente existían antes de la nube.

¿Qué cambió? La tasa de lanzamiento está aumentando exponencialmente en un entorno de nube moderno. Los equipos de DevOps están utilizando definiciones de infraestructura como código (IaC), integración rápida basada en servicios y feeds de datos, canalizaciones de implementación automatizadas y contenedores que se ejecutan en cualquier lugar.

En un discurso de apertura de KubeCon, la ingeniera de operaciones de Airbnb, Melanie Cebula, dijo que su equipo está lanzando más de 20,000 lanzamientos en contenedores a la semana, ¡y eso fue hace un año! Si bien es probable que la mayoría de las empresas nunca toquen las velocidades de Netflix y Airbnb del mundo, todavía estamos buscando un aumento de mil veces en la velocidad de implementación para cualquier empresa que haga los entornos de nube correctamente.

Entonces, ¿dónde deja eso al resto del mundo, a las empresas que no nacieron en la nube?

Cualquier desarrollador senior o ingeniero de pruebas reconoce que el código en sí mismo representa una responsabilidad. Cuanto más código escriba, más tendrá que probar ese código, y más código de prueba tendrá que escribir y mantener a lo largo del tiempo.

Alcanzar la velocidad de escape ya no es una cuestión de aumentar la velocidad de las implementaciones y lanzamientos, si no podemos abordar el coeficiente de arrastre de mantener el código de prueba que lo acompaña.

Alcanzando la velocidad de escape contra el cambio

A medida que las empresas adoptan el movimiento DevOps, recurren a potentes canalizaciones de automatización para la automatización de la implementación del entorno y el lanzamiento continuo en arquitecturas dinámicas en la nube.

Las pruebas deben ser un aspecto de primera clase de esa canalización. Si no se prueba el software en un entorno realista temprano y con frecuencia, las fallas resultantes que aparecen en la producción pueden ser demasiado costosas de corregir.

La mayoría de los grupos de pruebas y desarrollo utilizan una combinación de herramientas comerciales y código abierto, cuando es práctico, para la automatización de pruebas y la burla de las dependencias (también conocida como "virtualización de servicios"). . La herramienta de automatización de pruebas web de código abierto más popular es Selenio, que permite a los probadores reproducir flujos de trabajo basados ​​en navegador a través de un sistema bajo prueba.

Si bien los elementos centrales de Selenium han existido durante años, la actividad de los socios y las contribuciones de los desarrolladores al proyecto se han intensificado últimamente. Durante los últimos 3 a 5 años, Selenium se ha convertido en parte de la cadena de herramientas de la mayoría de los equipos de desarrollo y pruebas empresariales.

No importa cuántas pruebas de rendimiento, integración y nivel de código ejecute el equipo de software, las pruebas funcionales desde la perspectiva del usuario con herramientas como Selenium siguen siendo el final del juego. Probar repetidamente una interfaz de usuario web en todos los navegadores y dispositivos de destino es fundamental para el éxito.

Ahora, la repetibilidad, ahí es donde las cosas se ponen complicadas. Cuando la lógica empresarial y los datos de back-end se representan dinámicamente en la interfaz de usuario web en tiempo de ejecución, se produce una cantidad infinita de anomalías en la pantalla que rompen los scripts de prueba de Selenium, ya sea que hayan sido capturados navegando o modificados manualmente por los probadores.

Por ejemplo, los elementos pueden cargarse en diferentes posiciones en la página, o en un orden diferente, o contener valores de datos o imágenes que están fuera de las expectativas del script de prueba de Selenium.

Los probadores y los SRE (ingenieros de confiabilidad del sitio o del servicio) pueden intentar crear controladores personalizados para tener en cuenta las fallas falsas, ajustando el código para permitir la flexibilidad a lo largo de ciertos parámetros, pero en poco tiempo, será imposible confiar en los resultados de cualquier conjunto de funciones funcionales mantenidas manualmente. pruebas, debido a cambios subyacentes en la arquitectura back-end de la nube que nunca dejan de generar inconsistencias en una UI web dinámica.

Haga que las pruebas sean tan resistentes como la arquitectura

¿Cuál es la mejor manera de contrarrestar la constante superación de las pruebas de aplicaciones por parte de la nube? ¡Aplique el mismo principio de DevOps de 'automatizar todo' al mantenimiento de la automatización de pruebas en sí!

Si bien existen algunas herramientas de automatización patentadas en el mercado que cubren todo el ciclo de vida de la prueba, también existen enfoques que aumentan las capacidades de los probadores que utilizan herramientas de código abierto.

Una importante corporación de viajes se enfrentaba exactamente a ese desafío cuando comenzó a migrar una aplicación de programa de lealtad crítica para el negocio de los clústeres de servidores heredados existentes a una instancia de aplicación en la nube reservada con capacidades de desbordamiento de la nube pública.

La versión inicial se probó por completo y fue bastante exitosa, pero a medida que se agregaron clientes adicionales en el transcurso de tres versiones más, sus primeras series de pruebas de Selenium estaban comenzando a fallar a un ritmo muy alto. El costo laboral de cambiar las pruebas, así como el aumento de los costos de la nube debido al uso redundante de la computación, estaban comenzando a proporcionar una visión de gestión negativa del proyecto.

Afortunadamente, pudieron recurrir a Parasoft Selenic una herramienta para mejorar sus conjuntos de pruebas de Selenium, aplicando un enfoque basado en inteligencia artificial para interpretar los objetos en la página y 'autocurativo' las pruebas para adaptarse a las condiciones cambiantes observadas en la interfaz de usuario web.

Este nivel de resistencia de las pruebas redujo los costos de mantenimiento de las pruebas de la empresa hasta en un 75 por ciento, al tiempo que les permitió completar su lanzamiento con Selenium y Selenic dos semanas antes con mucho menos riesgo de falla en el futuro a medida que avanza la migración.

La toma Intellyx

Las empresas tienen claras intenciones de trasladar las aplicaciones a la nube, pero las consecuencias y los costes del traslado son mucho menos claros.

Si va a modernizar los monolitos existentes y lanzar nuevas funciones más rápidamente para satisfacer las necesidades del cliente, aún debe realizar muchas pruebas funcionales y de regresión. Tantas pruebas, de hecho, que incluso los ingenieros de pruebas más hábiles y eficientes no pueden codificar y ejecutar suficientes pruebas para mantenerse al día.

Asegurar la resistencia de las pruebas, al tener pruebas que pueden probarse a sí mismas y curarse a sí mismas, es la única forma en que las pruebas pueden seguir el ritmo de los rápidos cambios que trae la nube.

A continuación: Evitar el drama de código abierto: mitigar el riesgo de desarrollar con software de código abierto.

Escrito por

Jason Inglés

Jason English es Analista Principal y CMO en Intellyx, donde asesora a los principales proveedores de soluciones tecnológicas y a las nuevas empresas de software mientras navegan por la transformación digital. Su experiencia incluye experiencia del cliente y diseño interactivo, ciclo de vida de desarrollo / prueba de software empresarial, virtualización, nube y blockchain.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft