Descubra cómo la Orquestación Universal agiliza el trabajo, acelera las decisiones y escala la automatización. Regístrese hoy mismo para el seminario web.
Un Marco de Pruebas Automatizadas usando ProcessMaker + Selenium + Github
En la era moderna actual de desarrollo de software, todos los equipos de desarrollo de software bien administrados deben comprender el valor de las pruebas. Las nuevas aplicaciones deben construirse con una cobertura de pruebas unitarias casi perfecta para la automatización de pruebas. Además, las pruebas funcionales basadas en navegador deben automatizarse completamente utilizando herramientas de código abierto como Selenium para capturar patrones conocidos de interacción humana.
Los desafíos de incorporar pruebas funcionales en CI/CD
Los casos de uso funcionales tienden a evolucionar con el tiempo y cambian con regularidad a medida que crecen y evolucionan los casos de uso de un conjunto de software. Como resultado, muchas empresas luchan con cómo ejecutar un conjunto en constante evolución de pruebas de Selenium como parte de un pipeline automatizado de pruebas y despliegue.
En particular, en el mundo actual del software SaaS, muchas aplicaciones SaaS multiinquilino tienen suites completas de pruebas de Selenium que deben ejecutarse antes de que se aprovisione un nuevo inquilino. Estas pruebas deben ejecutarse como parte del pipeline automatizado del aprovisionamiento real del inquilino.
La realidad, sin embargo, es que la mayoría de las empresas SaaS no hacen esto. El resultado se manifiesta como inconsistencias constantes durante el aprovisionamiento de inquilinos o en la nube privada.
Entonces, ¿cuál es la solución?
Aunque Selenium es una forma eficaz y popular de automatizar pruebas basadas en navegador, las organizaciones necesitan una forma de automatizar la inclusión de conjuntos de pruebas de Selenium debidamente versionados en los pipelines de implementación.
ProcessMaker es una solución ideal para automatizar un pipeline de implementación y aprovisionamiento de pruebas de Selenium directamente desde sus repositorios en Github. Veamos cómo se puede hacer esto.
Suites de pruebas de Selenium en Github
Imagine por un momento una empresa que tiene un conjunto de pruebas automatizadas de Selenium que se almacenan como archivos de Python en GitHub. Estos archivos de Python deben ejecutarse cada vez antes de que se aprovisione un nuevo inquilino de espacio de trabajo o una instalación en la nube privada. Si alguno de los casos de prueba falla, queremos asegurarnos de que el aprovisionamiento no continúe.
Además, reconocemos que los casos de prueba cambiarán y evolucionarán constantemente. En este caso, tenemos varios equipos que desean poder contribuir con pruebas a un repositorio versionado, y queremos asegurarnos de que nuestras pruebas de Selenium siempre se ejecuten utilizando la versión más reciente, estable y aprobada de las pruebas.
En este caso, las pruebas se realizarán con Selenium. Por supuesto, Selenium es una herramienta de código abierto extremadamente popular que utilizan los desarrolladores en todo el mundo. Con Selenium, puede automatizar todas las tareas de su navegador. Además, admite Chrome, Firefox, Safari, IE y Mozilla.
En ProcessMaker hemos creado un flujo de trabajo de implementación que extrae el arnés de prueba de Selenium apropiado de github, lo ejecuta, verifica problemas y, si todo pasa, llama a una función Lambda para implementar un nuevo servidor AWS con el código verificado.
ProcessMaker nos brinda una representación visual del flujo de trabajo, la capacidad de rastrear el rendimiento, el tiempo y los errores. Aquí está el aspecto del flujo de trabajo para una empresa que actualmente utiliza ProcessMaker de esta manera:
La flexibilidad es clave para la gestión de pruebas. ProcessMaker facilita la reagrupación y refactorización de casos de prueba para que pueda mejorar la mantenibilidad mientras disminuye la complejidad y la duplicación. Con las herramientas fáciles de usar de ProcessMaker, puede reducir el tiempo de ejecución de las pruebas e incluso ejecutar varias pruebas en paralelo.
Usando ProcessMaker, las pruebas de Selenium se extraen del repositorio de código y se ejecutan a través de una serie de tareas de script en ProcessMaker que canalizan la prueba a través de una imagen Docker de Selenium y luego almacenan los resultados de la prueba en la Solicitud.
Parte de la belleza de ProcessMaker es que administra los datos como un objeto Json muy ligero, no estructurado y fácil de entender. Durante la vida de una solicitud (una instancia de proceso), este Json puede recibir datos de muchas fuentes diferentes. En el caso de las pruebas de Selenium, los resultados que se devuelven de las pruebas de Selenium simplemente se agregan al objeto Json. Luego, dependiendo de cómo se suponga que funcione nuestro flujo de trabajo, podemos usar reglas externas o puertas de enlace para evaluar los resultados y cambiar lo que sucede en el flujo de trabajo.
Para ilustrar, ProcessMaker se puede configurar para ejecutar acciones de seguimiento basadas en los resultados de las pruebas que devuelven resultados == “éxito”. En la puerta de enlace, evaluamos la variable de resultados. Si los resultados fueron exitosos, entonces hemos configurado el flujo de trabajo para llamar a una nueva tarea de script que es la función lambda que usamos para iniciar un nuevo inquilino (espacio de trabajo). Si los resultados muestran “fallo”, entonces no procederemos con la creación del inquilino. En ese caso, podríamos querer publicar detalles del fallo en un canal de Slack o por correo electrónico utilizando conectores en ProcessMaker para Slack o Email.
Al usar ProcessMaker como un arnés de prueba de esta manera, podemos probar cualquier aplicación personalizada antes de implementarla en un servidor para un cliente. Obtenemos flexibilidad en flujos de trabajo complejos y la capacidad de escalar y lanzar pruebas bajo demanda.
Ejecución de procesos a través de la API de ProcessMaker
Dado que la ejecución de procesos puede ocurrir a través de llamadas API, el uso de ProcessMaker puede formar parte de sus pipelines de CI/CD. Si se implementa o actualiza un entorno, el pipeline de CI/CD puede ejecutar una llamada a la API REST contra ProcessMaker para comenzar a ejecutar una suite de pruebas basada en la carga útil de la solicitud de llamada a la API.
Al usar un proceso de CI/CD, obtiene cierres de problemas más rápidos porque tiene una identificación y corrección de errores más rápidas. Además, la planificación y ejecución de pruebas se mantiene de manera consistente. No se requieren habilidades técnicas. La implementación es más fácil y rápida con casi ningún tiempo de inactividad. Se pueden crear aplicaciones de mayor calidad porque tiene más tiempo para centrarse en la usabilidad, la seguridad, las pruebas exploratorias y de rendimiento. La retroalimentación continua también mejora la calidad general.
Ejecución de subprocesos
Se puede diseñar un proceso simple para ejecutar una sola prueba de Selenium y devolver el resultado. Una suite de pruebas puede ser un proceso principal que recorre la ejecución de una suite de pruebas definida y realiza decisiones de flujo de trabajo más complejas basadas en los resultados.
En su núcleo, el ProcessMaker workflow engine es altamente personalizable. Puede rastrear las pruebas con total transparencia. Algunos de los beneficios incluyen lo siguiente:
Mejor eficiencia de pruebas
Disminución de costos de mantenimiento
Cobertura de pruebas optimizada
Poca intervención manual necesaria
Reutilización de código
No se requiere experiencia en automatización de pruebas
Pruebas basadas en Selenium contenerizadas con tareas de script
Las Tareas de Script se ejecutan en contenedores Docker durante el ciclo de vida de ese script. Podemos aprovechar la imagen Docker de Selenium para ejecutar una prueba con aislamiento en sandbox. También podemos personalizar la imagen Docker para heredar de la imagen base de Selenium y luego proporcionar un andamiaje para cargar la prueba y ejecutarla, lo que devuelve los resultados en un formato JSON adecuado que ProcessMaker espera.
¿Por qué ProcessMaker prefiere JSON? Bueno, para empezar, JSON es más legible y compacto que XML, lo que facilita el trabajo con sistemas complejos. Dado que JSON utiliza menos datos que XML, el análisis del software es mucho más rápido. JSON también facilita la asignación de tiempo a objetos de dominio. La estructura de mapa de datos de JSON también es fácil de entender. Además, JSON garantiza la correspondencia de objetos y códigos.
Escalado
La ejecución de las suites de pruebas se realiza bajo demanda y se puede configurar como una implementación de entorno único o a gran escala (actualizaciones de varios entornos). Puede escalar fácilmente la ejecución de suites de pruebas utilizando la infraestructura de escalado automático de ProcessMaker.
Almacenamiento de suites de pruebas como código
La intención es almacenar la definición de una suite de pruebas como un archivo JSON en un repositorio de código de GitHub. El archivo JSON definirá las pruebas a ejecutar, y cada prueba se almacenará también en el repositorio de código. Esta utilización de repositorios de código git para almacenar suites de pruebas nos permite aprovechar el branching y otras características de git para controlar y administrar las suites de pruebas. Esto también permite la ejecución de dichas pruebas, sin el uso de ProcessMaker, localmente para fines de desarrollo y depuración.
Entonces, ¿por qué usamos GitHub? Honestamente, porque el wiki y el rastreador de problemas de GitHub nos brindan la retroalimentación y la documentación detallada que requerimos. Además, puede rastrear revisiones en múltiples versiones. Además, en términos de control de versiones, nos encantan las capacidades de branching de Git. A través de las funciones de branching, puede trabajar en un entorno aislado para cada cambio que necesite hacer en su base de código. Dado que GitHub utiliza un sistema de control de versiones distribuido, cada persona que trabaja en el mismo proyecto puede tener su historial completo guardado en su propio repositorio localizado. Además, si dos colaboradores realizan cambios en el mismo archivo, GitHub combinará inteligentemente las modificaciones. También es bastante fácil revertir a una versión específica. En general, permite un ciclo de lanzamiento más rápido y GitHub funciona a la perfección con entornos de CI/CD.
Conclusión
Al seleccionar una herramienta de prueba automatizada, debe buscar una que sea ágil y ofrezca soporte para una amplia gama de idiomas y aplicaciones. Esto permitirá que su equipo contribuya a sus ciclos de prueba sin necesidad de habilidades técnicas.
BOAT, APO, BPM, iPaaS, UO: Una guía de campo para la sopa de letras de orquestación
Un Marco de Pruebas Automatizadas usando ProcessMaker + Selenium + Github
Orquestación Universal: Qué es, por qué importa y cómo lograrla
La orquestación universal está surgiendo como la respuesta, brindando a las empresas una forma más inteligente de gobernar flujos de trabajo, procesos impulsados por IA y toma de decisiones humanas a escala.
