EDICOM y su ecosistema integrado para la automatización de pruebas

Sebastián Morcillo e Ignacio Serna, QA Automation Engineers en EDICOM, nos muestran la importante labor que realiza nuestro Departamento de Calidad y Testeo. En este artículo, profundizan acerca del ecosistema de tecnologías que empleamos para lograr la máxima calidad en el desarrollo de nuestro software.

    Artículo elaborado por:

    Ignacio Serna

    QA Automation Engineer

    Especializado en desarrollo de herramientas de QA y automatización de testeos. Motivado por el mundo del CI/CD y la mejora de la calidad en procesos de desarrollo de software.

    Sebastián Morcillo

    QA Automation Engineer

    Especializado en la automatización de pruebas y desarrollo de herramientas para la mejora de los procesos. Apasionado por las nuevas tecnologías que nos rodean día a día.

Introducción

La calidad del software es uno de los aspectos más importantes del ciclo de vida del desarrollo. Puede garantizar la entrega continua de software y mitigar los inevitables riesgos que conlleva su desarrollo.

En este artículo, hablaremos del ecosistema de tecnologías utilizado por EDICOM para hacer frente a los retos que se plantean en el mundo de la calidad del software.

Contexto

Desde hace algunos años, EDICOM ha apostado por la prestación de sus servicios a través de una arquitectura en la nube. Esto ha traído consigo algunas consecuencias como la rapidez en la distribución de nuevas aplicaciones y servicios y su uso desde diferentes dispositivos, sistemas operativos y navegadores.

En el Departamento de Calidad, esta «potenciación» en términos de entrega y disponibilidad de software también tuvo sus implicaciones.

La principal consecuencia fue que la implementación de pruebas automatizadas era casi obligatoria. Había que probar las integraciones de la API con los servicios, las aplicaciones web siempre cambiantes y su rendimiento, y llevarlo a los procesos de despliegue continuo. Todo ello de forma programada que, junto a la persistencia de los resultados, nos permitiera llevar un control del estado de nuestros servicios así como su monitorización.

En este contexto es donde surge el siguiente ecosistema de tecnologías para lograr estos objetivos:

Infraestructura del ecosistema de pruebas

La construcción se divide en cuatro partes, cada una con un propósito específico:

  • EDICOM Automated Test Framework: Es una herramienta propia desarrollada en Typescript que encapsula Jasmine permitiendo implementar y ejecutar pruebas.
  • CI/CD: Como herramienta de gestión de código fuente y CI/CD utilizamos GitLab.
  • Informes: Corresponde a la gestión de los resultados de la ejecución. Para ello, se utilizan dos servicios: un gestor de informes y un visor para monitorizar el estado de los pipelines (Automonitor). La comunicación entre las distintas partes se realiza a través de una API siendo la columna vertebral de esta entidad.
  • Persistencia: Esta pieza del puzzle corresponde a la persistencia de los datos, es decir, los informes generados para cada ejecución de pruebas (ElasticSearch, MySQL y ELTA).

En las próximas secciones hablaremos de cómo funciona esta arquitectura y qué tecnologías utilizan las diferentes entidades.

EDICOM Automated Test Framework

ecosistema integrado de EDICOM

Antes de adentrarnos en las facilidades que proporciona el framework de test, es importante destacar el tipo de pruebas automatizadas que realizamos para los productos EDICOM. Existen 3 tipos principales:

  • Pruebas funcionales: pruebas enfocadas a verificar el correcto funcionamiento de los diferentes casos de uso del producto. Incluimos tanto las pruebas de la API como las del frontend.
  • Pruebas de rendimiento: pruebas enfocadas a verificar que el rendimiento del software es correcto y no disminuye con las actualizaciones/modificaciones.
  • Pruebas de accesibilidad: pruebas enfocadas a verificar que los productos cumplen con los estándares de accesibilidad WCAG.

Las pruebas de rendimiento y accesibilidad no están implementadas bajo el paraguas del framework de test y serán tratadas en otros posts.

Conocido internamente como EDICOM Automated Test Framework, es la parte del ecosistema a través de la cual se desarrollan y ejecutan las pruebas automatizadas de extremo a extremo que realizamos (pruebas funcionales). Está construido en Typescript y ejecutado en Node.js, a través del cual se integran diferentes librerías clave como utilidades. Estas tecnologías se encapsulan gracias al patrón de diseño llamado adaptador. En lugar de añadir las tecnologías y utilizarlas directamente en nuestros proyectos, lo que hacemos es definir una interfaz para acceder a las funciones de la librería. Esto asegura la flexibilidad en posibles migraciones de tecnología y simplifica la lógica. Las principales tecnologías son:

  • Como motor para la implementación de las pruebas E2E utilizamos el runner Jasmine. Es el núcleo principal a través del cual creamos, ejecutamos y validamos este tipo de pruebas.
  • Otra tecnología clave es Axios. Es un cliente HTTP basado en Node.js. Como ya hemos comentado, el framework se encarga de encapsular las utilidades de las librerías que integra. En este caso, tenemos una clase que se encarga de todo lo relacionado con las peticiones HTTP. Desde la construcción de las cabeceras y el cuerpo hasta el procesamiento de las respuestas. Lo más interesante es que esta clase es capaz de abstraer la construcción de las peticiones SOAP y REST, es decir, evita la necesidad de construir las peticiones de forma diferente según sea SOAP o REST. De esta forma, se simplifica enormemente la realización de peticiones a los servicios de EDICOM desde los proyectos de prueba, lo que es muy utilizado en los proyectos de prueba de APIs.
  • Por otro lado, para las pruebas de nuestras aplicaciones web, utilizamos la reciente herramienta de Microsoft llamada Playwright. Se trata de un marco de trabajo que permite la ejecución en múltiples navegadores y plataformas a través de una API que interactúa con el navegador.
  • Además de estas tecnologías, el marco de pruebas está repleto de pequeñas librerías que proporcionan diversas funcionalidades como la compresión en diferentes formatos, la comparación de archivos .pdf, el envío y recepción de correos electrónicos así como el envío de archivos a través de los protocolos FTP y SFTP. Gracias a ellas podemos probar la amplia gama de servicios que ofrece EDICOM.

Al mismo tiempo, el entorno cuenta con otras utilidades como una herramienta autogeneradora de proyectos, u otra que nos permite ejecutar proyectos de forma ágil. Estas consisten en una serie de instrucciones interpretadas por la línea de comandos para generar y lanzar proyectos.

Volviendo al diagrama, esta parte del ecosistema se conecta con dos piezas clave: el gestor de informes y GitLab. La primera de estas relaciones se encarga de enviar los resultados de las pruebas a un servicio que los almacena y muestra en una página web. La conexión con GitLab es obvia. Necesitamos almacenar los proyectos en un repositorio de código que además nos permita programar sus ejecuciones.

En las siguientes secciones discutiremos ambas partes del diagrama.

CI/CD

Utilizamos GitLab como repositorio de código, control de versiones y herramienta CI/CD. Gracias a GitLab podemos definir pipelines que ejecuten proyectos de forma programada y así hacer un seguimiento del estado de los servicios.

Por otro lado, al estar GitLab basado en Git, nos permite añadir nuestros proyectos como submódulos en los servicios. Con esto, podemos definir pasos adicionales en los pipelines que se lanzan en los despliegues de nuevas versiones del servicio. En estos pasos adicionales es donde ejecutamos la suite de pruebas del servicio, permitiéndonos revertir el despliegue en caso de que las pruebas fallen.

Todos los resultados de las ejecuciones del pipeline se envían a un servicio de monitorización del que hablaremos más adelante.

Servicio de informes

Esta parte del diagrama se encarga de supervisar los conductos y los resultados de la ejecución del proyecto. Se compone de tres partes distintas: la API de informes, la web de informes y la herramienta de monitorización (Automonitor). A continuación hablaremos de todas ellas.

La API de informes es una de las partes más importantes de todo el ecosistema. Su función es almacenar y recuperar los resultados de las ejecuciones del proyecto. Está construida bajo el framework Nest.js y utiliza TypeORM para mapear objetos a bases de datos MySQL. Su principal consumidor es el framework de test, donde en cada ejecución se almacenan los resultados en el gestor de informes.

La siguiente aplicación clave en esta parte del diagrama es la página web de informes. Construida en Angular, se encarga de mostrar los resultados de las diferentes ejecuciones de cada proyecto de forma visual e intuitiva. Para cada una de las pruebas que componen la ejecución de un proyecto, las llamadas HTTP que se han lanzado se almacenan en el gestor de informes y luego son consumidas por la página web. Profundizando, para cada llamada HTTP se almacenan las cabeceras y el cuerpo de la petición y la respuesta.

Así, en resumen, cuando accedemos al informe de un proyecto veremos el resultado de cada una de las pruebas. Para cada una de ellas, todas las llamadas HTTP lanzadas con sus respectivas peticiones y respuestas.

Posteriormente, durante un caso de uso real veremos las imágenes de esta página web.

Por último, disponemos de una aplicación para monitorizar internamente los pipelines de GitLab conocida como «Automonitor«. Una vista de cuadrícula muestra el estado de ejecución de los pipelines de los diferentes proyectos agrupados por etiquetas. El valor de esta aplicación es que de un vistazo se puede ver si los últimos cambios en los servicios han introducido errores o no.

Otras funcionalidades que contiene esta aplicación son relanzar los pipelines sin necesidad de acceder a GitLab o mostrar el último informe generado para cada proyecto y así ver por qué ha fallado.

Como antes, durante el caso de uso veremos imágenes de esta aplicación.

Persistencia

ecosistema integrado de EDICOM

En cuanto a la persistencia de la información con la que trabajamos en todo el ecosistema, utilizamos tres tecnologías diferentes en función de los datos que queramos persistir.

Toda la información de las llamadas HTTP (cabeceras, parámetros, cuerpo o URL) se almacena en ElasticSearch. Se elige esta tecnología debido al gran tamaño de estos datos en algunos casos.

Por otro lado, utilizamos MySQL para mantener las tablas que representan los proyectos, los informes, los usuarios y las relaciones entre ellos.

Por último, también contamos con un servicio propio conocido como ELTA (EDICOM Long-Term Archiving). Se trata de un servicio de almacenamiento de documentos. En nuestro caso, lo utilizamos para almacenar toda la información adjunta, capturas de pantalla, archivos, etc.

Una vez conocidas todas las partes del ecosistema, podemos trabajar en un caso de uso que nos ayude a conocer en profundidad lo que aporta cada uno de estos engranajes.

Caso de uso

Para el caso de estudio vamos a utilizar una API REST abierta llamada Cat Fact API. La idea es montar un pequeño test para validar el funcionamiento de uno de los endpoints del servicio y mostrar con más detalle las entidades del diagrama.

La siguiente imagen muestra el código asociado al test:

ecosistema integrado de EDICOM
Código para probar el método «fact» de la API Cat Fact

La prueba consiste en validar que la función «fact» devuelve una cita con una longitud máxima de 30 caracteres. Como se indica en el queryVars. Otro aspecto importante es el objeto «client». Este se construye en base a un fichero de propiedades que representan la información básica de los servicios a los que se quiere lanzar peticiones HTTP. En nuestro caso, el fichero modela la información de la API que estamos trabajando:

Propiedades de los endpoints de Cat Fact API

La principal ventaja que nos da modelar de esta forma las llamadas a servicios es que nos permite trabajar con múltiples clientes que realizan las llamadas a todo tipo de servicios.

Como se ha comentado anteriormente, cuando se ejecuta el proyecto, el framework envía los resultados del test al gestor de informes. En la siguiente imagen podemos ver como tras la ejecución, donde se muestran los resultados, también se indica un enlace donde se encuentra el informe generado:

ecosistema integrado de EDICOM
Resultados de la ejecución impresos en el terminal

En cuanto a la página web de informes, este es su aspecto:

ecosistema integrado de EDICOM
Página web del servicio de informes

Para cada prueba listada podemos ver las llamadas HTTP lanzadas pulsando el botón con el icono de la nube. En el modal que aparece, como ya hemos comentado, podemos ver las cabeceras, parámetros, cuerpo, etc. de la petición y respuesta de las diferentes llamadas:

ecosistema integrado de EDICOM
Vista de la información sobre las llamadas HTTP de una prueba

Situado un poco más abajo encontramos el cuerpo de la respuesta de la petición:

ecosistema integrado de EDICOM
Cuerpo de la respuesta a la solicitud

Una vez implementado el proyecto, el siguiente paso es añadir su ejecución como un trabajo adicional en los pipelines del producto. De esta forma, cada vez que se realizan cambios en el producto, se ejecutan diferentes pruebas para asegurar que los cambios no han introducido errores.

Por otro lado, estas ejecuciones se pueden programar para ser ejecutadas en GitLab. Para ello, teniendo el proyecto alojado en un repositorio definiremos un fichero llamado «.gitlab-ci.yml» que contendrá todo lo necesario para la ejecución de pipelines. Este archivo, entre otras cosas, indica las diferentes etapas del pipeline. En nuestro caso, el pipeline contiene dos. La etapa de construcción y la etapa de prueba donde se ejecuta el proyecto:

ecosistema integrado de EDICOM
El pipeline de Gitlab y sus etapas

Dentro del trabajo donde se ejecutan las pruebas podremos encontrar la URL donde se ha almacenado el informe con los resultados de las pruebas de la misma forma que se muestra cuando lo ejecutamos en local. Por último, para tener esta ejecución programada tendremos que definir un horario del pipeline de GitLab basado en la sintaxis de Cron. Por ejemplo, a las tres de la mañana.

ecosistema integrado de EDICOM
Programador de pipelines de Gitlab

El resultado de la ejecución de estos pipelines es lo que enviamos a la aplicación Automonitor. De esta forma podemos monitorizar el estado de los servicios. En la siguiente imagen podemos ver cómo se muestra el resultado de la ejecución de los pipelines de cinco proyectos, incluyendo la pequeña demo creada:

ecosistema integrado de EDICOM
Automonitor

Conclusión

Toda esta integración de tecnologías tiene un propósito: satisfacer las necesidades que aparecen al probar nuestras aplicaciones. El hecho de que el framework incluya tantas librerías y la posibilidad de cambiarlas sin necesidad de cambiar los proyectos es una gran ventaja, nos da mucha robustez y flexibilidad en las pruebas.
Por otro lado, el sistema de reportes nos ofrece información valiosa tanto actual como histórica sobre los resultados de las pruebas y el monitor de proyectos proporciona el estado actual de los proyectos de E2E.

Podríamos resumir que este ecosistema nos aporta:

  • Flexibilidad en la implementación de pruebas.
  • Fácil migración a otras tecnologías gracias a patrones de diseño.
  • Mantenibilidad de los proyectos.
  • Adaptabilidad a distintos entornos mediante ficheros de configuración.
  • Monitorización continua de los servicios.
  • Fiabilidad y rapidez en la ejecución de pruebas y la visualización de resultados.
  • Trazabilidad de los resultados de ejecuciones.