Hablando de Azure Load Testing (preview)

Una de las cosas que no he comentado por aquí es que desde hace pocos meses he estado probando el nuevo servicio Azure Load Testing, el cual podríamos considerar como la evolución del proyecto (ya deprecado) Load Testing Pipeline with JMeter, ACI and Terraform, que también estuve probando a mediados del año pasado, ambas herramientas tienen como propósito la gestión automatizada de infraestructura para ejecutar pruebas de performance sobre nuestras aplicaciones, basándonos en un modelo estándar como es JMeter

La verdad lo que trae el nuevo servicio es alucinante: monitoreo en paralelo de los recursos de Azure involucrados, comparación de resultados entre tests previos, integración con Azure DevOps y GitHub Actions, etc, por lo que para conocer con detalle las novedades y lo que podemos hacer con Azure Load Testing hace poco tuve la oportunidad de participar en el Meetup mensual de la comunidad DevOps Perú, así que les comparto el video, mi participación esta desde el minuto 1:21.


Aprovecho para comentar las ideas fuerzas principales alrededor de este servicio:

  • A la fecha de escribir este post, el servicio aun esta en preview, pero eso no debería ser limitante para empezar a configurar nuestros planes de prueba y ejecutarlos, pues si bien no hay un SLA definido, considero (muy personalmente) que el riesgo es menor que con un servicio que si se publica de cara a nuestros usuarios.
  • Debemos recordar siempre de escribir nuestros scripts .jmx considerando que van a correr dentro de un entorno Linux, lo cual implicara una ligera adaptación si nuestras pruebas actuales están configuradas para ser ejecutadas desde PCs con Windows.
  • El limite de cada engine es de 250 hilos por segundo, por lo que si queremos golpear nuestra app a 1000 veces por segundo deberemos provisionar 4 engines simultáneos.
  • Otro detalle a considerar es que en esta preview el numero máximo de engines que se pueden provisionar en paralelo es 45.
  • Y la consideración mas critica, en este momento, es que el servicio no asigna un controlador para los engines inicializados, esto significa que si en la prueba subo un archivo .csv (para pruebas con data) de (digamos) 100 filas, y lanzo 2 engines, las filas se enviaran en su integridad a los dos engines, con lo cual tendremos 200 llamada a la aplicación a validar, si contáramos con un controlador, cada engine hubiera recibido 50 filas, pues el controlador estaría repartiendo la carga entre sus hijos. Esperemos que Microsoft mejore este detalle, pero por mientras debemos tener en cuenta la limitante que esto representa.

Bueno, espero que el video les haya sido interesante y que ya empiecen con sus pruebas! Ya saben dejen un comentario con sus opiniones que serán bien recibidas.

Los “equipos” QA en la ecuación DevOps

Puede que en el nombre del movimiento este el problema: Dev y Ops, desarrollo y operaciones, lo cual tiene a poner a nuestras amigas QA(*) fuera del radar de esta tendencia, pero a poco de pensarlo bien debemos darnos cuenta de que ya están ahí… si es que hacemos las cosas adecuadamente, me explico.

Se espera que el software que desarrollamos y que se entregue tenga calidad (y ojo, no nos olvidemos que la calidad no es negociable) así que entra en acción el proceso de QA, tests, ratificación o ya en plan sofisticado “certificación”, pero lamentablemente en la gran mayoría de los casos estas pruebas se efectúan al final de cada etapa de desarrollo, a veces en un entorno dedicado, a veces en preproducción y otras (felizmente muy pocas) en el propio entorno de desarrollo, volviéndose un ejercicio incremental, pues como en cada ciclo o iteración de desarrollo se añaden nuevas funcionalidades (con suerte Historias de usuario) el equipo QA tiene que probar todo, incluyendo lo que se probo hace unas semanas, no vaya a ser que se caiga en una de las temidas “regresiones” y algo ya validado deje de funcionar.

Ah, ¿y se han percatado que dije “equipo QA”?, ¿no les causa ruido? pues esto es indicativo de que ese proceso esta vinculado a personas diferentes a la labor de desarrollo, asi que de generar sinergias ni hablar.

Pues si, lo usual, incluso en equipos que se denominan “agiles”, pero como bien nos recuerda Javier Garzas no se puede ser agil si se prueba en cascada, pues lo que hemos descrito anteriormente es efectivamente un proceso en cascada lo cual nos lleva a algo que tenemos asumido desde hace tiempo (y es parte de la raíz de este modo de trabajar en QA): el “ritual” del pase a entornos: descarga de ultima versión (si es que todo esta bien sincronizado), separar los archivos modificados, asegurarse de que los archivos de configuración este Ok, copia de archivos, reiniciar entornos… etc, y si el pase es a producción ya mejor ni hablar: gran amanecida bailable con desayuno incluido.

¿ Y del lado de QA esta forma de trabajar como les afecta? Simple: el entorno donde probar no esta actualizado de manera frecuente, asi que hay un gran delay entre el tiempo en que Desarrollo entrega nueva funcionalidad o corrige bugs y el que QA puede “verlos”, eso de manera evidente. Pero aun hay mas, como mencionaba al principio la validación es manual e incremental dándose el caso que vi de una QA que en cada iteración debía validar la aplicación contra una tabla de valores para verificar que los resultados siguieran siendo los esperados ¿no habría una forma de reducir el trabajo repetitivo de tal manera que el esfuerzo de las pruebas inevitablemente manuales se centre en las nuevas funcionalidades y lo que respecta a la validación de usuario?

Si que la hay, y ya hemos hablado frecuentemente de ello, tender a la Integración y Entrega Continua, buenas practicas (vitales del movimiento DevOps a fin de entregar valor constantemente) que facilitan y a la vez requieren el tener pruebas automatizadas que se ejecuten frecuentemente, acotando lo manual a lo necesario, pero mas aun: facilitando el que se caigan las barreras entre QA y Dev al generar (¡al fin!!!) equipos multidisciplinarios (y no bandos en pugna **) que se den feedaback periódicamente.

Pero aun hay mas, y esto nos lleva al titulo de este post, el escenario DevOps abre una gran oportunidad para QA de asumir liderazgo en este proceso, pero para lo cual algunas cosas deben de cambiar (como nos indica el enlace anterior):

Empoderar a QA para que recomiende o determine las herramientas (de automatización y pruebas)
Que QA migre a una mayor estrategia de tests
Dar a QA una mayor visibilidad dentro de la hoja de ruta
Cambiar QA a un enfoque mas productivo que reactivo
Permitir a QA evangelizar y educar en DevOps

devops_01Pero si, este cambio no es fácil, estamos hablando de una “cultura” ya establecida, que si ya nos esta costando evolucionar en tanto a la adopción del agilismo, por el lado de la forma de trabajar con QA existen retos diferentes:uno el trabajar como departamento separado, lo cual como recordamos anteriormente nos aleja del desarrollo de sinergias, pilar de lo que es DevOps;  por otro lado el hecho de que buena parte de quienes trabajan en QA se acercaron a dicha área porque de esa manera no tendrían que programar, si, esa es la verdad y es una pena, pero buena parte de la automatización de pruebas requiere habilidades de programación y esto es algo que ha venido para quedarse; y finalmente el factor económico, se asume erróneamente que introducir a QA desde la concepción del proyecto es un error por el costo que esto implica (asumiendo de partida que las pruebas se harán “al final”), siendo que el costo de tratar de corregir la falta de calidad en estadíos tardíos es mucho mayor que el que involucra trabajar con pruebas y alcances claros desde el principio.

El reto esta puesto, QA es totalmente necesario para lograr sinergias y entregar valor desde el principio, tal vez el propio nombre “DevOps” no ayuda a recordar que QA es parte del proceso, pero si que lo es, sin esa vital pieza no tenemos la figura completa. Espero sus opiniones para ver como podemos mejorar este proceso.

Referencias adicionales:
Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad
Cuándo deberías hacer los pasos a producción dentro de un Sprint o iteración

(*)Si, en esta profesión tan bonita que es la informática se da el fenómeno que el sector de QA es terreno femenino en su gran mayoría, pero eso da para otra historia.

(**) Un QA tenia en su estatus la siguiente frase “Todo QA debe tener un corazón de desarrollador, guardado en un frasco”