Agentes para QA: el agente propone con evidencia, el humano decide

Subtítulo: El sentido de la flecha que casi nadie da vuelta —no “testear agentes” sino “usar agentes para testear”—, el panorama de casos de uso anclado al portfolio, la línea roja de la casa y por qué QA tiene ventaja conceptual en este terreno.

Nota de alcance. Ejemplos ilustrativos; los casos de uso son un panorama, no un catálogo cerrado. Las herramientas agénticas cambian rápido: revalidá contra tu versión. La regla de diseño que atraviesa la colección —el agente propone, el humano decide— es una postura, no una limitación de la tecnología del momento.

Resumen ejecutivo

Buena parte de la conversación sobre agentes y calidad va en un sentido: cómo se testea un sistema que actúa solo. Esta colección va en el otro: qué puede hacer un agente por el trabajo de testing.
El panorama es amplio —generar casos por riesgo, reparar selectores, triagear fallos de CI, priorizar qué correr, revisar PRs de test, explorar flujos, auditar accesibilidad— y cada caso ya tiene su ancla en el portfolio.
La línea roja que ordena todo: un agente para QA propone con evidencia y un humano decide. El agente que auto-mergea su propio arreglo es el anti-patrón; el que abre un PR con trace, diff y justificación es la herramienta.
El auto-merge no falla solo por los bugs que deja pasar: entrena al equipo a ignorar la señal. Un agente que abre PRs mediocres produce flakiness social —la erosión de la confianza en un canal automatizado— exactamente como una suite flaky enseña a reintentar sin leer.
QA no llega a este terreno de prestado: la disciplina que sabe diseñar por riesgo, medir comportamiento agregado y desconfiar de las demos es la que mejor equipada está para poner a un agente a trabajar sin creerle de más.

Al terminar vas a poder: distinguir “QA de agentes” de “agentes para QA”, ubicar cada caso de uso en el panorama, argumentar por qué el auto-merge erosiona la confianza y defender la regla propone-evidencia-humano frente a un agente entusiasta.

1. El problema: la flecha que casi nadie da vuelta

Casi toda la serie apunta en una dirección: los agentes actúan, y hay que testearlos. Cómo se evalúa una trayectoria, cómo se los somete a red teaming, cómo se los mete en un sandbox. La flecha va de QA hacia el agente: el agente es el objeto de prueba.

Esta colección da vuelta la flecha. La pregunta no es “¿cómo testeo este agente?” sino “¿qué puede hacer un agente por mi trabajo de testing?”. El agente pasa de objeto de prueba a herramienta del que prueba. Y el cambio de rol trae una pregunta nueva, que es la que ordena todo lo que sigue: si un agente va a participar del trabajo de calidad, ¿hasta dónde se le deja decidir?

La respuesta fácil —“que haga todo, para eso está”— es la que produce los desastres más caros. La respuesta de esta colección es más incómoda y más útil: se le deja proponer, no decidir. La diferencia entre esas dos posturas no es de grado; es de diseño, y define si el agente suma o resta.

2. El panorama: qué puede hacer un agente por QA

El terreno es más grande de lo que parece desde el primer caso de uso obvio. Un agente con las herramientas adecuadas puede intervenir en casi cada etapa del trabajo de calidad. Lo que cambia de un caso a otro no es tanto la técnica como la clase de evidencia que el agente tiene que adjuntar para que su propuesta sea revisable.

Caso de uso	Qué propone el agente	La evidencia que adjunta	Dónde se profundiza
Generación de casos por riesgo	Casos nuevos priorizados por dónde más duele que se rompa	El mapa de riesgo y el hueco de cobertura que llena	Evaluar aplicaciones con LLM
Self-healing con criterio	Un selector de reemplazo cuando el original se rompe	El diff, el DOM viejo y el nuevo, por qué el selector propuesto es más estable	Self-healing de selectores
Triage de fallos de CI	Una categoría para cada rojo: producto, entorno, dato o test	La línea exacta del log y la regla que disparó la clasificación	Triage con un agente
Test impact inteligente	Qué subconjunto de la suite correr ante un cambio	El grafo de dependencias entre el diff y los tests afectados	Pipeline de calidad por riesgo
Revisión de PRs de test	Comentarios sobre un PR de automatización	El anti-patrón detectado y la línea donde vive	Quality gate en cada PR
Exploratorio sintético	Hallazgos de recorrer flujos reales sin script fijo	La secuencia de pasos y la captura donde algo se rompió	Exploratorio con computer use
Auditoría a11y asistida	Violaciones de accesibilidad candidatas a arreglo	El nodo, la regla WCAG y el impacto en el usuario	Accesibilidad en CI con axe

Hay un patrón en la columna de la evidencia, y no es accidental: en todos los casos el agente entrega algo que un humano puede leer y contradecir en minutos. Ese es el diseño. Un agente para QA cuyo output no se puede auditar rápido no es una herramienta de calidad; es una fuente nueva de trabajo de calidad.

3. La línea roja: propone → evidencia → humano decide

La marca de la casa cabe en un ciclo. El agente detecta algo, reúne la evidencia, la adjunta en un formato revisable —casi siempre un pull request— y ahí se detiene. La decisión de mergear, descartar o pedir más no es del agente: es de una persona con contexto que el agente no tiene.

        ┌───────────────────────────────────────────────────┐
        │                                                   │
        ▼                                                   │
   [1] El agente          [2] Reúne la            [3] Un humano
       detecta algo  ───►     evidencia    ───►       decide
       (fallo, selector       (trace, diff,          (merge / descarta /
        roto, riesgo)          log, regla)            pide más)
        │                       │                       │
        │                       ▼                       │
        │                 se adjunta al PR              │
        │                 revisable y citable           │
        └───────────────────────────────────────────────┘
              el agente NUNCA cierra su propio loop

La pieza que no se puede negociar es la flecha que falta: no hay una que vuelva del paso 3 al merge sin pasar por una persona. Un agente que detecta, arregla y mergea solo cerró el loop, y al cerrarlo eliminó justo el paso donde el juicio importa. La palabra clave es evidencia: no alcanza con que el agente proponga bien; tiene que mostrar por qué, con material que sobreviva a una revisión escéptica. Una propuesta sin evidencia adjunta no es revisable, y lo que no es revisable no debería mergear —lo proponga un agente o una persona.

Esto no es desconfianza del agente por principio. Es el mismo criterio con el que se trata cualquier automatización que tiene efectos: hasta que no se prueba que decide bien de manera consistente, decide un humano y la máquina prepara la decisión.

El error que esta colección combate no es un bug técnico: es una decisión de diseño que parece eficiencia y es deuda. Darle a un agente permiso para mergear sus propios cambios suena a productividad —“que arregle y siga, no me molestes con cada selector”—. El costo aparece más tarde y es más caro de revertir.

Un agente con auto-merge falla de dos maneras. La primera es obvia: mergea cosas mal. Un selector “arreglado” que en realidad tapa un cambio de UI que era un bug; un test “estabilizado” que ahora pasa siempre porque dejó de probar lo que probaba. La segunda es la peligrosa, porque es social. Cuando un agente abre PRs y los cierra solo, el equipo deja de mirarlos. Y cuando abre PRs mediocres que sí hay que revisar, entrena a todos a aprobarlos sin leer, porque “total, el agente ya lo hizo”.

Eso es flakiness social: la erosión de la confianza en una señal automatizada hasta que deja de informar. Es exactamente lo que le pasa a una suite de tests flaky. Un test que falla sin motivo enseña al equipo a reintentar sin leer el error; a la tercera falla real, nadie la mira, porque el reflejo ya es “dale de nuevo”. Un agente que produce ruido enseña lo mismo con otra cara. La confianza en un canal de calidad es un activo que se gasta rápido y se reconstruye lento.

La regla que evita las dos fallas es la misma: el agente propone, el humano decide, y la propuesta viaja con su evidencia para que decidir cueste minutos y no una investigación. Un PR con el trace, el diff y la justificación se aprueba o se rechaza leyendo. Un PR sin eso es una apuesta, y las apuestas no se mergean.

5. Por qué QA tiene ventaja conceptual

Hay una lectura pesimista de todo esto —“los agentes vienen por el trabajo de testing”— y es la equivocada. El terreno de aplicar agentes a la calidad premia exactamente las habilidades que definen a un buen Quality Engineer, y castiga las que no tiene quien viene solo del lado del entusiasmo.

Diseñar por riesgo. Un agente puede generar mil casos; elegir cuáles importan es criterio, no volumen. Quien sabe cubrir el riesgo en vez de inflar el número le da al agente el objetivo correcto.
Medir comportamiento agregado. Un agente no se juzga por su mejor demo sino por su consistencia sobre muchas corridas. Esa es la mentalidad de las evals, no la de la anécdota. Para el marco completo, ver Evaluar aplicaciones con LLM.
Desconfiar de las demos. La demo hipnótica de un agente que arregla un test solo es, para QA, una bandera roja, no una promesa. La pregunta profesional no es “¿anduvo?” sino “¿cada cuánto anduvo, y qué hace cuando no?”.

Ninguna de esas tres cosas es nueva. Son el oficio de siempre —diseño por riesgo, medición agregada, escepticismo ante lo que brilla— aplicado a una herramienta nueva. El dominio cambió; el criterio es el mismo. Por eso QA no llega a este terreno a defenderse: llega con ventaja.

6. Por qué esto es Quality Engineering

Un agente para QA bien diseñado no reemplaza el juicio: lo alimenta. Hace el trabajo mecánico de detectar, reunir y presentar, y deja intacto el trabajo que solo una persona con contexto puede hacer: decidir si esto que el agente encontró es un arreglo o un encubrimiento, una mejora o una regresión disfrazada. La regla propone-evidencia-humano no es una concesión temporal a modelos todavía inmaduros; es la forma correcta de conectar cualquier automatización potente con un sistema que tiene efectos reales.

Los tres artículos que siguen bajan esta regla a la práctica en tres casos concretos: triage de fallos de CI, donde el agente clasifica y cita la línea que lo llevó a clasificar así; self-healing de selectores, donde repara pero nunca mergea; y exploratorio sintético, donde recorre flujos que ningún script fijo cubría. En los tres, la misma línea roja.

Para ubicar todo esto en un plan de carrera —qué habilidades de QE se vuelven más valiosas cuando el agente hace el trabajo mecánico—, ver De QA Automation a Quality Engineering: el mapa de 180 días. Y para ver el estilo de evidencia que estos agentes deberían producir, los experimentos de diagnóstico y flakiness viven en qa-insights y flakiness-hunting-playwright.