Pruebas de UI con IA: Epsilon suma Amazon Nova Act a Playwright y recorta de horas a minutos sus flujos de 18 pasos

Escribir una prueba de interfaz que sobreviva a un rediseño es uno de los problemas más caros del desarrollo web, y Epsilon, la empresa de datos y marketing de Publicis Groupe, lo ha atacado sin tirar a la basura lo que ya funcionaba. Su equipo de plataforma agéntica lanzó un servicio de pruebas de UI con IA donde los casos de prueba se escriben en inglés llano, y lo ofrece como capacidad gestionada a todos sus equipos de producto. Según un resumen publicado por AI Digest, un flujo de 18 pasos pasa de 30-90 minutos de autoría en Playwright a 5-10 minutos, es decir, una autoría 4-6 veces más rápida. Es una cifra reportada por esa fuente secundaria, no un benchmark independiente.

La clave es el enfoque. Epsilon no reemplazó su suite de regresión en Playwright, que sigue siendo su columna vertebral para comprobaciones deterministas. Encima añadió una capa de testing basado en intención con Amazon Nova Act y Amazon Bedrock AgentCore Browser Tool. Detrás hay un equipo de 50 ingenieros que construye infraestructura compartida para que los demás equipos desplieguen agentes sin resolver identidad, seguridad ni navegadores por su cuenta. Un usuario crea un flujo vía API con una URL objetivo y una lista de pasos en lenguaje natural, como «confirma que el saldo de recompensas es visible». Un ejecutor en segundo plano (Celery) abre una sesión de navegador aislada y ejecuta cada paso, con lógica condicional del tipo «si aparece un tour guiado, ciérralo». Captura una captura de pantalla por paso, calcula la tasa de aciertos y guarda todo en Amazon S3. Las tareas se encolan en Amazon SQS y corren en Amazon ECS. La capacidad se expone como un agente estándar, `ui-test-agent`, con dos habilidades: grabar escenarios y ejecutarlos.

Por qué Epsilon eligió pruebas de UI con IA gestionadas y no un CLI más

El problema no era que Playwright fallara. Sus pruebas dependen de selectores y estructura de página, así que un cambio cosmético puede romperlas aunque la funcionalidad esté intacta. Además, cada equipo tenía que montar su propia infraestructura de navegadores, dependencias e integración de identidad. Epsilon quería un servicio multi-tenant, no una herramienta que cada equipo operara por su cuenta.

La arquitectura encaja con su modelo de seguridad. La autenticación usa la cadena estándar de credenciales de AWS, sin repartir API keys. El aprovisionamiento usa AssumeRole entre cuentas, de modo que cada equipo ejecuta sus pruebas en su propia cuenta con un rol acotado. Las sesiones de navegador efímeras incluyen vista en vivo para intervención humana (útil con CAPTCHAs o autenticación multifactor), grabación en S3 y auditoría en CloudTrail. Como resume un análisis de CloudNinjas, el cambio reduce el mantenimiento de pruebas y aísla la infraestructura sin romper los flujos de IAM existentes.

Otro caso de AWS apunta en la misma dirección. En su guía sobre pruebas de experiencia de usuario, Nova Act se presenta como un modelo multimodal que «lee» capturas de pantalla como lo haría un tester humano. Ese enfoque permite generar escenarios a partir de documentación con Amazon Bedrock y ejecutarlos en paralelo, y sus logs de razonamiento dan pistas sobre la usabilidad del sitio.

Cómo aplicar las pruebas de UI con IA en tu empresa

La lección principal es que la IA se adopta mejor como capa adicional que como sustitución. Si tu equipo ya tiene regresión automatizada, no la desmontes. Estos son los pasos que sugiere el caso:

Separa lo determinista de lo semántico. Deja en scripts lo que debe ser exacto (cálculos, contratos de API) y pasa a lenguaje natural lo que solo exige «que se vea y funcione» (flujos de login, saldos visibles, checkout).

Empieza por los tests que más se rompen. Mide cuántos fallos de tu suite actual vienen de cambios cosméticos y no de bugs reales. Ese porcentaje es tu caso de negocio.

Convierte la capacidad en servicio. Epsilon evitó el trabajo duplicado ofreciendo el testing con la misma API que usan para cualquier otro agente. Si tienes varios equipos de producto, centraliza identidad, navegadores y permisos, como ya hacen otras plataformas multi-tenant seguras sobre Amazon Bedrock.

Haz el onboarding casi trivial. Epsilon solo provisiona un rol entre cuentas, registra las URL de la aplicación y concede acceso al agente. Una puerta de entrada MCP bien diseñada muestra cuánto tiempo se ahorra cuando incorporar a un equipo se reduce a minutos.

Exige trazabilidad desde el primer día. Capturas por paso, resultados estructurados, grabación de sesión y auditoría convierten una prueba «mágica» en un resultado que se puede revisar.

Cuándo tiene sentido dar el paso

El momento es ahora si tu ritmo de cambio en la interfaz supera tu capacidad de mantener scripts. Con asistentes de código que multiplican los cambios, escribir código ya no es el cuello de botella y la validación pasa a serlo. Conviene esperar si tu aplicación es estable, si tu cobertura actual rara vez se rompe por razones estéticas o si no tienes aún una base de identidad y permisos que permita ejecutar agentes con seguridad.

También hay cautelas. Las cifras de velocidad vienen de una fuente secundaria y conviene validarlas con tus propios flujos. Los modelos que interpretan pantallas pueden comportarse de forma distinta a un selector exacto, así que no son un sustituto de la regresión determinista. Epsilon lo asume al mantener Playwright.

La pregunta para tu equipo

Las pruebas de UI con IA no prometen eliminar a QA, sino liberarlo del mantenimiento que menos valor aporta. Antes de abrir una prueba piloto, haz un inventario: ¿cuántas de las pruebas que fallaron el último trimestre rompieron por un cambio de botón y no por un bug real? Si la respuesta es «muchas», ya tienes tu primer candidato para escribir en lenguaje natural.