Las herramientas low code para automatización de casos de prueba están ganando cada día más terreno. ¿Por qué? La respuesta es simple: por eficiencia. Conoce en este post en qué consiste este enfoque, y mira nuestra evaluación comparativa de las soluciones más populares.

Existe una tendencia creciente a aplicar este enfoque sobre todo para la automatización de pruebas a nivel de interfaz de usuario. Sus plataformas permiten desarrollar soluciones tecnológicas en menos tiempo, y con una menor curva de aprendizaje que con los enfoques de programación clásicos.

En Abstracta nos dispusimos a realizar algunos experimentos, con el objetivo de comparar el tiempo de ejecución de diferentes plataformas.

Si bien las soluciones que presentan estas plataformas son más que prometedoras, siempre hay un trade-off: no podemos ceder en tiempo de ejecución de pruebas, necesitamos que los ciclos de feedback sean rápidos. 

Es sabido que cuanto más rápido recibamos feedback, mejor. Eso también se aplica a las pruebas automatizadas end to end. En esta nota, compartimos los resultados de un benchmark que ejecutamos para comparar la velocidad de algunas de las soluciones de low code más conocidas para la automatización de pruebas.

Si querés reproducir el experimento, no te pierdas nuestro análisis y la explicación del paso a paso para lograrlo. Si solo querés conocer los resultados, entrá directamente a la sección Resultados del benchmark: conclusiones y observaciones.

¿Por qué es importante contar con una rápida automatización de pruebas de UI?

Como parte de la estrategia de prueba, se pueden automatizar casos de prueba que serán capaces de proporcionar feedback sobre el posible impacto en el sistema de los cambios más recientes en el código. El escenario típico es que al terminar un cambio se desea verificar si podría dañar otras partes del sistema (tests de regresión). 

La idea es tener los resultados de la revisión del estado de calidad en unos minutos, especialmente en los pipelines de CI/CD. Si el ciclo de retroalimentación es demasiado largo, vamos a pasar a otra cosa y cambiar de contexto. Volver a lo que estábamos haciendo se vuelve más costoso, ya que requiere más tiempo y esfuerzo.

Entonces, supongamos que definimos que la prueba de regresión queremos que no dure más de 5 minutos. Cuanto más rápido la herramienta de automatización pueda ejecutar las pruebas y proporcionar los resultados mejor, porque vamos a poder agregar más casos de prueba a la suite de regresión en el mismo límite de tiempo y aumentar la cobertura.

También es importante mencionar que para las pruebas de regresión probablemente sea conveniente ejecutar las pruebas unitarias, pruebas a nivel de API y algunas pruebas de interfaz de usuario con el objetivo de tener una cobertura end to end de los flujos más críticos de la aplicación. Hay que tener en cuenta que lo que suele suceder es que se pueden ejecutar miles de pruebas unitarias en segundos, cientos de pruebas API en un minuto y algunas pruebas de interfaz de usuario pueden tardar varios minutos.

Evaluación comparativa de las soluciones low code para automatizar más populares

Las plataformas de low code para la automatización de pruebas tienen como objetivo simplificar la automatización de pruebas con funcionalidades que no requieren que el usuario escriba ningún código. Vas a tener un recorder que te permite crear fácilmente casos de prueba y editarlos con una interfaz simple sin necesidad de conocimientos de codificación. 

En los últimos años, han surgido nuevas soluciones de low code para la automatización de pruebas. Algunas de ellas son Functionize, GhostInspector, Katalon, Kobiton, Mabl, Reflect, Testim, TestProject, y la lista crece cada día.

Hace unos meses, Testim lanzó una nueva funcionalidad llamada “turbo mode”, que permite ejecutar los casos de prueba en un modo más rápido. Para esto, se ejecutan los casos sin guardar todos los datos que normalmente se almacenan. La mayoría no suelen ser necesarios, como los logs de la red, de la consola y las capturas de pantalla de todos los pasos en ejecuciones exitosas (sí se almacenan resultados cuando el caso de prueba reporta un error). Ellos afirman que pueden ejecutar entre un 25% y un 30% más rápido que las ejecuciones de prueba estándar de Testim. En el mismo artículo, también aseguran que “compararon sus pruebas con otras herramientas de low code y lograron resultados en menos de la mitad del tiempo que las otras alternativas”.

Quisimos probar si esas afirmaciones eran ciertas. Pensamos que podría ser un buen experimento para aprender y compartir los resultados con la comunidad, realizando una comparación y creando un punto de referencia entre las soluciones de low code más populares para la automatización de pruebas.

Detalles del experimento

Veamos cómo se diseñó el experimento antes de discutir sus resultados.

Decidimos comparar las siguientes plataformas de low code:

• Testim (con y sin el turbo mode). 
• Mabl. 
• Functionize.
• TestProject.

También queríamos comparar Katalon ya que es una alternativa popular, pero no brinda soporte nativo en la nube. Lo mismo sucedió con TestProject, pero fue muy fácil integrarlo con SauceLabs, por lo que decidimos incluirlo de todos modos.

Nos enfocamos en comparar el tiempo que lleva ejecutar una prueba en la nube, ya que este es el escenario típico en el que se ejecutan las puebas desde el motor de CI. Otro aspecto a mencionar es que Testim, Mabl y TestProject te permiten ejecutar localmente, por lo que también comparamos los tiempos de ejecución locales, debido a que a menudo se ejecuta la prueba localmente al hacer debug 

Las pruebas en local las ejecutamos en la misma computadora, para minimizar la variabilidad y que no afecte los resultados.

Especificaciones de la computadora portátil para pruebas locales:

• Sistema Operativo: Windows 10 Inicio.
• Modelo: ASUS VivoBook 15.
• Procesador: AMD Ryzen 7 3700U 2,3 GHz.
• Memoria: 8GB.
• Conectividad: Wifi y Fibra, accediendo desde Uruguay.

Para mantener el experimento lo más simple posible, decidimos enfocar nuestro tiempo en la comparación entre diferentes herramientas pero no en las diferentes estrategias de diseño de prueba.

Diseñamos un solo caso de prueba con una longitud típica, tal como lo tendrían muchos proyectos reales. Es importante resaltar que diseñamos la prueba para incluir diferentes tipos de elementos en la interfaz de usuario para interactuar, llenar campos de texto, hacer clic en botones, validar textos y más. 

Luego de esto, automatizamos el mismo caso de prueba en cada herramienta. Decidimos ejecutar la prueba 10 veces en cada una, para que nuestra comparación sea justa y para reducir el impacto de los outliers.

A pesar que la mayoría de las herramientas ofrecen ejecutar la prueba en diferentes navegadores, realizamos las pruebas con Google Chrome para simplificar, ya que no era nuestro objetivo comparar el rendimiento del navegador. 

Investigamos diferentes sitios de demo para usarlos como sistema bajo prueba y decidimos usar Demoblaze, que lo provee Blazemeter como sitio de capacitación para su herramienta de pruebas de performance. Este sitio nos pareció adecuado para el experimento ya que no pertenece a ninguna de las empresas que estábamos evaluando, es estable y rápido, por lo que hay menos riesgo de que afecte los resultados de nuestro análisis. Además es similar a un sitio de e-commerce real y tiene la complejidad suficiente para nuestro objetivo.

El caso de prueba se definió siguiendo estos pasos:

1. Acceder a https://www.demoblaze.com/.
2. Hacer clic en el título del primer elemento de la lista (Samsung galaxy s6).
3. Verificar que el título del producto sea “Samsung galaxy s6”.
4. Hacer clic en el botón “Agregar al carrito”.
5. Hacer clic en “Aceptar” en la ventana emergente que dice que se agregó el producto.
6. Hacer clic en “TIENDA DE PRODUCTOS” para volver a la página de inicio.
7. Hacer clic en el menú “Carrito” en la parte superior derecha.
8. Hacer clic en el botón “Hacer pedido”.
9. Rellenar cada uno de los campos con una “x”.
10. Hacer clic en el botón “Comprar”
11. Validar el mensaje “¡Gracias por tu compra!”.
12. Hacer clic en el botón “Aceptar”.

En las siguientes capturas de pantalla, se puede ver cómo se representa el script de prueba en algunas de las herramientas que estamos comparando.

Testim con un enfoque muy gráfico:

TestProject con un estilo de scripting muy simple:

Es importante mencionar que para automatizar la prueba con Functionize tuvimos que buscar un workaround utilizando JavaScript para localizar algunos elementos que la herramienta no podía encontrar por sí misma.

Resumiendo:

• Apuntamos a comparar Testim, Mabl, TestProject y Functionize.
• Automatizamos un solo caso de prueba que incluye diferentes tipos de acciones (validaciones, llenado de campos de texto, clic en botones). Sistema bajo prueba: Demoblaze.
• Las ejecuciones locales siempre se ejecutaron en la misma computadora (para todas las herramientas que brindan ejecución local).
• Todas las pruebas se realizaron con Google Chrome.
• Ejecutamos el caso de prueba 10 veces en cada configuración para normalizar los resultados.

Resultados del benchmark: conclusiones y observaciones

El conjunto completo de datos se puede descargar aquí. La siguiente tabla y gráficos resumen los resultados. Realizamos un análisis estadístico para verificar que los conjuntos de datos fueran significativamente diferentes. Te recomendamos ver más sobre la importancia en el análisis de resultados de performance en este artículo.

Observación 1: en nuestro experimento, Testim turbo mode fue, en promedio, un 27 % más rápido que la ejecución estándar de Testim. Eso significa que no pudimos refutar lo que afirmaron en su artículo.

La misma información es más fácil de analizar y comparar en un gráfico como el siguiente:

Comparemos las ejecuciones solo en local:

Si bien el resultado más importante es el tiempo que lleva ejecutarse en la nube, porque ahí ejecutaremos nuestras pruebas en nuestros pipelines, también queríamos comparar los tiempos de ejecución en local, ya que eso afectará nuestro tiempo para depurar los scripts de prueba.

Observación 2: Mabl fue la ejecución local más rápida con un 22% más que la siguiente herramienta más rápida.

Para simplificar la comparación de las diferentes herramientas en la nube, prestamos atención solo al promedio de las ejecuciones del experimento:

Observación 3: Testim fue el más rápido en la ejecución de la nube. En promedio, Testim fue entre un 79% y un 87% más rápido que las otras herramientas ejecutando el mismo caso de prueba. Dicho de otra manera, en el tiempo que Mabl (el segundo más rápido en este experimento) puede ejecutar el caso de prueba solo una vez, podría ejecutar la misma prueba casi 5 veces con Testim. Además, Mabl fue casi el doble de rápido que TestProject y Functionize.

Cabe mencionar que no comparamos cómo la latencia podría afectar los resultados. 

Algunas observaciones adicionales:

• Es muy fácil aprender a automatizar con una herramienta de low code, especialmente una vez que ya aprendiste a usar una de ellas. Nos impresionó que pudiéramos transferir nuestro conocimiento de una herramienta de automatización low code a otra. 

Por ejemplo, pudimos registrarnos, grabar un caso de prueba y ejecutarlo con Mabl sin ningún aprendizaje adicional específico de la herramienta. Aunque tenemos experiencia con Selenium, nos podría haber llevado al menos un par de horas configurar el entorno, preparar el framework y ejecutar las pruebas. Más aún, configurarlo para ejecutarlo en un grid, generar  reportes de prueba atractivos, preparar la solución para conectarla en un entorno de CI/CD, etc.

• En la mayoría de las herramientas, realmente no se pierde flexibilidad en comparación con las soluciones basadas en código como Selenium, ya que normalmente hay un mecanismo para inyectar código si la situación lo requiere. Por ejemplo, tuvimos que agregar algo de JavaScript en la prueba de Functionize para automatizar algunas acciones que la herramienta no era capaz de hacer al momento de automatizar.

• Si bien es cierto que alguien sin habilidades de programación puede ser muy bueno para automatizar casos de prueba con estas herramientas, tener experiencia ayuda a mejorar a estructurar la prueba, aplicar buenas prácticas para la modularización, el control de versiones, etc.

---

Como nota final, no podría haber escrito de desarrollo low code este artículo sin la ayuda de Juan Pablo Rodríguez y Federico Martínez, de Abstracta, quienes prepararon la mayoría de los guiones y recopilaron los resultados.

¡Síguenos en Linkedin, Facebook, Twitter, Instagram y Youtube para enterarte de más novedades sobre herramientas para testing automatizado!

---

Otros contenidos relacionados

Cómo elegir la mejor Herramienta de Automatización en 5 simples pasos

Mabl: Primeros pasos con la Herramienta de Testing Automatizado

Mejores sitios web de prueba para practicar diferentes tipos de tests