La fase de discovery nos dio la confianza de que era posible alcanzar una velocidad 2 veces mayor dentro del alcance del piloto, y pudimos identificar claramente los puntos críticos.

Director de QA

El cliente es una gran empresa del sector alimentario y de retail que gestiona toda la experiencia del cliente en una única plataforma de eCommerce y vende a través de varios canales. Su equipo interno de QA era responsable de una suite de regresión de aproximadamente 5.000 pruebas distribuidas entre varias regiones y roles. El negocio estaba impulsando el crecimiento de su cuota de mercado y necesitaba lanzar funcionalidades con mayor rapidez, por lo que la ingeniería de calidad debía evolucionar en lugar de convertirse en un freno.

La calidad nunca fue el problema. Lo era la velocidad. El cliente no buscaba otra prueba piloto de herramientas. Necesitaba un programa por fases, basado en evidencias y con criterios claros de validación. a1qa fue contratada para identificar dónde se perdía realmente el tiempo dentro del ciclo, demostrar un mecanismo más rápido en un alcance reducido y escalarlo únicamente allí donde los datos lo respaldaran.

El desafío

Sin un responsable claro, tomar una decisión de lanzamiento tardaba cerca de dos semanas, y la suite de pruebas se había vuelto tan grande que agregar un solo test ralentizaba el siguiente ciclo de regresión. Las soluciones habituales ya habían alcanzado su límite. Automatizar más, incorporar más personas o ejecutar la suite durante la noche ya no marcaba ninguna diferencia.

El cuello de botella no estaba en el número de pruebas. Estaba en la estructura del ciclo. Antes de cada comprobación se ejecutaban configuraciones complejas de interfaz de usuario. Los mismos casos equivalentes desde el punto de vista de la configuración se repetían una y otra vez. El triaje significaba que los ingenieros tenían que volver a revisar los fallos a mano, sin un dueño claro. Y cada decisión de lanzamiento se basaba en estimaciones en lugar de en datos.

La IA cambia la economía de estos cuatro factores, pero solo cuando se integra en el propio ciclo en lugar de añadirse como un elemento externo. El programa abordó simultáneamente estos cuatro costes: la configuración inicial, las ejecuciones redundantes, el análisis manual de fallos y la ausencia de una señal clara para la toma de decisiones sobre lanzamientos.

El proyecto se ejecutó bajo un modelo de precio fijo y por fases con puntos de validación, de modo que el cliente podía detenerlo en cualquiera de ellos: cada fase concluía con un punto de validación, y la siguiente solo se financiaba si la evidencia respaldaba los resultados obtenidos. La inversión nunca se adelantaba a la validación, y el equipo compartía la responsabilidad de cada herramienta de apoyo, métrica y proceso de triaje desde el primer día, garantizando que el conocimiento permaneciera dentro de la organización una vez finalizada la colaboración con a1qa. El trabajo se desarrolló bajo un modelo Agile con entregas iterativas y fue llevado a cabo por un equipo multidisciplinar compuesto por un QA Lead, dos ingenieros de automatización, un diseñador de pruebas y un ingeniero DevOps responsable de la ejecución en la nube.

Discovery

Diagnóstico de puntos críticos. Una fase de Discovery de alcance fijo validó las hipótesis utilizando el propio código y pipeline del cliente. Posteriormente, desglosó la toma de decisiones sobre lanzamientos en nueve puntos críticos concretos relacionados con la definición del alcance, la ejecución automatizada, el triaje, la reejecución y la decisión final. En lugar de intentar abordarlo todo al mismo tiempo, a1qa definió deliberadamente, junto con el QA Lead, un alcance limitado a una combinación específica de rol y región. Este enfoque es más fácil de medir, menos costoso en caso de error y proporciona al cliente datos reales antes de asumir compromisos de mayor envergadura.

Piloto

Diseño de pruebas asistido por IA. Un LLM ayudó en el diseño de pruebas. Generó casos candidatos a partir de historias de usuario y especificaciones existentes, identificó brechas de cobertura frente a los cambios presentes en el código y generó datos de prueba realistas para escenarios con múltiples regiones y roles. Un ingeniero de QA revisó cada artefacto generado por IA antes de incorporarlo a la suite, garantizando que la cobertura creciera allí donde realmente existía riesgo.

Automatización de pruebas impulsada por IA. Los lentos pasos de configuración de la interfaz de usuario fueron sustituidos por precondiciones basadas en API preparadas mediante IA, capaces de situar el sistema en el estado requerido en milisegundos en lugar de minutos. La configuración inicial necesaria antes de cada ejecución se compartía entre grupos de pruebas, las ejecuciones se realizaban en paralelo para distintas combinaciones de región, rol y modo, y los localizadores autorreparables absorbían los cambios habituales de la interfaz, evitando fallos de las pruebas. El resultado fue una capa de automatización más ligera, rápida y fácilmente mantenible por el propio equipo del cliente.

Triaje asistido por IA y clasificación de fallos. El triaje representaba uno de los costes ocultos más importantes. a1qa asignó un responsable identificado a cada fallo en cada etapa del proceso y entrenó mecanismos de clasificación basados en patrones de fallo para categorizarlos como problemas de entorno, de prueba o de producto. La detección de pruebas inestables redujo los falsos positivos, mientras que las reejecuciones automáticas gestionaban los fallos relacionados con el entorno. Como resultado, los ingenieros dejaron de revisar registros manualmente y pudieron volver a centrarse en la resolución de problemas del producto.

Fase 2

Inteligencia para la toma de decisiones de calidad. Cada decisión de lanzamiento se vinculaba a una compilación específica y quedaba almacenada con fines de trazabilidad y auditoría. En lugar de basarse en estimaciones, los equipos utilizaban datos reales de pruebas y calidad. Para cualquier compilación, los responsables podían ver qué se había aprobado, qué se había pospuesto y por qué.

Fase 3

Ejecución en la nube a escala. La suite se ejecutó sobre una infraestructura cloud elástica que cubría flujos web y móviles, incluidos los procesos de entrega y checkout. a1qa eliminó las reejecuciones equivalentes desde el punto de vista de la configuración, dividió la suite crítica para el negocio para que se ejecutara únicamente ante eventos relevantes relacionados con versiones del cliente y escaló la capacidad bajo demanda para ejecuciones paralelas. Una ventana fija de ejecución nocturna se convirtió en una capacidad flexible que el equipo podía ampliar cuando una versión lo requería.