¿Hablamos?
¿Hablamos?

 

bCube (1)

 

5 minutos de lectura

La artillería de testing de bCube CMS: automatización y estrategia

Featured Image

Garantizar la calidad en un entorno tan flexible como bCube CMS no es tarea sencilla. Probar, validar y asegurar el correcto funcionamiento de todas las piezas que conforman cada proyecto supone un reto constante. En este artículo, explicamos la estrategia de calidad que está llevando a cabo nuestro departamento de QA, basada en la automatización de pruebas.

 

El éxito de cualquier gestor de contenidos reside en su calidad y estabilidad. Como ya exploramos en nuestro artículo anteriorQA en bCube CMS: clave en la calidad y el éxito de los proyectos, la Garantía de Calidad (QA) es un pilar fundamental de nuestro desarrollo. Sin embargo, dada la alta capacidad de personalización que ofrecemos a nuestros clientes, el testing se convierte en un desafío considerable.

¿Cómo abordamos esta “marea de pruebas”, como lo califica Katia Sánchez, Quality Assurance de Bitban Technologies? Mediante una batería de tests estratégicos y automatizados, que el departamento ha diseñado, desarrollado y consolidado en el último año.

 

El desafío de la personalización: un CMS, múltiples realidades

bCube CMS se distingue por su flexibilidad y su capacidad de adaptarse a las necesidades específicas de los medios de comunicación. Esta personalización, aunque supone un gran beneficio para el cliente, complica notablemente el plan de calidad. Probar manualmente cada configuración a medida supone un esfuerzo enorme y resulta, en la práctica, inviable.

Para afrontar este reto, el enfoque elegido por Bitban Technologies se basa en la automatización de una batería de pruebas configurable para las funcionalidades comunes del CMS. Estas pruebas actúan como una “cáscara vacía, en la que se inyectan las variaciones de configuración propias de cada cliente. Este enfoque se complementa con otra batería de pruebas específicas para las funcionalidades únicas de cada proyecto, logrando así una cobertura automática completa (o casi completa) del sistema.

 

El enfoque de las pruebas

El objetivo de la estrategia definida por el departamento de calidad es asegurar la solidez del CMS como producto. Para ello, se están desarrollando varias baterías de tests funcionales automáticos, lo más amplias posible, centradas en:

  • Flujos esenciales y casos límite del CMS, tanto en frontend como en backend, para validar las interacciones y funcionalidades clave de usuarios y equipos internos que utilizan el gestor de contenidos.

  • Contratos de datos entre servicios, con el fin de garantizar la cohesión y compatibilidad entre las distintas partes que componen bCube.

  • Correcto funcionamiento del producto en su configuración estándar, así como de las configuraciones específicas de cada proyecto, asegurando que las variaciones se comportan como se espera sin necesidad de reescribir la batería de pruebas.

 

Estrategia de capas

Aparte de diferenciar entre la batería de pruebas de las funcionalidades básicas y la de las funcionalidades específicas de cada proyecto, a la hora de probar servicios de forma eficiente es fundamental definir una estrategia de cobertura por capas.

Una aproximación muy conocida es la pirámide de testing, que prioriza los tests unitarios y reduce progresivamente el peso de los tests de integración y finalmente de los de E2E. Sin embargo, en nuestro caso hemos optado por una estrategia más cercana a la del panal de abeja (Honeycomb testing): una estructura menos jerárquica, donde distintas capas de pruebas se refuerzan entre sí.

La base de nuestra estrategia es una capa sólida de tests funcionales, orientados a validar que las interacciones reales del cliente funcionan correctamente. Estos tests se centran en los flujos principales del sistema y nos dan un alto nivel de confianza sobre el comportamiento del producto desde el punto de vista del usuario final.

Esta capa funcional se complementa con:

  • Tests unitarios, desarrollados por los propios desarrolladores, que validan el comportamiento de las unidades de código de forma aislada y permiten detectar errores de manera casi inmediata.

  • Tests de integración y/o de API, cuyo objetivo es asegurar que los contratos entre los servicios principales del CMS se mantienen estables y que la comunicación entre componentes es correcta, incluso cuando evolucionan de forma independiente. Además, permiten reducir la carga de algunos tests de E2E, probando a gran velocidad muchas casuísticas distintas.

Esta combinación nos permite equilibrar rapidez de ejecución, facilidad de mantenimiento y confianza en el sistema, asegurando el correcto funcionamiento de la aplicación.

En el artículo anterior sobre QA mencionamos el uso de Cypress como herramienta principal de automatización. A medida que la batería de pruebas fue creciendo y los escenarios se hicieron más complejos, decidimos dar el salto a Playwright, una herramienta que encaja mejor con las necesidades de nuestros proyectos.

 

Playwright

 

 

Ejecución en distintos puntos del desarrollo

Un plan de calidad no solo depende de qué pruebas se incluyen, sino también de cuándo se ejecutan. Los bugs (o errores) pueden aparecer en cualquier fase del desarrollo, y una batería de tests, por completa que sea, pierde gran parte de su valor si no se lanza en los momentos adecuados.

En nuestro caso, los problemas pueden venir de múltiples fuentes: el código de las librerías core, las personalizaciones de cada proyecto, los textos de traducción, la calidad de los datos o los cambios de configuración entre entornos.

Dado que hay muchos factores que pueden afectar al estado final, aseguramos la calidad de forma continua mediante ejecuciones nocturnas en los principales entornos de desarrollo. Además, dependiendo de la situación, las pruebas se ejecutan manualmente en los siguientes casos:

  • En local, al terminar una nueva tarea, para asegurarnos de que todo funciona correctamente antes de integrar ese código con el resto de cambios de la versión.

  • Al desplegar nuevas versiones en los distintos entornos del proceso de desarrollo.

  • Al llevar nuevas versiones del core a los diferentes proyectos.

 

CRM, IA y el desafío de lo no determinista

Los nuevos módulos que estamos incorporando al CMS, como la integración con el CRM y, especialmente, con la solución de Inteligencia Artificial, introducen nuevos retos para la calidad:

  • Sistemas novedosos e inestables, cuyas funcionalidades pueden cambiar con frecuencia hasta alcanzar un grado suficiente de madurez.

  • Pruebas de IA, el gran desafío: ¿cómo se prueba un sistema no determinista? Nuestro equipo de QA está explorando metodologías que evalúan la calidad de la salida permitiendo variaciones lógicas, con el objetivo de asegurar un comportamiento consistente y evitar sesgos o errores graves.

 

Fomentando la cultura de la calidad: formación transversal

La complejidad del QA en un producto tan personalizable como bCube CMS exige que la calidad sea una responsabilidad compartida, no exclusiva del equipo de QA. Para ello, es clave que los equipos técnicos y no técnicos estén alineados.

Las pruebas de E2E se desarrollan utilizando BDD (Behavior-Driven Development), lo que permite que estén escritas en un lenguaje humano que pueden comprender todos los departamentos. Además, con el objetivo de fomentar la participación de todos los compañeros en el mantenimiento de la calidad, nuestra responsable de Quality Assurance ha liderado una iniciativa de formación dirigida a todo el equipo de Bitban Technologies, especialmente a los desarrolladores.

En dos sesiones formativas, Katia ha desmitificado la estrategia de calidad, explicando qué se está probando, cómo funcionan los tests E2E y de API y cómo ejecutarlas e interpretar sus resultados. Al entender los mecanismos de validación, los desarrolladores pueden escribir código con la calidad en mente, anticipar fallos en las pruebas y utilizar los propios test automatizados como una herramienta para mejorar su proceso de desarrollo y la solidez general del software.

En una próxima entrega del blog, nuestra responsable de QA profundizará en otro de los grandes retos del proyecto: cómo ejecutar de forma sencilla unas pruebas que pueden tener distintas configuraciones de proyectos, funcionalidades y entornos. Se presentará la herramienta de ejecución de los tests, y una visión más técnica del proyecto de automatización.

———

El departamento de QA de Bitban ha adoptado una estrategia de testing escalable y multifacética para dominar la complejidad de bCube. Combinando una sólida batería de pruebas automáticas de regresión centradas tanto en nuestras funcionalidades básicas (adaptadas a la configuración de cada cliente), como en las funcionalidades específicas de cada proyecto, nos aseguramos que la calidad y la estabilidad son los cimientos sobre el que nuestros clientes construyen su éxito digital.

¿Quieres conocer más en profundidad cómo puede ayudar un CMS robusto, como bCube, a tu redacción? Contacta con nuestro equipo.