Late-Game: observación
La tercera fase del IQL cubre los steps 10 a 15 y la comparten QA y DevOps. Su pregunta es «cómo se comporta en el mundo real?»: la regresión decide si el release sale, y después producción se vigila y alimenta el siguiente ciclo.
Esta página resume la sub-página upexgalaxy.com/metodologia/late-game. Si algo de aquí no coincide con el sitio, manda el sitio. La versión en inglés está en upexgalaxy.com/en/methodology.
La fase en una tabla
| Pregunta | «Cómo se comporta en el mundo real?» |
|---|---|
| Enfoque | Observación: monitorear y asegurar la confiabilidad en producción |
| Rol protagonista | QA + DevOps |
| Alcance | Steps 10-15 |
| Enfoques integrados | Shift-Right, Chaos Engineering, Production Monitoring, AI Ops |
| Herramientas | Sentry / Grafana / Datadog, despliegue progresivo / feature flags, k6, UptimeRobot (o monitor de disponibilidad) |
El stage Regression
La suite corre y toda falla se clasifica: ninguna queda como «se rompió». De ahí salen el veredicto de release y el STR del sprint. Ocurre en el cierre y release, con nivel L3 · Continuous Detection, y contiene un solo step, el 10.
| El agente hace | Ejecuta la suite, clasifica cada falla (REGRESSION, FLAKY, KNOWN, ENVIRONMENT o NEW TEST), calcula pass-rate y tendencia sin truncar, propone GO, CAUTION o NO-GO y arma el STR. |
|---|---|
| La persona firma | Decide todo CAUTION. Y nunca deja que el número de sprint se invente: si no está, se pregunta. |
| Evidencia exigida | Reporte de la corrida con la clasificación de cada falla, histórico de al menos cinco corridas para poder declarar FLAKY (con menos se declara histórico insuficiente), y la corrida registrada en su Test Execution: un RTR enlazado al RTP por cada corrida de regresión, y el STR enlazado al STP al cierre del sprint. |
| Autonomía | 3 (4 en un GO limpio) |
| Verificador separado | No hace falta |
| Roles | QA Automation Engineer, QA Lead · Executor, Guardian |
| Salidas | STR; reporte de regresión con la clasificación de cada falla; veredicto GO / CAUTION / NO-GO |
Las cinco clases de falla
El sitio oficial nombra las cinco clases. La columna de la derecha es cómo las trata el
skill /regression-testing de este repo
(.agents/skills/regression-testing/SKILL.md, que es la fuente si la lista
cambia). El skill parte KNOWN en dos: KNOWN-BLOCKED y KNOWN ISSUE.
| Clase | Qué hace el skill con ella |
|---|---|
| REGRESSION | Bloquea el release, se filea un Bug o Defect en Jira y se asigna. |
| FLAKY | Se agenda su estabilización y no bloquea. No se crea bug. Declararla exige al menos cinco corridas de histórico. |
| KNOWN |
KNOWN-BLOCKED: el test lleva el tag
@blocked:{BUG-KEY} porque está estacionado detrás de un bug ya abierto.
Se excluye del pass-rate que decide el veredicto y se lista aparte con su bug.
KNOWN ISSUE: el fallo está enlazado a un ticket conocido; se
documenta contra ese ticket y no bloquea. En ninguno de los dos casos se crea un bug
nuevo.
|
| ENVIRONMENT | Se vuelve a correr tras revisar la infraestructura. No se crea bug. |
| NEW TEST | Verificación manual: si es un defecto real del producto se filea; si no, se acepta o se corrige el test. |
Con la clasificación, el pass-rate y la tendencia, el agente propone uno de tres veredictos: GO, CAUTION o NO-GO. Un CAUTION siempre lo decide una persona.
El stage Observation
Observation es el stage de producción (L4 · Production Observation) y agrupa los steps 11 a 15. Todavía no tiene skill: su unidad operativa es la rutina agéntica, una ejecución que corre sola, en horario o por disparo, y deja evidencia con destinatario. Por eso el sitio lo declara panorama: se enseña como vista de la industria y hoja de ruta, no como práctica operada contra producción. El agente vigila las señales que el producto ya emite y abre ítems al backlog cuando una se sale de rango; la persona define los objetivos de servicio y decide cuándo se detiene un release.
El contrato completo, las cuatro piezas de una rutina agéntica y los detalles de cada step están en Observation.
Los 6 steps del Late-Game
El step 10 es regresión y lo cubre el boilerplate. Del 11 al 15 son Shift-Right, están marcados como panorama y el boilerplate no los cubre. Cada step pide un prerrequisito del entorno y tiene un orden de adopción sugerido.
| Step | Qué se hace | Entregable | Prerrequisito | Adopción |
|---|---|---|---|---|
| 10. Continuous Maintenance Production Ops |
Asegurar que la aplicación esté estable para el lanzamiento y siga así después del despliegue. La regresión del sprint se planifica en el STP y su ejecución se registra en el STR. Actividades: regression suite, smoke testing, test maintenance. | US desplegada a producción con confianza + STR del sprint | CI verde con una suite de regresión que corre en cada PR | nº 1 |
| 11. Canary Release Monitoring Shift-Right |
Desplegar funcionalidades nuevas a un porcentaje pequeño de usuarios y monitorear cómo se comportan. | Validación segura con riesgo mínimo | Despliegue progresivo (canary o feature flags) con métricas por cohorte | nº 4 |
| 12. A/B Testing Experimentation |
Probar versiones distintas de una funcionalidad para optimizar la experiencia. | Decisiones basadas en datos de usuarios reales | Feature flags y analítica de producto | nº 5 |
| 13. Real User Monitoring (RUM) Observability |
Monitorear la experiencia real de los usuarios para identificar problemas de performance. Métricas: Core Web Vitals, MTTD, MTTR. | Visibilidad completa de la UX real | Error tracking y RUM (Core Web Vitals) en producción | nº 2 |
| 14. Chaos Engineering Resilience |
Introducir fallas controladas en producción para validar la resistencia del sistema. | Sistema con recovery validado | Arquitectura distribuida, SLOs definidos y equipo SRE | nº 6 |
| 15. Feedback Loop Continuous Learning |
Analizar el feedback de usuarios y las métricas de producción para alimentar el siguiente ciclo del Early-Game. | Mejora continua del producto | Al menos una fuente de producción (RUM o alertas) y un ritual que devuelva lo aprendido al step 1 | nº 3 |
Herramientas por step: el 10 usa Playwright, Xray y GitHub Actions (o CI equivalente). Del 11 al 15 aparecen Sentry / Grafana / Datadog, despliegue progresivo / feature flags, k6, UptimeRobot, herramientas de chaos (Gremlin, Litmus, scripts propios), Jira y Slack / Teams. Casi todas las trae el cliente: el IQL define qué observar y el entorno define con qué. k6 entra solo cuando el atributo performance aparece por riesgo en el step 1.
Hasta dónde llegar lo fija la madurez
Esta fase no se adopta entera. Cada step pide un prerrequisito del entorno, y el nivel de madurez del equipo dice cuáles tienen sentido en cada momento. Los steps del Late-Game están en L3 (el step 10) y en L4 (del 11 al 15).
| Nivel | Steps | Requiere | Resultado |
|---|---|---|---|
| L1 · Prevention | 1, 2 | Backlog en un tracker y QA sentado en el refinamiento | Historias mejor definidas |
| L2 · Early Detection | 3, 4 | Un ambiente de prueba anterior al merge (QA o staging) | Feedback antes del PR |
| L3 · Continuous Detection | 5-10 | Repositorio con pull requests y un CI que corra en cada PR | Regresión confiable en CI |
| L4 · Production Observation | 11-15 | Observabilidad en producción; despliegue progresivo para canary y A/B; SLOs y cultura SRE para chaos | Producción alimentando la estrategia |
Las métricas
Las fases anteriores se evalúan por lo que producen: un plan, un caso, un PR mergeado. Esta se evalúa por lo que pasa en producción cuando nadie está mirando, y eso solo se sabe con números y con un objetivo declarado de antemano.
Las 6 métricas del Late-Game
| Métrica | Qué mide | Benchmark de referencia |
|---|---|---|
| MTTD (Mean Time To Detect) | Cuánto tarda el equipo en enterarse de que algo se rompió en producción. Todo lo que pasa antes de detectarlo es impacto que nadie contiene. | < 5 minutos |
| MTTR (Mean Time To Resolution) | Cuánto tarda en resolverse un problema una vez detectado. Es la mitad del incidente que se acorta con proceso. | < 30 minutos |
| Error Rate | Porcentaje de peticiones que terminan en error. Se mueve antes que cualquier queja. | < 0.1% |
| CSAT (Customer Satisfaction Score) | La satisfacción declarada por quienes usan el producto. Mide la percepción del sistema, no el sistema. | > 4.5/5 |
| SLO Compliance | Qué porción del tiempo se cumplen los objetivos de servicio comprometidos. Pone la disponibilidad en un número negociable. | > 99.9% |
| Performance Score (Core Web Vitals) | El rendimiento percibido, con las métricas web de Google. Afecta posicionamiento y conversión. | > 90/100 |
Los valores son benchmarks de ejemplo. Un banco y una app interna de RRHH no necesitan el mismo SLO: cada implementación declara sus propios targets según criticidad, baseline, arquitectura y negocio.
Las métricas del método
- Change failure rate
- Porcentaje de despliegues que terminan en incidente, rollback o hotfix. Es la métrica DORA que dice si el método sostiene la velocidad o solo la empuja.
- Escape rate
- Bugs encontrados en producción sobre el total de bugs del período. Mide lo que el método promete: que el defecto se encuentre antes.
- Ratio Deferred
- Porción de escenarios que el gate de ROI deja fuera de la regresión. Si más de la mitad cae en Candidate o Manual, el filtro no se aplicó y se vuelve a correr la fase de descarte.
- Flaky rate
- Tests que cambian de resultado sin que cambie el código, sobre el total de la suite. Decide si el equipo le cree a la regresión.
- Lead time AC → ATP (opcional)
- Cuánto tarda una historia con criterios en tener su plan de aceptación. Mide si el Shift-Left llega a tiempo.
Enfoques y herramientas de la fase
- Shift-Right
- Extender la validación hacia producción, donde el sistema recibe usuarios reales.
- Chaos Engineering
- Fallas controladas para validar la resiliencia antes de que el fallo llegue solo.
- Production Monitoring
- Observabilidad continua del sistema en producción para detectar anomalías temprano.
- AI Ops
- IA sobre la telemetría: análisis predictivo y detección de anomalías.
| Herramienta | Para qué en esta fase |
|---|---|
| Sentry / Grafana / Datadog | Errores de producción con su traza y tableros de métricas. De ahí salen el Error Rate y buena parte del MTTD. |
| Despliegue progresivo / feature flags | Lo que permite mirar una cohorte antes que a todo el mundo. |
| k6 | Carga y rendimiento contra el sistema real, no contra una maqueta. |
| UptimeRobot (o monitor de disponibilidad) | Disponibilidad medida desde afuera: el chequeo que sostiene el objetivo de servicio. |
En este repo
| Stage | Skill |
|---|---|
| Regression (step 10) |
/regression-testing: corre la suite en CI, clasifica y emite el
veredicto
|
| Observation (steps 11-15) | Ninguno todavía. El stage está declarado y no implementado. |
El checklist del stage Regression en
.agents/skills/agentic-qa-core/references/stage-gates.md pide además, por cada
corrida, un RTR (Test Execution) enlazado al RTP. Observation no tiene checklist a
propósito, para que ningún orquestador crea que hay un gate verificable. El resto del mapa
está en El IQL en este repo.