Mitos acerca de la automatización de pruebas web con Selenium

Los mitos son verdades a medias que normalmente nublan la resolución de problemas concretos en nuestra industria.  Éstos vienen normalmente de la ignorancia de quien los difunde o de quien los cree. En este artículo vamos a intentar derribar para ustedes, algunos mitos que encontrarán frecuentemente para el uso de una tecnología, que bien aplicada, puede aportar a reducir los costos de las pruebas, y aún mejor, incrementar la capacidad de testear un cambio en múltiples plataformas y navegadores aumentando así la cobertura de las pruebas al usar Selenium y/o Appium.

Mito 1: La automatización requiere personal de programación

La suite Selenium provee una herramienta llamada Selenium IDE, gratuita y que funciona como plugin de Firefox o Chrome, y en realidad en todos los nuevos navegadores basados en Chromium. Esta herramienta trabaja sobre la lógica de Record&Play, es decir, se graba una sesión de ejecución, y luego ya está lista para ejecutar.  Esta herramienta no requiere saber lenguaje de programación alguno para usarse (Code less). Se recomienda si, tomar un curso de 10 a 16 horas para poder registrar y ejecutar scripts profesionales.

Mito 2: La automatización solo sirve para regresiones y cuando el cambio ya está listo

Las pruebas end-to-end requieren que exista una interfaz gráfica, es cierto. Sin embargo, nada impide que los mismos desarrolladores, puedan liberar tempranamente versiones de los casos de uso, con una interfaz (GUI o API) esqueleto al ambiente de desarrollo.   En este ambiente, se graban los scripts, y los mismos servirán para que los desarrolladores puedan promover sus cambios testeados hacia el ambiente de QA. Este simple cambio, permitirá adelantar la calidad, hacerla explícita, y además facilitar la prueba en el ambiente de QA.  Esta modalidad se llama normalmente Test Driven Development. La gracia de usar Selenium IDE es que el costo de generación es bajísimo, y en este punto, el hecho de si se van a re-usar en adelante, para regresión, no es tema.

Por otra parte, y cómo dice la página oficial de Selenium, “Selenium automatiza navegadores. ¡¡Eso es!!. Lo que usted haga con él, es completamente cosa suya.”, Selenium permite automatizar labores sobre un navegador, es decir, puede eliminar labores repetitivas, no solamente repetición de casos de pruebas.  Por ejemplo, imagine una empresa con 50 empleados, que diariamente requiere emitir permisos diversos de salida en pandemia para sus empleados en la comisaría virtual.  Una solución rápida, es grabar el flujo de un empleado, depurarlo, y dejar como variables el nombre, rut y destinos, para luego clonar ese script dejando uno hecho para cada empleado.  

Otro ejemplo, es la generación de datos masivos. Hay variadas ocasiones en que se requiere generar datos masivamente “con el sistema” para realizar una prueba digamos de un ciclo de facturación. Para dicho fin, requerimos generar transacciones del negocio en el mes, para luego probar el proceso de facturación.  Selenium IDE cuenta con capacidades de control de flujo (if, while, for) por lo que una solución rápida al problema es grabar un flujo, y luego agregar repeticiones con while o for para obtener los datos necesarios.

Mito 3: Los scripts de Selenium IDE no pueden ejecutar multiplataforma o en CI/CD

Desde hace algún tiempo, Selenium IDE cuenta con ejecutores de línea de comandos, los cuales permiten que los scripts puedan ejecutarse en servidores Selenium grid o Appium generando así un poderoso modelo de ejecución escalable, multi-navegador y multi-plataforma.  Esto es lo que demuestro en el vídeo de este artículo, en dónde se lanza desde un archivo .bat una ejecución en paralelo sobre Chrome y Edge en mi equipo, las que ejecutan 7 pruebas en ambos navegadores (14 en total) en un minuto, labor que a un probador manual hubiera tomado al menos 15 minutos. El modelo demostrado se puede extender para operar en máquinas On Premise o de proveedores de nube como SauceLabs o BrowserStack para acceder a pruebas en diferentes plataformas y dispositivos. Finalmente deci,r que al ejecutarse desde líneas de comando, queda usable en pipelines de compilación y entrega continua como Github o Azure DevOps Server.

Espero que este artículo les apoye en mirar de nuevo esta tecnología como una oportunidad para su carrera, ya que como espero haber dado luces, no es solamente para programadores y testers, incluso los ejecutivos del negocio pudieran sacar provecho en sus operaciones.