Para cerrar esta serie voy a reunir las ideas en un ejemplo. Imaginemos que una plataforma financiera permitirá aumentar temporalmente el límite diario de transferencias. El cambio parece sencillo, pero toca autenticación, reglas, riesgo de fraude, concurrencia, notificaciones, auditoría y experiencia del usuario.
El objetivo no es mostrar un sistema autónomo que “hace QA”. Es explicar cómo varios agentes pueden apoyar tareas acotadas mientras un Quality Owner conserva contexto, trazabilidad y decisión.
Etapa 1: descubrimiento y refinamiento
Las fuentes iniciales incluyen la historia, reglas de límites, diseño, contratos actuales y decisiones previas. Un agente de análisis produce cuatro secciones: hechos confirmados, inconsistencias, preguntas e hipótesis.
- ¿Quién puede solicitar el aumento?
- ¿Cuánto dura y cómo se revoca?
- ¿Se aplica por cuenta, cliente o canal?
- ¿Qué ocurre con transferencias iniciadas antes de vencer?
- ¿Qué autenticación y auditoría requiere?
- ¿Cómo interactúa con el acumulado diario?
- ¿Qué debe mostrarse en otros canales?
El agente no completa respuestas. El equipo resuelve lo necesario y marca lo que queda abierto. El Quality Owner registra fuentes y responsables. Este flujo amplía mi método para analizar requisitos con IA antes del refinamiento.
Etapa 2: mapa de riesgos
Un segundo agente organiza riesgos propuestos, pero el equipo asigna prioridad. Algunos ejemplos:
- aumento aplicado a la cuenta incorrecta;
- límite vigente después de vencer;
- dos solicitudes concurrentes que superan controles;
- respuesta exitosa sin persistencia;
- cambio correcto sin auditoría;
- notificación enviada con información equivocada;
- desalineación entre app, web y servicio;
- abuso del flujo de autenticación.
Cada riesgo queda vinculado con una señal y un propietario. El objetivo no es puntuar todo, sino decidir dónde invertir cobertura y qué condiciones impedirían desplegar.
Etapa 3: estrategia de cobertura
Un agente de diseño recibe únicamente reglas confirmadas y propone condiciones clasificadas por técnica. El QA revisa redundancia, observabilidad y nivel.
- Unidad: cálculo de vigencia, límites y acumulados.
- Contrato: compatibilidad entre canales y servicio.
- Componente/API: autorización, estados, idempotencia y concurrencia.
- Integración: auditoría, notificaciones y dependencias.
- End-to-end: pocos recorridos críticos de usuario.
- Producción: métricas de uso, rechazo, error y comportamiento anómalo.
La guía sobre creación de casos con IA ayuda a convertir estas condiciones en pruebas ejecutables sin inflar la suite.
Etapa 4: datos y ambientes
Otro agente propone perfiles sintéticos: cuenta activa, bloqueada, con límites diferentes, cerca del acumulado y con solicitudes en varios estados. No recibe datos reales. Las reglas de generación se validan y los datos se crean en un ambiente aislado.
El sistema registra qué perfil utiliza cada prueba y cómo restaurarlo. Esto reduce dependencias ocultas y permite investigar una falla con el mismo estado inicial.
Etapa 5: implementación y automatización
Un agente de código puede preparar un borrador de pruebas siguiendo ejemplos del repositorio. Trabaja en una rama aislada y no puede integrar cambios. La revisión humana comprueba:
- qué riesgo protege cada prueba;
- si observa un resultado real y no un detalle interno frágil;
- si los datos son independientes;
- si los waits, reintentos y aserciones ocultan fallos;
- si la prueba pertenece al nivel correcto;
- si el mantenimiento esperado justifica su valor.
Etapa 6: pipeline y análisis de fallos
En CI, los controles rápidos se ejecutan primero. Si aparece un fallo, un agente agrupa síntomas, identifica el cambio, enlaza logs y propone hipótesis. No reejecuta indefinidamente ni marca un flaky test sin evidencia.
La decisión puede ser corregir producto, corregir prueba, aislar ambiente o investigar. Queda registrada con evidencia. Esta separación evita convertir la IA en un mecanismo que explique cualquier rojo hasta hacerlo parecer aceptable.
Etapa 7: decisión de release
El Quality Owner prepara una vista de decisión:
- riesgos críticos y evidencia disponible;
- cambios y dependencias afectadas;
- defectos abiertos y exposición;
- controles inestables o no ejecutados;
- observabilidad y alertas preparadas;
- estrategia de despliegue gradual;
- condiciones de reversa;
- responsables durante la ventana.
Un agente puede reunir la información, pero no aceptar el riesgo. Producto, tecnología y operación toman la decisión correspondiente a su responsabilidad.
Etapa 8: despliegue y producción
El cambio se habilita gradualmente. Un agente compara señales con la línea base: errores, rechazos, latencia, solicitudes, cambios revertidos y contactos de soporte. Utiliza límites predefinidos y escala cuando una condición se cumple.
La persona de guardia conserva autoridad para detener o revertir. Las métricas técnicas se interpretan junto con experiencia y resultados de negocio; una respuesta 200 no demuestra que el límite correcto fue aplicado.
Etapa 9: aprendizaje y actualización
Después del despliegue, el equipo revisa diferencias entre riesgos previstos y comportamiento real. Si surgió un problema, no se limita a añadir una regresión. Actualiza la fuente, el mapa de riesgos, el control, la señal y la respuesta.
Un agente puede sugerir artefactos relacionados que necesitan revisión. La persona responsable confirma el impacto y evita cambios masivos sin contexto.
Cómo se coordinan los agentes
No crearía un agente general con acceso a todo. Separaría capacidades:
- analista de requisitos con acceso de lectura;
- diseñador de cobertura sin capacidad de crear registros;
- generador de datos limitado al ambiente de pruebas;
- asistente de código restringido a una rama;
- analista de ejecución con logs y resultados;
- observador de producción con acceso de solo lectura.
Cada uno entrega una salida estructurada y el siguiente consume solo lo necesario. Los puntos de aprobación aparecen antes de acciones externas o decisiones de alto impacto, como explico en qué delegar y supervisar en agentes de testing.
Qué medir en el caso
- Tiempo desde una pregunta hasta evidencia útil.
- Porcentaje de propuestas aceptadas, modificadas y descartadas.
- Riesgos críticos con controles observables.
- Fallos encontrados antes y después del despliegue.
- Tiempo de diagnóstico y recuperación.
- Costo de revisión del trabajo asistido.
- Errores del agente por fuente, permiso o interpretación.
No mediría líneas de código generadas, cantidad de prompts ni número bruto de casos. Son actividad, no resultado.
El Quality Owner cierra el ciclo
Los mini agentes permiten trabajar en paralelo y reducir tareas mecánicas. El Quality Owner conserva la visión del conjunto: propósito, riesgo, evidencia, permisos, decisiones y aprendizaje. Esa coordinación es lo que transforma IA aislada en una capacidad real de Quality Engineering.
Preguntas frecuentes
¿Necesito implementar todos los agentes del ejemplo?
No. El caso representa un estado posible, no un punto de partida. Un solo agente de lectura que prepare preguntas con fuentes puede producir valor. La arquitectura debe crecer cuando cada nueva capacidad resuelva un problema medible y pueda controlarse.
¿Cómo evito que los agentes se transmitan errores?
Cada salida debe tener estructura, fuentes, validaciones y criterios de rechazo. Los agentes posteriores no deberían tratar una inferencia como hecho. Los puntos de control humanos se colocan donde un error cambia de alcance o puede producir un efecto externo.
Si quieres recorrer la serie desde el principio, comienza por De QA Engineer a Quality Owner. Para convertirla en un proyecto profesional, utiliza el plan de 90 días.
¿Qué “mini agente” aportaría primero valor en tu flujo y qué control humano colocarías? Te leo en LinkedIn.