Amazon Nova Act propone otra forma de probar la experiencia web

Probar una web no consiste solo en comprobar que un botón funciona. Una compra puede completarse sin errores técnicos y, aun así, resultar confusa: quizá el buscador oculta los filtros, el menú no anticipa dónde está una función o el proceso de registro exige pasos inesperados. Ese territorio es el de la experiencia de usuario, y Amazon Web Services ha publicado una arquitectura de referencia que propone recorrerlo con agentes de IA que operan un navegador.

El ejemplo utiliza Amazon Nova Act para ejecutar recorridos de usuario en paralelo y combina automatización, documentación interna y análisis de resultados. No es un estudio independiente que demuestre que un modelo sustituya a todas las herramientas de pruebas. Sí es una explicación concreta de cómo una empresa podría ampliar las pruebas de experiencia más allá de unas pocas rutas críticas.

QA y UX miden problemas distintos

Las pruebas de calidad tradicionales se centran en comprobar requisitos funcionales: que una cuenta se cree, que un formulario guarde los datos o que una compra no falle. Las pruebas de UX preguntan además si una persona encuentra el camino, entiende las opciones y se atasca antes de lograr su objetivo. Son preguntas relacionadas, pero no equivalentes.

AWS plantea que el límite práctico está en la cobertura. Un equipo humano no puede repetir cada recorrido posible, en cada variante de navegación y con cada cambio de interfaz. La automatización convencional ayuda, pero suele depender de selectores y guiones rígidos. Cuando una página cambia, esos guiones pueden requerir mantenimiento aunque la intención del usuario siga siendo la misma.

La propuesta de Nova Act parte de otra unidad de trabajo: una instrucción expresada como objetivo. En lugar de codificar únicamente que hay que pulsar un elemento concreto, un flujo puede pedir encontrar un producto, modificar una preferencia o completar un registro. El agente observa la interfaz en el navegador y ejecuta acciones para avanzar. Eso no elimina la necesidad de diseñar casos de prueba; cambia la forma de expresar y ejecutar parte de ellos.

De la documentación a un recorrido comprobable

La arquitectura descrita por AWS tiene cuatro capas. Primero, reúne manuales, especificaciones y documentos de recorridos en Amazon S3. Esos materiales alimentan una base de conocimiento de Amazon Bedrock que permite recuperar contexto sobre cómo debería funcionar el sitio.

Después, una función de AWS Lambda usa Claude 4.5 Sonnet en Bedrock para convertir tareas de usuario en instrucciones de prueba. AWS propone producirlas con distintos niveles de detalle: desde un objetivo amplio hasta una secuencia paso a paso. Esta diferencia es útil porque permite comprobar si una interfaz se deja descubrir con una indicación breve o solo responde cuando se le dicta exactamente el camino.

Los flujos generados se guardan con sus parámetros en Amazon DynamoDB. Cuando están listos, otras funciones coordinan su ejecución y lanzan tareas en Amazon ECS con Fargate. Ahí es donde Nova Act abre sesiones de navegador y recorre los flujos en paralelo. La paralelización no equivale a una garantía de calidad, pero permite observar más recorridos y variantes en menos tiempo que una revisión manual aislada.

El resultado no debería ser solo aprobado o suspendido

La parte valiosa del ejemplo está en lo que conserva después de cada ejecución. La solución almacena en S3 resúmenes, capturas y datos de interacción; después procesa los resultados para identificar patrones, medir tiempos, separar ciertos fallos de infraestructura y señalar puntos de fricción. El repositorio de AWS añade trazas HTML, registros JSON y un panel web para revisar los resultados.

Con ese material, un equipo puede hacer preguntas más útiles que si una prueba terminó bien. Puede comparar cuántos pasos exige una ruta, cuánto tarda cada etapa o qué instrucciones provocan errores repetidos. También puede contrastar una misma tarea planteada mediante búsqueda o mediante navegación por menús. Esa comparación conecta las pruebas técnicas con decisiones de diseño, siempre que las métricas se interpreten junto a observaciones de personas reales.

No conviene convertir una puntuación de usabilidad producida por un sistema automático en un veredicto definitivo. Un agente puede detectar fricción operativa, pero no representa por sí solo la diversidad de necesidades, expectativas y contextos de una audiencia. Para una web pública, las pruebas con usuarios, la accesibilidad y la revisión de equipos de producto siguen siendo complementos necesarios.

Dónde empieza el trabajo difícil

Automatizar un navegador que ha iniciado sesión exige disciplina. AWS indica que su ejemplo puede mantener sesiones persistentes para flujos autenticados; esa posibilidad obliga a usar cuentas de prueba, permisos mínimos y datos no sensibles. También hay que definir qué acciones quedan fuera de alcance: un agente de pruebas no debería generar compras reales, modificar información de producción ni sortear controles diseñados para las personas.

La documentación tampoco es un detalle administrativo. Si describe mal el producto, los recorridos generados heredarán esa confusión. Por eso AWS recomienda un enfoque híbrido: generar una cobertura inicial desde documentación existente y añadir flujos manuales para casos límite, funciones nuevas o escenarios que requieren precisión. Es una recomendación razonable: la automatización amplía el mapa, pero no decide por sí sola qué debe ser importante en él.

Nova Act se presentó inicialmente como un modelo para acciones en navegadores y AWS lo sitúa hoy dentro de un recorrido de exploración, desarrollo, despliegue y monitorización. La arquitectura de UX testing muestra una aplicación específica de esa idea: usar un agente no para responder una pregunta, sino para recorrer una interfaz y dejar evidencia de lo que ocurrió.

Una herramienta para mirar más, no para mirar menos

La novedad no es que las empresas prueben sus webs automáticamente. La aportación de este ejemplo es unir documentación, instrucciones en lenguaje natural, ejecución visual y análisis en una misma cadena. Si se aplica con datos de prueba, supervisión y criterios claros, puede ayudar a descubrir rutas que una batería de pruebas tradicional no había cubierto.

La medida de su utilidad será menos espectacular y más práctica: si permite a un equipo encontrar antes una pantalla confusa, entender por qué falla un recorrido y corregirlo sin perder de vista a las personas que usarán el producto.