Por Ignacio Muñoz, Project Manager ACL
La IA para priorización de regresión sirve para tomar una decisión concreta: qué pruebas deben correr siempre, cuáles deben subir primero y cuáles pueden pasar a una capa posterior.
No es un tema de moda. Es un tema de capacidad operativa.
Escribí este blog porque cuando la suite de regresión crece, correr todo en cada cambio deja de ser una práctica sana. El pipeline se alarga, el feedback llega tarde y el equipo empieza a compensar con decisiones poco explícitas: desactivar pruebas, mover validaciones al final o aceptar cobertura insuficiente para cumplir plazos.
Ahí entra risk-based regression. La lógica es simple: no todos los cambios exponen el mismo riesgo, no todos los flujos tienen el mismo impacto y no todas las pruebas entregan la misma señal. Según Microsoft Learn, en muchos escenarios tiene más sentido correr el subconjunto de pruebas realmente afectado por el cambio que ejecutar toda la suite de forma indiscriminada.
Qué es y qué no es
La priorización de regresión basada en riesgo ordena la ejecución de pruebas según dos preguntas:
- Qué tan probable es que este cambio rompa algo;
- Qué tan costoso sería que eso falle en producción.
La IA o un scoring inteligente ayudan a responder eso con más contexto:
- Componentes modificados;
- Historial de fallos;
- Criticidad del flujo;
- Incidentes previos;
- Estabilidad de las pruebas;
- Costo de ejecución.
Conviene separar tres conceptos:
- Priorizar es ordenar qué corre primero.
- Seleccionar es decidir qué subconjunto corre en una etapa.
- Excluir es dejar algo fuera en ese contexto.
No siempre necesitas hacer las tres cosas a la vez. También hay un límite importante: esto no reemplaza una estrategia de calidad. Si la suite está inflada, duplicada o llena de ruido, la IA no la corrige. Solo vuelve menos visible el problema.
Cuándo sí vale la pena
Este enfoque suele empezar a entregar valor cuando se cruzan varias condiciones:
- La suite tarda demasiado y ya afecta merges o releases;
- Existe presión real por reducir el tiempo de feedback;
- Hay suficiente automatización como para elegir entre capas;
- No todos los cambios impactan todo el sistema;
- El equipo ya tiene alguna trazabilidad entre prueba, componente y flujo.
En cambio, conviene no sobrediseñar si todavía pasa esto:
- No sabes qué cubre cada prueba;
- Hay demasiadas pruebas inestables;
- El historial de ejecución es pobre o poco confiable;
- El principal problema sigue siendo cobertura básica;
- Todo el sistema cambia al mismo tiempo en cada release.
En ese escenario, partir por ML suele ser un desvío. Primero hay que ordenar la base.
Qué señales conviene usar
Uno de los errores más comunes es construir el ranking solo con variables técnicas. Eso puede servir para una prueba de concepto. No alcanza para un pipeline serio.
1. Alcance real del cambio
No basta con mirar archivos modificados. Hay que mirar también:
- Servicios afectados;
- Dependencias;
- Contratos;
- Flags;
- Tipo de cambio: cosmético, funcional o estructural.
Un cambio pequeño en autenticación o permisos puede ser más delicado que un cambio grande en una vista secundaria.
2. Criticidad del flujo
Este punto marca la diferencia entre una priorización útil y una priorización ingenua.
No pesan igual:
- Login;
- Checkout;
- Pricing;
- Conciliación;
- Onboarding regulado;
- Cálculo de beneficios o comisiones.
Si el ranking no incorpora criticidad, puede optimizar tiempo de ejecución y aun así dejar demasiado expuestas las rutas más sensibles.
3. Historial de fallos e incidentes
Sí conviene mirar:
- Módulos con defectos recurrentes;
- Áreas con incidentes recientes;
- Rutas con alto defect leakage;
- Zonas con mucha frecuencia de cambio.
Pero no conviene convertir el modelo en un espejo del pasado. Si el ranking solo reacciona a donde antes hubo fallos, pierde capacidad para detectar riesgo nuevo.
4. Confiabilidad de la prueba
Acá se cae más de una implementación. Una prueba inestable no debería subir de prioridad porque falla seguido. Debería bajar de peso, entrar en cuarentena o tratarse aparte. Como explica Google Testing Blog, los flaky tests degradan la señal y frenan la productividad cuando no se controlan.
5. Costo de ejecución
No todas las pruebas cuestan lo mismo.
Hay pruebas:
- rápidas y precisas;
- lentas pero críticas;
- caras y con poco valor incremental.
Por eso sigue siendo útil pensar en capas. La test pyramid de Martin Fowler sigue siendo una referencia útil para ordenar el problema según velocidad, alcance y costo de cada nivel de prueba.
Una arquitectura práctica que suele funcionar mejor
En la práctica, lo más defendible no es una única suite “inteligente”. Es una arquitectura por capas.
| Capa | Qué corre | Cuándo | Qué protege |
|---|---|---|---|
| Suite base | Smoke, autenticación, permisos, pagos, cumplimiento crítico | Siempre | Salud mínima del sistema |
| Capa dinámica por riesgo | Pruebas priorizadas por cambio, criticidad e historial | Por commit o PR | Feedback enfocado |
| Regresión ampliada | Regresión más extensa | Nightly, pre-release o hitos definidos | Cobertura extendida |
| Cuarentena | Pruebas inestables o bajo análisis | Fuera de gates principales | Higiene de señal |
Este esquema evita dos errores frecuentes:
- Usar IA como único árbitro del pipeline;
- Asumir que priorizar equivale a dejar de validar.
En equipos con pagos, KYC, pricing o cálculo regulado, esa diferencia no es menor.
Cómo implementarlo sin volverlo un proyecto eterno
1. Define una suite base no negociable
Antes de hablar de IA, deja claro qué corre siempre:
- Login;
- Permisos;
- Pagos;
- Creación de órdenes;
- Eventos auditables;
- Flujos normativos.
Si esta capa no está acordada, todo lo demás nace débil.
2. Mapea pruebas a componentes y flujos
No necesitas un mapeo perfecto desde el día uno. Si necesitas uno suficiente para responder esto: si cambia este componente, qué pruebas tienen sentido primero.
Si hoy no puedes responder eso con cierta claridad, el problema todavía no es IA. Es trazabilidad.
3. Parte con un puntaje de riesgo simple
En muchos equipos, un scoring por reglas entrega valor antes que un modelo sofisticado.
Una base razonable puede considerar:
- Criticidad del flujo;
- Cercanía al cambio;
- Historial de defectos;
- Incidentes recientes;
- Duración;
- Penalización por inestabilidad.
Con eso ya puedes separar prioridad alta, media y baja sin volver el sistema opaco.
4. Pilotea en un flujo acotado
No intentes desplegarlo en todo el portafolio de una vez.
Parte por un flujo donde el dolor sea claro y la señal exista:
- Checkout;
- Onboarding;
- Autenticación;
- Pricing;
- Conciliación;
- Emisión o liquidación.
Ese piloto debería ayudarte a responder algo más útil que “corrimos menos”:
- ¿Bajó el tiempo de feedback?
- ¿Subieron los falsos negativos?
- ¿Se mantuvo la cobertura de rutas críticas?
- ¿La operación confía más o menos en el pipeline?
5. Recalibra con disciplina
La priorización envejece. Cambian la arquitectura, las dependencias, los patrones de release y los riesgos del negocio. Si nadie recalibra reglas, pesos y excepciones, el sistema pierde credibilidad y el equipo vuelve a correr todo.
Errores comunes
Apostar por ML antes de estabilizar la base
Si la suite está desordenada, una capa más sofisticada no arregla nada.
Diseñar el ranking solo con datos técnicos
El cambio en el código importa. El impacto al negocio también.
No aislar las pruebas inestables
Una prueba ruidosa no debería dominar decisiones críticas.
Medir solo ahorro de tiempo
Sin mirar escapes, falsos negativos y cobertura de rutas críticas, el ahorro puede ser engañoso.
Convertirlo en caja negra
Si nadie entiende por qué algo subió o bajó de prioridad, la confianza cae rápido. Para organizaciones que necesitan trazabilidad y gobierno, el AI Risk Management Framework de NIST es una buena referencia para pensar riesgo, explicabilidad y revisión responsable de sistemas asistidos por IA.
Checklist para saber si tu equipo está listo
- Tenemos una suite base clara.
- Sabemos cuáles son los flujos más críticos del negocio.
- Existe mapeo razonable entre pruebas, componentes y flujos.
- Medimos duración, fallos e inestabilidad.
- Podemos distinguir señal útil de ruido operacional.
- Hay historial suficiente para pilotear.
- Existe acuerdo entre QA, ingeniería y negocio sobre lo no negociable.
- El puntaje de riesgo se puede explicar sin magia.
- Tenemos cómo medir defect leakage y falsos negativos.
- Hay alguien responsable de recalibrar el modelo.
Preguntas frecuentes (FAQs)
¿Esto reemplaza la regresión completa?
No. La vuelve más eficiente. La regresión amplia sigue existiendo, pero deja de bloquear cada cambio.
¿Conviene partir con IA o con reglas?
En la mayoría de los casos, con reglas. Si el problema está bien modelado, un puntaje simple entrega valor antes y con menos fricción.
¿Qué pasa en entornos regulados?
Se puede aplicar, pero con límites más explícitos. No conviene dejar rutas críticas o auditables dependiendo solo de priorización dinámica.
¿Dónde suele fallar primero una implementación?
En tres puntos: mapeo débil entre cambio y prueba, ruido por pruebas inestables y falta de gobierno sobre excepciones.
¿Qué métrica importa más?
No hay una sola. Conviene mirar tiempo de feedback, defect leakage, falsos negativos, cobertura de rutas críticas y confianza real del equipo en la señal.
La IA para priorización de regresión aporta cuando ayuda a tomar mejores decisiones de ejecución bajo riesgo real.
No se trata de recortar validación a ciegas. Se trata de proteger mejor lo crítico, acelerar feedback donde sí conviene y dejar de tratar todas las pruebas como si valieran lo mismo.
Si estás trabajando este tema, vale la pena complementar esta lectura con nuestra página de QA con IA, la guía práctica para implementar testing inteligente, el artículo sobre herramientas de IA para QA, la nota sobre tipos de testing en software, el post sobre pirámide de pruebas y cobertura basada en riesgo y la guía de STLC/SDLC aplicado: dónde entra QA con IA.
¿Tu suite de regresión ya no escala al ritmo del producto?
Conversemos sobre cómo ordenar la regresión por riesgo, reducir ruido operacional y mejorar la señal del pipeline sin comprometer cobertura crítica.Agenda una conversación con nuestros expertos de ACL
