¿Qué prácticas son relevantes en las pruebas de rendimiento continuo actualmente? Hablamos de este tema con un panel de especialistas formado por Roger Abelenda, Andréi Guchin, Sofia Palamarchuk, Paul Holland, Andy Hohenner y Eric Proegler.

Muy pronto, en octubre, se realizarán dos importantes conferencias sobre testing de software: WOPR y Quality Sense Conf. ¿Por qué son tan relevantes? Porque gracias a este tipo de eventos, expertos y expertas en software de todo el mundo pueden establecer contactos, forjar redes y compartir ideas, en pos del desarrollo de software de calidad.

Uruguay, un país de aproximadamente 3 millones y medio de habitantes, se encuentra entre los principales exportadores de software del mundo. Tiempo atrás, Financial Times informó de que existen más de 1000 empresas de desarrollo de software activas en Uruguay: “Están generando casi 1000 millones de dólares en exportaciones, en su mayoría a Estados Unidos. Eso lo convierte en uno de los principales exportadores de software per cápita del mundo”.

Cada vez es más habitual referirse a Uruguay como el “Silicon Valley de Sudamérica”. Según el informe Digital Rise Report 2021, Uruguay fue el mayor Digital Riser de América Latina y el Caribe durante los últimos 3 años. ¿Qué es un Digital Riser? El término refiere a países que han logrado elevar su competitividad digital y ver esto reflejado en sus economías.

El reporte es elaborado por el European Center for Digital Competitiveness cada tres años: analiza la competitividad digital de 140 países con información del Foro Económico Mundial, el Banco Mundial y la Unión Internacional de Telecomunicaciones.

Globalmente, hay un público cada vez mayor en todo el mundo interesado en aprender más sobre el testing de performance y la calidad del software. Entonces aquí estamos, indagando en todo ello a través de esta saga que llamamos “Testing de performance a fondo”, con el objetivo de tender puentes y ampliar el conocimiento en la búsqueda de crear software de calidad.

Para este artículo, nos enfocamos en las prácticas de Continuous Performance Testing, con las opiniones de un panel de especialistas compuesto por Paul Holland, Andy Hohenner y Eric Proegler, organizadores de WOPR29; Roger Abelenda, Chief Technology Officer de Abstracta; Andréi Guchin, líder del hub de Performance Hub de Abstracta; y Sofía Palamarchuk, co-CEO de Abstracta y CEO de Apptim.

El sitio web de WOPR indica que la generación de carga sintética es capaz de proporcionar beneficios predictivos que son difíciles de conseguir de otra manera. En este contexto, ¿qué prácticas son relevantes actualmente en Continuous Performance Testing?

Andy Hohenner: Eso es parte de lo que espero explorar en este WOPR. Existen prácticas como las pruebas de observabilidad, la instrumentación de pruebas automatizadas, monitorización y pruebas sintéticas, etc. Pero ninguna de ellas nos proporciona la visión a futuro de los datos de performance a escala que ofrecían las pruebas de carga de la vieja escuela.

Eric Proegler: En el caso del software bajo desarrollo, queremos saber si estamos mejorando las cosas, o al menos no las estamos empeorando. Las cargas controladas (en contraposición a las “realistas”) pueden encontrar información para confirmar, y nueva información que podemos obtener con seguridad sin arriesgar la imagen de marca y los ingresos. Verificar nuevas arquitecturas y modificación de componentes en una fase temprana puede ser muy valioso para lograr un buen rendimiento en el sistema.

En cuanto a la escalabilidad, la inyección de carga y las pruebas del sistema integrado pueden ayudarnos a descubrir problemas que no queremos encontrar más tarde en producción. A un cierto nivel de fiabilidad, la “ingeniería de reinicio de servicios” (o en inglés, el “Service Restart Engineering”) puede ayudarnos a llegar a 99.99 en promedio de disponibilidad (uptime), pero eso no es suficiente para todos los contextos. Incluso cuando lo es, hay que explorar los efectos de la carga puntual. El autoescalado no es inmediato y los sistemas de soporte operativo también necesitan verificación.

Roger Abelenda: Hay muchas prácticas que son relevantes y que pueden utilizarse para asegurar el rendimiento de un sistema bajo diferentes cargas.

La generación de carga sintética sigue siendo relevante, ya que nos permite verificar el rendimiento de la aplicación para anticiparnos a posibles cargas futuras, como por ejemplo los Black Friday. Además, nos posibilita analizar perfiles conocidos con una preparación adecuada, y monitorizar en el lugar y reproducirlo de forma sencilla para evaluar ajustes de configuración o correcciones en el código, etc. En el contexto de Continuous Performance Testing, la generación de cargas sintéticas permite verificar que el comportamiento de un sistema se mantiene en rangos aceptables bajo un escenario conocido mientras el propio sistema cambia en cada iteración, ya sea por cambios de código, configuración o infraestructura.

Además, se pueden aplicar otros tipos de pruebas como las de resiliencia (a través de la ingeniería del caos), la velocidad de subida y bajada de la escalabilidad de la infraestructura, etc.

En Continuous Performance Testing, creo que la práctica clave es versionar los scripts de pruebas de performance. Cuanto más cerca esté el versionado del código bajo prueba, mejor (idealmente: que las pruebas de performance estén en el mismo repositorio que el código bajo prueba)a. Mantener el versionado de las pruebas de performance cerca del versionado del código bajo prueba nos permite rastrear fácilmente los cambios en ambos lugares, revertir fácilmente en caso de cualquier problema potencial, aplicar correcciones al código de producción y verificar fácilmente con las pruebas adecuadas para dicha versión.

Además, fomenta la colaboración entre los desarrolladores y los testers de performance (por ejemplo, a través de la práctica de la revisión del código), un equipo verdaderamente multidisciplinario, y no 2 equipos que tratan de sincronizar en los sprints.

Andréi Guchin: Para complementar la respuesta de Roger, y alineado con las arquitecturas de microservicios, otra práctica relevante en Continuous Performance Testing es ejecutar las pruebas de performance para cada sistema de forma aislada y en forma integrada. Al igual que con las pruebas funcionales, es esencial probar cada componente de forma aislada para verificar que funcione correctamente y obtener bucles de retroalimentación rápidos, mediante el uso de mocks o servicios virtuales.

Al mismo tiempo, también es importante probar la integración con otros sistemas en pasos posteriores, para verificar que la funcionalidad o el rendimiento no se vean afectados en el entorno integrado debido a la red, el escenario especial ejercitado en la integración u otros factores.

Asimismo, es de especial relevancia contar con entornos adecuadamente representados y reproducibles para ejecutar dichas pruebas de rendimiento de forma continua, donde la infraestructura como código y los entornos desechables juegan un papel más importante que el que solían desempeñar en el pasado, cuando las pruebas de rendimiento se realizaban de forma puntual.

A diferencia de las pruebas de rendimiento “tradicionales”, para las pruebas de rendimiento continuas no es tan importante tener un entorno similar al de producción para ejecutar las pruebas, sino la capacidad de reproducir exactamente el mismo entorno a lo largo de los diferentes sprints para tener comparaciones de resultados eficaces.

Por último, tener un informe de resultados adecuado y fácil de usar con toda la información importante para obtener conclusiones útiles relacionadas con el rendimiento es algo que hay que tener en cuenta cuando se ejecuta este tipo de pruebas. La mayor parte de las veces nadie va a supervisar las pruebas mientras se ejecutan, por lo que es esencial contar con un buen informe para entender después lo que ha sucedido.

Sofía Palamarchuk: En cuanto a las pruebas de rendimiento durante el ciclo de desarrollo de software (en inglés conocido como software development life cycle), hay diferentes tipos de comprobaciones que se pueden hacer para garantizar que las regresiones de rendimiento se detecten a tiempo y se aborden.

Qué tipo de pruebas de rendimiento es más relevante en la Integración Continua (CI) depende del objetivo final del software bajo prueba y de lo que sea más crítico para el negocio.

Lo mínimo sería comprobar automáticamente el tiempo de respuesta de todas las solicitudes y la experiencia de usuario de los principales flujos de usuario. Esto requiere analizar el rendimiento en múltiples entornos (navegadores, dispositivos móviles, conexiones de red, etc.). Dado que esto se hace de forma continua (cada vez que se lanza una nueva versión del software y pasa por el pipeline CI), es fundamental que estas pruebas estén automatizadas, se ejecuten en el mismo entorno controlado y sean rápidas. Como resultado, podemos detectar antes la degradación del rendimiento (regresiones) y tomar las medidas adecuadas.

¿Estás buscando un partner para realizar testing de software? Abstracta es una de las empresas más confiables del mundo en ingeniería de calidad de software. Contáctanos y conversemos sobre cómo podemos ayudarte a hacer crecer tu negocio.

Síguenos en LinkedIn, X, Facebook, Instagram y YouTube para ser parte de nuestra comunidad!