• Inicio
  • Blog
  • ¿Y si el Performance Testing se Automatiza Solo?
¿Y si el Performance Testing se Automatiza Solo?

¿Y si el Performance Testing se Automatiza Solo?

"¿Qué pasaría si los scripts de performance testing se diseñaran una sola vez y nunca necesitaran modificaciones? En nuestro último artículo, exploramos cómo parametrizar y variabilizar scripts de pruebas puede transformar la forma en que gestionamos el rendimiento

En cada ocasión en las que estoy diseñando un scrirpt de Performance se que es importante y clave pensar según la escalabilidad y robustez de cualquier aplicación. Sin embargo, con estos scripts, muchas veces se pasa por alto un elemento crucial: la parametrización y variabilización.

Esto último mencionado me ocurrió en un proyecto en el cúal los usuarios querían ver las métricas de sus pruebas en un reporte lo suficientemente user friendly como para ellos poder tomar decisiones con respecto a su producto.

Inicialmente, mi propuesta para ellos fue simple, partamos de reportes html generados desde los resultados de JMeter y vamos implementando métricas en un dashboard de Grafana. Curiosamente aunque yo hice la propuesta, el diseño de los scripts me estaba quitando mucho tiempo, bueno de hecho, eramos varias personas invirtiendo tiempo en esos diseños y allí es cuando solicité el apoyo de un DevOps experto.

Ustedes se preguntarán... y un DevOps para que? No es reponsabilidad de un DevOps diseñar scripts de Performance y en eso tienes toda la razón. Ven y te cuento por qué necesité su apoyo.

Resulta que existe una palabra llamada Operacionalización, que para los que no la conozcan se refiere al proceso de llevar una idea, diseño o modelo a un estado donde sea funcional y pueda ser implementado de manera práctica en un entorno real. En este caso, implica convertir ejecuciones de pruebas de performance que un usuario normalmente no entiende en soluciones prácticas que puedan ser ejecutadas y mantenidas incluso por usuario no ténicos. 

John, no entendí... entonces que se debe de hacer?

Este concepto abarca la implementación de procesos, herramientas y tecnologías que permitan usar los scripts de manera consistente y segura.

Para poder cumplir esto debiamos automatizar la entrega de los scripts implementando su integración en CI/CD, condigurar los ambientes y entornos para que tengan todos los recursos necesarios en el momento de ejecutar los scripts y finalmente tener bien claro el monitoreo y obserbabilidad para poder detectar fallos o evidenciar el comportamiento de dichos resultados.

Con todo lo anterior podriamos documentar todos los procedimientos para que tenga bien soporte a usuarios finales. Y pues si entendieron bien, para todo eso necesité a un DevOps. Sin ese rol no hubiera podido garantizar que una solución técnica como lo son los scripts estén completamente listos para ser utilizados en un entorno operativo por usuarios finales.

Volviendo a mi historia... 

Todo comenzó con la intención de tener una visualización clara de las métricas de performance. Grafana parecía una solución perfecta, permitiendo visualizar tiempos de respuesta, throughput, y métricas críticas para entender el comportamiento del sistema. Sin embargo, conforme se avanzaba en la integración de Grafana, surgió la necesidad de ir más allá del simple monitoreo: la verdadera complejidad radicaba en crear scripts de pruebas que fueran sostenibles y escalables. 

Nota importante. El stack tecnológico que usé en este proceso y motivo por el cual escribí este blog fue: 

  • Jmeter como herramienta de performance
  • Prometheus como base de datos de métricas
  • Grafana como visualizador y reportes
  • Git para el manejo de versiones
  • Groovy para desarrollar código personalizado dentro de los scirpts
  • Java como requisito de ejecución de JMeter
  • Sql Server como base de datos de los datasets creados
  • Protocolos: Rest y GRPC

Al involucrar a un DevOps experto, se hizo evidente que el diseño de los scripts debía evolucionar de ser solo un conjunto de pasos para probar rendimiento a ser un componente esencial de la infraestructura de calidad del software. Esto significa adoptar principios propios de proyectos de software, como la automatización, la reutilización de componentes, y la facilitación del mantenimiento. Esto nos llevó a implementar la parametrización y variabilización, para asegurarnos de que estos scripts fueran lo suficientemente flexibles para ser usados y adaptados por cualquier miembro del equipo.

Y capaz que ustedes se preguntarán ¿Por Qué Parametrizar y Variabilizar un Script de Performance Testing?

La parametrización consiste en la práctica de convertir valores estáticos en variables configurables. Es decir, que el script tenga la minima información quemada en su diseño, nombres de endpoints, puertos, protocolos, datasets, archivos de salida, rutas, bases de datos, payloads, headers, etc.

Esto trae múltiples ventajas como por ejemplo:

  • Facilita la Usabilidad para No Expertos: Los scripts parametrizados permiten a usuarios sin experiencia modificar datos de entrada (como URLs, credenciales, y datos de prueba) sin tener que modificar el código del script. De esta forma, usuarios no técnicos pueden configurar y ejecutar pruebas fácilmente.

  • Mejora el Mantenimiento: Al evitar valores hardcodeados, cualquier cambio en la aplicación puede ser reflejado rápidamente en el script sin necesidad de buscar y reemplazar líneas de código.

  • Escalabilidad y Reutilización: La variabilización permite adaptar el mismo script para distintos entornos (desarrollo, pruebas, producción), sin tener que duplicar scripts, promoviendo la reutilización.

Una vez el DevOps nos sugirió esta idea mi reto era entonces como Tratar los Script como un Proyecto de Software?

Al adoptar la mentalidad de "proyecto de software," se empezaron a aplicar buenas prácticas que son comunes en el desarrollo de software:

  • Archivos de Configuración y Externalización de Variables: Se optó por almacenar configuraciones en archivos externos, como archivos de propiedades eh el JMeter properties o archivos personalizados, de manera que el script pudiese adaptarse a diferentes escenarios sin modificar el código base.

  • Automatización y CI/CD: Los scripts de performance fueron integrados a herramientas de CI/CD con el fin de que los usuarios de cada producto pudiesen ver ejecuciones programadas y de forma automática para poder analizar patrones de comportamiento, analisis de métricas y evolución de su proyecto en terminos no funcionales.

  • Documentación y Buenas Prácticas: El equipo creó una documentación más clara que explicaba cómo ejecutar las pruebas, cómo actualizar los parámetros, y qué esperar de los resultados. Esto hizo que cualquier miembro del equipo pudiese contribuir, incluso sin ser un experto en performance testing.

Gracias a todo este proceso anterior obtuvimos muchos beneficios, mucho mas allá de simples métricas. Esta parametrización y variabilización en el diseño de los scripts transformó la manera en que se realizaban las pruebas. Nos ayudó a Reducción del Tiempo de Mantenimiento, crear un entorno mas accesible e integrar multiples herrramientas para tener un proceso reactivo.

Moraleja ...

Lo que comenzó como una simple visualización de métricas con Grafana se transformó en un cambio completo de mentalidad sobre cómo se debe tratar el performance testing dentro de un proyecto. Parametrizar y variabilizar scripts de pruebas no solo hace el proceso más eficiente, sino que permite que más miembros del equipo participen, sin importar su nivel de experiencia técnica.

Esta evolución no solo tiene beneficios a corto plazo, como un mantenimiento más sencillo, sino que también sienta las bases para un enfoque más colaborativo y proactivo en cuanto a la calidad y el rendimiento de los sistemas.

SI TE GUSTÓ Y QUIERES APRENDER MÁS....

Bienvenido al Ecosistema más Poderoso de Pruebas de Rendimiento

  1. Si quieres aprender a CREAR UN PROYECTO DE PERFORMANCE TESTING DESDE CERO, Bienvenido a la MENTORIA PERFORMANCE 360
  2. Si quieres aprender sobre la IMPORTANCIA DE PERFORMANCE TESTING en los proyectos de desarrollo de Software desde la experiencia de los referentes más importantes en la industria, Bienvenido al PODCAST EFECTO PERFORMANCE
  3. Si quieres aprender HERRAMIENTAS, FUNDAMENTOS y BUENAS PRÁCTICAS, Bienvenido a JOHN PERFORMANCE, mi CANAL DE YOUTUBE
  4. Si quieres pertenecer a la COMUNIDAD DE PERFORMANCE TESTING en Español, Bienvenido al CANAL DE DISCORD
  5. Si quieres matenerte INFORMADO, CONECTADO, en EVENTOS, NOTICIAS, TENDENCIAS, CHARLAS, etc... Bienvenido a mi PERFIL DE LINKEDIN
  6. Si quieres CLASES GRATIS DE PERFORMANCE TESTING, BONOS DE DESCUENTOS, el ROADMAP de Performance Testing, Bienvenido a tus REGALOS GRATUITOS
  7. Si quieres conocer el DIA A DIA DE UN PERFORMANCE TESTER, Bienvenido a mi BLOG DIARIO DE UN PERFORMANCE

Mi deber y mi pasión es fortalecer y potencializar el conocimiento de PERFORMANCE TESTING en toda la región. Podría hacerlo solo pero no tendría mucho sentido. refiero hacerlo con ustedes. Juntos llegaremos más lejos.

"¿Qué pasaría si los scripts de performance testing se diseñaran una sola vez y nunca necesitaran modificaciones? En nuestro último artículo, exploramos cómo parametrizar y variabilizar scripts de pruebas puede transformar la forma en que gestionamos el rendimiento

Te puede interesar
Cerrar X