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.
La priorización de regresión basada en riesgo ordena la ejecución de pruebas según dos preguntas:
La IA o un scoring inteligente ayudan a responder eso con más contexto:
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.
Este enfoque suele empezar a entregar valor cuando se cruzan varias condiciones:
En cambio, conviene no sobrediseñar si todavía pasa esto:
En ese escenario, partir por ML suele ser un desvío. Primero hay que ordenar la base.
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.
No basta con mirar archivos modificados. Hay que mirar también:
Un cambio pequeño en autenticación o permisos puede ser más delicado que un cambio grande en una vista secundaria.
Este punto marca la diferencia entre una priorización útil y una priorización ingenua.
No pesan igual:
Si el ranking no incorpora criticidad, puede optimizar tiempo de ejecución y aun así dejar demasiado expuestas las rutas más sensibles.
Sí conviene mirar:
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.
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.
No todas las pruebas cuestan lo mismo.
Hay pruebas:
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.
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:
En equipos con pagos, KYC, pricing o cálculo regulado, esa diferencia no es menor.
Antes de hablar de IA, deja claro qué corre siempre:
Si esta capa no está acordada, todo lo demás nace débil.
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.
En muchos equipos, un scoring por reglas entrega valor antes que un modelo sofisticado.
Una base razonable puede considerar:
Con eso ya puedes separar prioridad alta, media y baja sin volver el sistema opaco.
No intentes desplegarlo en todo el portafolio de una vez.
Parte por un flujo donde el dolor sea claro y la señal exista:
Ese piloto debería ayudarte a responder algo más útil que “corrimos menos”:
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.
Si la suite está desordenada, una capa más sofisticada no arregla nada.
El cambio en el código importa. El impacto al negocio también.
Una prueba ruidosa no debería dominar decisiones críticas.
Sin mirar escapes, falsos negativos y cobertura de rutas críticas, el ahorro puede ser engañoso.
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.
No. La vuelve más eficiente. La regresión amplia sigue existiendo, pero deja de bloquear cada cambio.
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.
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.
En tres puntos: mapeo débil entre cambio y prueba, ruido por pruebas inestables y falta de gobierno sobre excepciones.
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
Funciones Clave de un Analista QA: Asegurando la Calidad del Software
Futuro del Cloud Computing en Chile: Tendencias, Beneficios y Desafíos
ISO 27001: Clave en la Seguridad de la Información Empresarial