Agentes de IA para testing: que son, que funciona de verdad y como montarlo

Agentes de IA para testing: qué son, qué funciona de verdad y cómo montarlo


Buenas gente. En el post anterior sobre Playwright quedó picando un tema que hoy es imposible de esquivar en QA: los agentes de IA. La industria está llena de humo al respecto, así que la idea de este post es separar lo que realmente anda de lo que todavía es marketing, y sobre todo mostrar cómo se monta esto en la práctica, con comandos y configuración concreta.

Aviso desde el arranque: esto no reemplaza al QA. Lo que hace es correr la parte mecánica del trabajo. Quien decide qué vale la pena probar y si un fallo es real seguís siendo vos.

---

1. Tres niveles distintos (y no son lo mismo)

Cuando alguien dice "uso IA para testear" puede estar hablando de tres cosas muy diferentes:

[list=1]

• Asistente: le pedís a un chat que te escriba un test y lo pegás. La IA no ve tu app, no ejecuta nada, no verifica nada. Es autocompletado con esteroides. Útil, pero el código sale plausible, no correcto.
• Agente en el loop de desarrollo: la IA tiene herramientas. Abre un navegador real, navega tu app, escribe el test, lo corre, ve que falla, lo corrige y vuelve a correrlo hasta que pasa. Acá está el 90% del valor real hoy.
• Agente autónomo en runtime: no hay script. El agente explora la app sola y decide qué probar en cada corrida. Suena increíble y es donde está casi todo el humo: es no determinista, caro, y difícil de auditar.

La diferencia entre el nivel 1 y el 2 es el ciclo de verificación. Un modelo que no puede ejecutar lo que escribe está adivinando. Uno que ejecuta, ve el error y corrige, converge. Es exactamente la misma diferencia que hay entre escribir código a ciegas y escribirlo con un compilador al lado.

2. Cómo funciona un agente por dentro

Un agente no es magia, es un bucle. Literalmente esto:

   ┌─────────────────────────────────────────────────┐
   │                                                 │
   ▼                                                 │
┌──────────┐   "abrí /login y                  ┌──────────┐
│  MODELO  │──── contame qué ves" ────────────▶│ HERRAMIENTAS│
│  (LLM)   │                                   │  browser  │
│          │◀─── árbol de accesibilidad, ──────│  archivos │
└──────────┘     errores, screenshots          │  shell    │
   │                                           └──────────┘
   │ ¿terminé?
   ▼
┌──────────────────────┐
│ test.spec.ts escrito │
│ y verificado         │
└──────────────────────┘

El modelo pide una acción, una herramienta la ejecuta de verdad, el resultado vuelve al modelo, y así hasta que la tarea está cumplida. Todo lo demás (frameworks, productos, suscripciones) es packaging alrededor de este bucle.

El detalle técnico que más importa: qué le mandás al modelo como "lo que ve". Hay dos escuelas:

• Píxeles: le mandás un screenshot y el modelo decide dónde clickear por coordenadas. Caro en tokens, lento y frágil.
• Árbol de accesibilidad: le mandás la estructura semántica de la página (roles, nombres, estados) como texto. Es órdenes de magnitud más barato, más rápido y determinista.

En 2026 ganó la segunda por goleada, y es la razón por la que Playwright quedó tan bien parado en este terreno: su modelo de locators ya era semántico antes de que existieran los agentes.

3. MCP: el enchufe estándar


MCP (Model Context Protocol) es un protocolo abierto que estandariza cómo un modelo accede a herramientas externas. Antes de MCP, cada integración era un adaptador propietario. Ahora un servidor MCP expone herramientas y cualquier cliente compatible las consume.

Para QA esto importa porque existe @playwright/mcp, el servidor oficial de Microsoft que expone el control del navegador como herramientas MCP. Configuración típica en un cliente:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Con eso, el agente puede abrir páginas, interactuar con el DOM, correr tests y leer los artefactos que Playwright produce: traces, screenshots, videos y logs de red. Esto último es lo más subestimado: el agente no sólo actúa, también diagnostica con la misma información que usarías vos.

Un consejo de configuración que ahorra dolores: podés restringirlo.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--headless",
        "--isolated",
        "--allowed-origins", "http://localhost:3000;https://staging.miapp.com"
      ]
    }
  }
}

--allowed-origins es importante de verdad. Un agente con un navegador sin restricciones es un navegador que puede ir a cualquier lado con las cookies de tu sesión. Tratalo como lo que es: un proceso automatizado con acceso a red.

4. Playwright Agents: planner, generator y healer

Esto ya viene integrado en Playwright, no es un producto de terceros. Son tres agentes que se pueden usar por separado o en cadena:

• 🎭 Planner — explora la aplicación y produce un plan de pruebas en Markdown, legible por humanos, basado en los flujos de usuario que encuentra.
• 🎭 Generator — transforma ese plan en archivos de test de Playwright, verificando selectores y assertions contra la app real mientras los escribe.
• 🎭 Healer — ejecuta la suite y repara los tests que fallan: replica los pasos, inspecciona la UI, identifica el arreglo y vuelve a correr hasta que pasan.

Se inicializan con un comando, eligiendo con qué cliente los vas a manejar:

npx playwright init-agents --loop=vscode
npx playwright init-agents --loop=claude
npx playwright init-agents --loop=codex
npx playwright init-agents --loop=opencode

Ese comando genera las definiciones de los agentes en tu repo. Conviene volver a correrlo cuando actualizás Playwright, porque las definiciones traen las herramientas e instrucciones de la versión, y quedarse con las viejas te deja sin capacidades nuevas.

El flujo que sale de esto es bastante distinto al tradicional:

App corriendo
     │
     ▼
 [PLANNER] ──▶ specs/plan.md          ← acá revisás VOS
     │                                   (esto es el control de calidad)
     ▼
[GENERATOR] ─▶ tests/*.spec.ts        ← código determinista, versionado
     │
     ▼
  npx playwright test  ──── falla ───▶ [HEALER] ──▶ propone el arreglo
     │                                                     │
     └────────────────── pasa ◀────────────────────────────┘

El punto clave está en el primer paso: el plan sale en Markdown a propósito. Es el momento donde un humano lee "voy a probar login, checkout y recuperación de contraseña" y dice "falta el flujo de cupones vencidos, que es donde siempre se rompe". Ese es el trabajo de QA que la IA no hace.

Y el resultado final es código Playwright normal. Determinista, en git, revisable en un PR, que corre en CI sin llamar a ningún modelo. Eso es lo que separa un enfoque serio de una caja negra que cobra por corrida.

5. Triage automático de fallos en CI

Este caso de uso es, en mi experiencia, el de mejor relación valor/esfuerzo y casi nadie lo aprovecha.

El escenario clásico: la suite falla de noche en CI, a la mañana hay 14 tests en rojo y alguien tiene que abrir uno por uno para descubrir que 12 fallan por la misma causa. Un agente con acceso a los traces hace ese agrupamiento en minutos:

# el agente recibe la carpeta de artefactos y produce un resumen
npx playwright test --reporter=json > resultados.json
# → agente: leer resultados.json + traces, agrupar por causa raíz

La salida útil no es "14 tests fallaron", es:

GRUPO 1 (12 tests) — el endpoint /api/session devuelve 502
  → causa compartida, backend. No es un problema de los tests.
GRUPO 2 (1 test)  — el botón "Continuar" cambió de nombre a "Siguiente"
  → cambio legítimo de UI, el test necesita actualizarse.
GRUPO 3 (1 test)  — flaky: pasó en el reintento, race condition en el toast
  → revisar espera, no es regresión.

Eso convierte cuarenta minutos de trabajo tedioso en una revisión de dos minutos. Y no requiere confiar en la IA para nada crítico: sólo está ordenando información, vos seguís decidiendo.

6. Armar tu propio agente

Si querés algo a medida, no hace falta un producto. El bucle es corto. Ejemplo mínimo en Python con la API de Claude:

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    tools=[{
        "name": "correr_test",
        "description": "Ejecuta un archivo de test de Playwright y devuelve stdout/stderr.",
        "input_schema": {
            "type": "object",
            "properties": {"archivo": {"type": "string"}},
            "required": ["archivo"],
            "additionalProperties": False,
        },
        "strict": True,
    }],
    messages=[{
        "role": "user",
        "content": "Corré tests/login.spec.ts y si falla, decime la causa raíz.",
    }],
)

for bloque in resp.content:
    if bloque.type == "tool_use":
        print("quiere ejecutar:", bloque.input)

Vos ejecutás la herramienta, devolvés el resultado como `tool_result` y repetís mientras `stop_reason == "tool_use"`. Eso es todo el agente. Un detalle importante de diseño: poné el gate de aprobación en tu código, no en el prompt. Si una herramienta puede borrar datos, que tu función pida confirmación; pedirle al modelo que "no borre nada" no es un control de seguridad.

7. Qué funciona y qué no (sin vender humo)

Funciona hoy:

• Generación de tests a partir de una URL o un flujo descrito en lenguaje natural.
• Reparación de locators rotos por cambios de maquetado.
• Generación de tests unitarios con cobertura alta sobre código existente.
• Triage y agrupamiento de fallos en CI.
• Regresión visual con filtrado inteligente (menos falsos positivos por un píxel de antialiasing).

Todavía es humo:

• Reemplazar al QA. Nadie serio sostiene esto. La IA genera casos; decidir qué importa probar es criterio de producto y de riesgo.
• Diagnóstico de causa raíz confiable. Agrupa bien, pero atribuye mal con frecuencia.
• Testing no supervisado de lógica de negocio compleja. El agente no sabe que un descuento del 110% es un bug si nadie se lo dijo.
• Self-healing sin revisión. Y este merece párrafo aparte.

8. El riesgo serio del self-healing

Un healer que arregla tests solo y mergea sin que nadie mire es una máquina de ocultar bugs. Pensalo: el test falla porque el botón "Comprar" desapareció. El agente busca un elemento parecido, encuentra "Ver más", actualiza el locator, el test pasa, el pipeline queda verde. Acabás de automatizar el borrado de la evidencia de una regresión en producción.

La regla es simple y no tiene excepciones: todo arreglo de un agente entra por pull request y lo revisa una persona. Nunca commit directo, nunca auto-merge. El agente propone, el humano dispone. Si la única lectura que le dedicás es ver el check en verde, desactivá el healer, porque te está perjudicando.

9. Costos

Vale aclararlo porque suele sorprender: los agentes gastan tokens, y un bucle mal armado los quema rápido. Tres cosas que bajan la factura de forma inmediata:

• Árbol de accesibilidad en vez de screenshots siempre que se pueda. La diferencia es enorme.
• Prompt caching si mandás el mismo contexto de proyecto en cada corrida.
• Nunca en el camino crítico del CI. El agente genera y repara en desarrollo; el CI corre código determinista que no llama a ningún modelo. Esto además hace tu pipeline reproducible y rápido.

10. Por dónde empezar

Si nunca tocaste esto, esta secuencia funciona:

[list=1]

• Instalá Playwright en un proyecto real y conseguí que corra un test a mano. Sin esto, lo demás no tiene sentido.
• `npx playwright init-agents --loop=<tu cliente>`.
• Corré el planner sobre un flujo chico y leé el plan que genera. Vas a aprender más de las limitaciones de la herramienta en esos cinco minutos que en veinte artículos.
• Generá esos tests y revisá el código como revisarías el PR de alguien que recién entró: mirá los locators y las assertions con lupa.
• Recién ahí sumá healer, y siempre vía PR.

---

El resumen honesto: un agente de IA es un junior muy rápido, incansable y sin criterio propio. Le delegás el trabajo mecánico —escribir el andamiaje, actualizar locators, ordenar fallos—, y te quedás vos con lo que realmente define la calidad: decidir qué probar, qué riesgo importa y si un resultado en verde significa algo.

Quien use esto para escribir más tests va a tener más tests. Quien lo use para liberar tiempo y pensar mejor qué probar, va a tener mejores tests. No es lo mismo.

¿Alguien ya lo tiene andando en un proyecto real? Me interesa saber sobre todo cómo manejan la revisión de lo que genera el agente cuando el volumen crece, que me parece el cuello de botella no resuelto.

Saludos!