Tener un gran número de pruebas no servía de nada cuando cada ejecución fallida desencadenaba una nueva investigación

Director de Ingeniería

La plataforma del cliente contaba con aproximadamente 1.100 pruebas automatizadas, pero los equipos de ingeniería habían dejado de confiar en la suite. a1qa fue contratada para evaluar un subconjunto delimitado de 420 pruebas que cubría los flujos críticos de eCommerce, documentar una decisión de mantener, sustituir o retirar para cada prueba y demostrar que el conjunto resultante podía respaldar decisiones de despliegue.

El desafío

El subconjunto crítico presentaba una tasa de pruebas inestables (flaky tests) del 18 %. Además, el 24 % de los fallos reportados no correspondía a defectos reproducibles del producto. Selectores obsoletos, lógica de preparación duplicada, datos inconsistentes y una clasificación deficiente de los errores obligaban a los ingenieros a repetir ejecuciones e investigar ruido antes de poder evaluar el riesgo real para el producto.

Las tareas de mantenimiento y las reejecuciones consumían alrededor de 45 horas de ingeniería semanales. Solo el 52 % de las ejecuciones de CI finalizaba dentro del límite acordado de 90 minutos y sin necesidad de reejecución. La toma de decisiones sobre regresión para el alcance seleccionado requería aproximadamente dos días laborables, lo que limitaba el área del producto a dos lanzamientos planificados al mes.

El cliente necesitaba evidencias claras sobre qué elementos seguían siendo válidos, cuáles debían modernizarse y cuáles resultaban más económicos de sustituir.

Durante un período de 12 semanas, a1qa avanzó desde la fase de evaluación hasta la ejecución de un proyecto piloto mediante un enfoque estructurado de recuperación y estabilización. El equipo estuvo formado por 3 ingenieros de automatización, 1 arquitecto sénior de Quality Engineering y soporte DevOps a tiempo parcial.

El proyecto comenzó con el análisis de fallos a través de múltiples ejecuciones repetidas, la revisión de la estructura del código y sus dependencias, así como la separación de pruebas inestables, fallos de entorno, problemas de datos y defectos reproducibles del producto. Cada una de las 420 pruebas incluidas en el alcance crítico recibió una decisión de mantener, sustituir o retirar, respaldada por criterios técnicos y económicos.

Tras estabilizar 170 pruebas cuyo propósito de negocio y arquitectura seguían siendo válidos, los ingenieros de QA mejoraron los selectores, las aserciones, las esperas, la preparación de datos y los componentes reutilizables, manteniendo al mismo tiempo la trazabilidad con los recorridos críticos del cliente.

Posteriormente, el equipo sustituyó 150 pruebas que no podían repararse de manera rentable. La IA se utilizó para apoyar tareas repetitivas de preparación y conversión de código basadas en escenarios previamente aprobados. Los ingenieros de QA aplicaron las convenciones del framework, revisaron la lógica de negocio y descartaron cualquier resultado que no cumpliera la política de aceptación establecida.

Finalmente, se retiraron 100 pruebas obsoletas o duplicadas del alcance piloto. Las 320 pruebas aceptadas se integraron en el flujo de CI propiedad del cliente, se validaron de forma repetida y se verificaron conforme a criterios de tiempo de ejecución, estabilidad, tasa de falsos fallos y mantenibilidad.

El alcance delimitado para la evaluación incluía autenticación y cuentas de usuario, búsqueda, carrito y proceso de compra (checkout), estado de pedidos y notificaciones a clientes. Los problemas de entorno y los defectos del producto fuera de este alcance se registraron como dependencias.

Los ingenieros de QA garantizaron que las pruebas conservadas y las de nueva creación cumplieran los requisitos de negocio, las normas del framework y las reglas de trazabilidad, superaran la revisión humana y mantuvieran su estabilidad durante el período de validación. Antes de aceptar una prueba, los fallos debían clasificarse como incidencias de la propia prueba, de los datos, del entorno o del producto. Esta política permitió que el resultado final de 320 pruebas reflejara la mantenibilidad real de la suite y no simplemente su tamaño.

Como entregables del proyecto, el cliente recibió el registro de clasificación, el código corregido, la configuración de CI, una guía operativa y un backlog técnico. El traspaso también identificó qué dependencias de entorno requerían acciones por parte del cliente y qué futuras iniciativas de automatización debían abordarse en una fase independiente de escalado.