Epsilon ya escribe pruebas de UI en frases simples. Conservó Playwright, y esa es la lección

Una prueba de UI típica en Epsilon, la empresa de marketing propiedad de Publicis Groupe, solía ser de 80 a 150 líneas de código Playwright. La misma prueba ahora se puede escribir como 18 frases que describen lo que hace un usuario: abrir la página de la campaña, filtrar por región, comprobar que los totales coinciden. Según las cifras internas de Epsilon, la autoría pasa de 30 a 90 minutos a 5 a 10.

Ese es el titular de la implementación que AWS publicó el 29 de octubre. La parte más instructiva es lo que Epsilon no cambió.

El servicio, no la herramienta

El equipo de Agentic Platform de Epsilon, unos 50 ingenieros, construyó las pruebas guiadas por intención como un servicio compartido multitenant, para que los equipos de producto no tengan que operar cada uno su propia infraestructura de navegador. Por debajo están Amazon Nova Act, que convierte pasos en lenguaje natural en acciones de navegador, y AgentCore Browser Tool, que ofrece sesiones gestionadas de navegador headless con vista en vivo, grabaciones de sesión almacenadas en S3 y auditoría con CloudTrail.

El servicio se expone internamente como un agente con dos skills: una graba una prueba y otra la ejecuta. Cada tenant se ejecuta bajo un rol con alcance limitado que se asume entre cuentas, de modo que las pruebas de un equipo no pueden tocar los entornos de otro, y cada sesión es atribuible.

Explorar una vez y luego reproducir

La decisión de diseño que lo hace usable en CI es la separación en dos estados.

En draft, el agente explora: lee las frases, resuelve cómo ejecutarlas en la página actual y reintenta cuando falla. Epsilon informa que una prueba suele necesitar cuatro o cinco iteraciones de prompt para superar esta fase. La exploración es donde la flexibilidad del modelo rinde y donde es lenta y consume llamadas al modelo.

En active, el servicio reproduce la trayectoria guardada de la ejecución exitosa en lugar de volver a preguntar al modelo. Epsilon informa de una tasa de éxito del 100 por cien en la reproducción de trayectorias a lo largo de ejecuciones repetidas. La reproducción es más rápida, más barata y, sobre todo, repetible, que es lo que una prueba necesita ser.

Es la misma idea que describimos en cuando el trabajo del agente debe volverse software: dejar que el modelo resuelva el problema una vez, conservar la solución y sacar al modelo del bucle. Una prueba que un modelo reinterpreta en cada ejecución no es una prueba de regresión: es un experimento nuevo cada vez.

Por qué Playwright se queda

Epsilon mantiene su suite de Playwright como la columna vertebral de la regresión. Las pruebas en lenguaje natural son adicionales: abaratan cubrir recorridos que nunca tuvieron una prueba escrita en código y permiten expresar intención que los responsables de producto pueden leer. No sustituyen las pruebas deterministas de regresión, accesibilidad, rendimiento o seguridad.

Hay razones prácticas más allá del principio. El endpoint de firma de Nova Act está en US East independientemente de dónde se ejecute la sesión de navegador, algo que importa a los equipos con restricciones regionales. Los valores por defecto de viewport del navegador hay que tenerlos en cuenta en los pasos de scroll. Y todas las cifras anteriores son benchmarks internos de Epsilon, no mediciones independientes de detección de defectos.

Qué se puede trasladar a otros equipos

Trate las pruebas de computer use como infraestructura de plataforma. Las sesiones de navegador, las credenciales para entornos de prueba, las grabaciones y la auditoría son iguales para todos los equipos. Construirlas una vez es de donde vino el apalancamiento de Epsilon.

Convierta la trayectoria en el artefacto. Revise y versione la trayectoria grabada como si fuera código. Cuando la UI cambia y la reproducción falla, la prueba vuelve a draft y una persona aprueba la nueva trayectoria.

Mantenga la suite determinista. Las pruebas de intención amplían la cobertura. Las pruebas en código mantienen el suelo. A medida que los agentes de codificación escriben más de la aplicación, ambas importan más, porque la evidencia de que el software funciona tiene que venir de fuera del modelo que lo escribió.

La prueba basada en frases es la novedad visible. La trayectoria reproducida es la razón por la que puede ejecutarse en un pipeline cada noche.