Testing agéntico: el papel de los agentes en la pila de pruebas E2E

• El equipo de ingeniería de Slack ejecutó más de 200 flujos agentic para comprobar si las pruebas E2E (End-to-End) basadas en agentes podrían reemplazar a las pruebas determinísticas tradicionales
• Mientras que las pruebas E2E tradicionales obligan a seguir rutas de UI predefinidas, los agentes verifican si se cumple un objetivo (goal) y pueden llegar al mismo resultado por caminos distintos
• Cada ejecución de agente toma más de 10 minutos y cuesta entre $15 y $30, pero existen casos de uso claros desde la perspectiva de confiabilidad
• El enfoque de Playwright MCP registró una menor tasa de fallas y un uso de tokens más bajo que los enfoques con CLI o generación de código, y la estabilidad del entorno de ejecución resultó decisiva
• El testing agéntico no reemplaza las pruebas existentes, sino que se agrega en la parte superior de la pirámide de testing como una capa para exploración, depuración y validación de comportamientos complejos

---

Del recorrido al objetivo (From Journeys to Goals)

• Las pruebas E2E tradicionales validan un recorrido (journey) específico siguiendo la UI → clic → clic → entrada → aserción (assert)
• Las pruebas basadas en agentes validan si es posible cumplir un objetivo expresado con una instrucción como "enviar un mensaje en un hilo" → objetivo → adaptación del agente → validación del resultado
  • Diferencia clave: "las pruebas fuerzan el recorrido, y los agentes validan el objetivo"
• El flujo completo (inicio de sesión → búsqueda → resultado → reinicio) se mantuvo constante, pero el orden real de las acciones cambió en cada ejecución
  • Distintas formas de entrada (hacer clic en una sugerencia de búsqueda vs presionar Enter)
  • Distintos patrones de navegación (volver a ejecutar la búsqueda vs reutilizar el estado existente)
  • Pasos agregados u omitidos (clics adicionales, snapshots, acciones intermedias)
• Esa flexibilidad viene con trade-offs en confiabilidad, costo y tiempo de ejecución

• El problema planteado

  • La pregunta central era si un método que tarda más de 10 minutos y cuesta entre $15 y $30 por ejecución puede formar parte de un flujo de testing moderno
  • Tras más de 200 ejecuciones, confirmaron que es fundamentalmente distinto a las pruebas tradicionales, pero con alta confiabilidad y casos de uso bien definidos
  • Los avances en modelos de lenguaje grandes (LLM), que permiten escribir código, depurar fallas y manipular la UI directamente, hicieron posible este nuevo modelo de ejecución

Configuración del experimento (Our Experiment)

• Se realizaron más de 200 ejecuciones automáticas en varias configuraciones para medir confiabilidad, velocidad de ejecución y costo

• Modelo de ejecución (tres enfoques)

  • Agent + Playwright MCP: el agente interactúa con el navegador mediante acciones predefinidas (hacer clic en elementos, escribir, leer el estado del DOM, etc.) y mantiene contexto persistente (snapshots del DOM y logs)
  • Agent + Playwright CLI: ejecuta comandos de Playwright CLI en la shell para procesar un paso a la vez, revisa el estado actualizado de la UI y decide la siguiente acción
  • Generated Playwright Tests: un agente de IA genera código determinístico de Playwright a partir de una descripción en lenguaje natural, lo ejecuta como prueba E2E estándar y lo mejora iterativamente hasta que pase

• Entorno experimental

  • Modelo de agentes MCP y CLI: Claude Sonnet 4.5
  • Modelo para pruebas Playwright generadas: Claude Opus 4.6
  • Ejecución: Claude Code no interactivo (claude -p)
  • Herramientas de navegador: Playwright MCP, Playwright CLI
  • Entorno: Slack Dev API MCP; todos los experimentos se realizaron en un workspace de pruebas con datos no productivos

• Flujo de pruebas (dos niveles de complejidad)

  • Thread Reply (simple): flujo de unas 15–20 etapas que incluye crear un canal, enviar un mensaje, responder en el hilo y verificar el estado del hilo
  • Search Discovery (complejidad media): flujo de unas 25–30 etapas que incluye ingresar una consulta de búsqueda, explorar resultados, moverse entre vistas (búsqueda, canal, hilo) y verificar el resultado esperado

• Formato de entrada

  • Lenguaje natural (NL): instrucciones legibles por humanos que describen el flujo y el resultado esperado en una lista paso a paso
  • YAML estructurado: el mismo flujo expresado de forma estructurada con pasos, acciones, objetivos y resultados esperados
    • La diferencia no es el nivel de detalle, sino la forma de expresión: en lenguaje natural el agente debe interpretar y mapear; en YAML ese mapeo queda más explícito

• Matriz del experimento

  • Cada configuración se ejecutó 20 veces, para un total de 5 experimentos (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, pruebas generadas-NL) aplicados a los dos flujos Thread Reply y Search Discovery

Lo que observaron (What We Observed)

• Resumen de resultados

  • Agent (Playwright MCP): tasa de fallas de 0% (thread reply) / ~12% (search discovery), promedio de 5–8 minutos
  • Agent (Playwright CLI): tasa de fallas de ~12% / ~20%, promedio de 9–11 minutos
  • Generated Playwright Tests: tasa de fallas de ~8% / ~48%, promedio de 3 minutos

• Confiabilidad (Reliability)

  • A medida que el flujo se vuelve más complejo, el cambio en confiabilidad se hace más evidente
  • Playwright MCP fue el más estable: casi 0% de fallas en escenarios simples y entre 0–12% incluso en flujos complejos
  • Playwright CLI mostró tasas de falla más altas (~12–20%), principalmente por problemas de ejecución como autenticación, timing de navegación e inestabilidad de sesión, no por razonamiento del modelo
  • Las pruebas generadas funcionaron bien en flujos simples (~8%), pero empeoraron mucho en flujos complejos (~48%)
    • No eran totalmente incorrectas; normalmente avanzaban hasta 70–80% del flujo antes de fallar en la interacción o aserción final
    • La causa fue la variabilidad del estado de la UI y desajustes de abstracción: se generaban desde flujos en lenguaje natural especificados de forma laxa y reutilizaban abstracciones existentes de page objects, lo que dificultaba apuntar con precisión a los elementos
  • Cuanto mayor es la complejidad, mayor es la brecha de confiabilidad, y los modelos de ejecución nativos para agentes como MCP son más estables
    • MCP mantiene una vista estable y en tiempo real de la app, mientras que CLI reconstruye el estado a partir de snapshots en cada paso, por lo que la desalineación se acumula a medida que el flujo se alarga
    • Parece que MCP reutiliza interacciones exitosas de pasos previos dentro de la sesión, mientras que CLI da la impresión de reiniciar desde cero en cada paso (aunque no se midió explícitamente)

• Velocidad (Speed)

  • Las pruebas generadas fueron consistentemente las más rápidas (~3 minutos), frente a MCP con ~5–8 minutos y CLI con ~9–11 minutos
  • Esa cifra de pruebas generadas incluye generación + ejecución; cada prueba se generó una vez y luego se ejecutó 5 veces para calcular el promedio
    • La ejecución pura real es mucho más rápida: thread reply ~32 segundos, search discovery ~45 segundos
    • En entornos de CI con ejecuciones repetidas, el costo único de generación se vuelve despreciable, por lo que las pruebas determinísticas escalan de forma eficiente
  • Los flujos agentic pagan el costo en cada ejecución: cada paso implica observar el estado de la UI, inferir la siguiente acción, ejecutarla y validar el resultado

• Adaptabilidad (Adaptability)

  • Solo ~20% de las ejecuciones siguieron exactamente la misma secuencia de acciones; la mayoría encontró distintos caminos válidos en la UI para llegar al mismo objetivo
    • Abrir menús en distinto orden
    • Elegir elementos de UI ligeramente diferentes
    • Usar flujos de navegación alternativos
  • Para medirlo, compararon entre ejecuciones la firma de acción (action signature): la lista ordenada de llamadas a herramientas y acciones de UI realizadas por el agente
    • Antes de comparar, la normalizaron: unificaron parámetros, acciones de espera/snapshot y variantes equivalentes de herramientas (fill vs type) para calcular solo diferencias significativas
  • Aunque el resultado final fuera correcto, el orden de acciones casi siempre cambiaba: el E2E tradicional fuerza un único recorrido determinístico; el agente explora la interfaz y valida si alcanza el estado objetivo

• Costo y de dónde viene (Cost and Where It Comes From)

  • Las ejecuciones con agentes suelen costar entre $15 y $30 por corrida, mucho más que las pruebas tradicionales
  • Análisis del uso de tokens en el mismo flujo search discovery
    • MCP (Opus 4.6) ~3.8M, MCP (Sonnet 4.5) ~3.5M, MCP (Haiku 4.5) ~5.7M
    • CLI (Opus 4.6) ~6M, Code Gen (Opus 4.6) ~7M
  • Importa más cómo se ejecuta que qué modelo se usa: Haiku consumió más tokens, pero todos los enfoques MCP usaron menos tokens que CLI o Code Gen
  • Análisis del modo de ejecución por sesión de Claude Code: la API subyacente es sin estado (stateless), así que en cada turno se reenvían el prompt completo del sistema y todo el historial de conversación
    • El costo no lo determina la salida del modelo, sino la velocidad de acumulación del contexto y la cantidad de turnos
  • Cantidad de turnos: MCP (Opus/Sonnet) ~40, MCP (Haiku) ~60, CLI (Opus) ~85, Code Gen (Opus) ~70
    • En CLI, cada interacción con el navegador se divide en múltiples comandos como acción, espera, snapshot, lectura y búsqueda de elementos, lo que lleva a un promedio de 85 turnos
    • MCP combina interacción y retorno de estado en un solo ida y vuelta
    • Cada turno adicional suma el costo del prompt completo del sistema y la carga de reenviar el contexto previo de la conversación
  • Elementos que llenan el contexto
    • MCP y CLI: los snapshots del navegador son la carga principal; los snapshots del árbol de accesibilidad (accessibility tree) que devuelve Playwright MCP se acumulan en todos los turnos posteriores
    • Code Gen: en cada reintento se acumula la salida completa del test runner con trazas de error, fallas de aserción y estado del DOM
  • La mayor parte del costo proviene de reenviar contenido ya visto; la información nueva por turno es mínima
  • El uso de tokens todavía no se había optimizado; proponen reducirlo con prompt caching, compactación de contexto (compaction) y menor frecuencia de snapshots
  • Por costo, hoy resulta más adecuado para depuración dirigida y testing exploratorio que para ejecuciones frecuentes en CI, aunque eso podría mejorar con futuros modelos y herramientas

• La importancia de la infraestructura (MCP vs CLI)

  • No solo el modelo importa: el entorno de ejecución también afecta mucho la confiabilidad; MCP tuvo 0–12% de fallas frente a 12–20% en CLI
  • La mayoría de las fallas en CLI provinieron de problemas de autenticación y navegación (errores de login, timeouts, inestabilidad de sesión), es decir, problemas de la capa de ejecución y no del razonamiento del agente
  • Playwright MCP ofrece primitivos de navegador estructurados y una integración estrecha con el flujo de llamadas de herramientas del agente, mientras que CLI introduce una capa adicional entre el agente y el navegador
  • Diferencia en paralelización: MCP facilita la ejecución concurrente; CLI la dificulta, por lo que la mayoría de las corridas fueron secuenciales
  • La confiabilidad, la velocidad y el costo dependen no solo del modelo, sino también de la estabilidad y el diseño del entorno de ejecución

• Límites de la capacidad de ejecución (Execution Capability Boundaries)

  • Este experimento se centró en flujos de UI de una sola sesión
  • Los flujos entre workspaces o aquellos que abren múltiples ventanas del navegador plantean retos distintos, donde la elección del modelo de ejecución se vuelve tan importante como el agente mismo
    • MCP podría enfrentar problemas de costo al aumentar el loop de observación en flujos largos
    • CLI podría enfrentar más complejidad de coordinación y mayor uso de tokens al manejar múltiples sesiones de navegador
  • Ambos enfoques pueden soportarlos, pero con trade-offs diferentes; este experimento no los exploró y el equipo de evaluación los considera un punto importante a analizar

Dónde encaja el testing agéntico en la pirámide de pruebas

• El testing agéntico no reemplaza los enfoques existentes; agrega una nueva capacidad por encima de ellos

• Pruebas E2E determinísticas

  • Son las más adecuadas para regresiones rápidas y repetibles en CI
    • Escritas por humanos o generadas por IA
    • Rápidas y repetibles, amigables con CI
    • Bajo costo operativo
    • Obligan a seguir un recorrido específico en la UI

• Testing agéntico

  • No ejecuta un script fijo, sino que parte de un objetivo: observa la UI, razona sobre el estado actual y decide cómo llegar al resultado deseado
    • Explorar comportamientos complejos de la UI
    • Depurar flujos inestables (flaky)
    • Reproducir bugs de producción

• La pirámide de pruebas con una capa agéntica

  • Desde la perspectiva del sistema, el testing agéntico valida flujos reales de usuario vía la UI al mismo nivel que E2E; la diferencia está en cómo se ejecuta el flujo
  • La estrategia de testing más efectiva del futuro combinará ambos: las pruebas determinísticas aportan la base estable para CI, y el testing agéntico se encarga en la cima de la pirámide de la exploración, la depuración y la validación de comportamientos complejos