Amazon Nova Act proposes another way to test web experience

Testing a website is not only about checking whether a button works. A purchase can complete without a technical error and still be confusing: search may hide filters, a menu may not reveal where a feature lives, or registration may introduce unexpected steps. That is the territory of user experience, and Amazon Web Services has published a reference architecture that uses AI agents operating a browser to examine it.

The example uses Amazon Nova Act to run user journeys in parallel, combining automation, internal documentation, and result analysis. It is not an independent study showing that a model replaces every testing tool. It is, however, a concrete account of how an organization could extend experience testing beyond a handful of critical paths.

QA and UX measure different problems

Traditional quality-assurance testing checks functional requirements: an account is created, a form saves its data, or a purchase does not fail. UX testing also asks whether a person can find the route, understand the available choices, and avoid getting stuck before reaching a goal. The questions are related, but they are not the same.

AWS frames the practical limit as coverage. A human team cannot repeat every plausible journey, navigation variant, and interface change. Conventional automation helps, but it often relies on selectors and rigid scripts. When a page changes, those scripts can need maintenance even if the user intention remains unchanged.

Nova Act starts from a different unit of work: an instruction expressed as a goal. Rather than encoding only a click on one particular element, a flow can ask the agent to find a product, change a preference, or complete a registration. The agent observes the interface in a browser and takes actions to progress. That does not remove the need to design test cases; it changes how some of them are expressed and executed.

From documentation to a testable journey

The AWS design has four layers. First, it collects manuals, specifications, and journey documents in Amazon S3. Those materials feed an Amazon Bedrock knowledge base that retrieves context about how the site is expected to work.

Next, an AWS Lambda function uses Claude 4.5 Sonnet in Bedrock to turn user tasks into testing instructions. AWS suggests producing several levels of detail, from a broad goal to a step-by-step sequence. That difference matters because it can test whether an interface is discoverable from a short prompt or works only when it is given the exact route.

The generated flows are stored with execution parameters in Amazon DynamoDB. When they are ready, other functions coordinate execution and launch Amazon ECS tasks on Fargate. Nova Act then opens browser sessions and runs the flows in parallel. Parallelism is not a quality guarantee, but it can expose more journeys and variants in less time than an isolated manual review.

The output should not be only pass or fail

The useful part of the example is what it keeps after each execution. The solution stores summaries, screenshots, and interaction data in S3, then processes the results to identify patterns, measure timings, separate some infrastructure failures, and flag friction points. The AWS repository adds HTML traces, JSON logs, and a web dashboard for reviewing results.

With that material, a team can ask more useful questions than whether a test completed. It can compare how many steps a route needs, how long each stage takes, or which instructions produce repeated errors. It can also contrast the same task attempted through search and through menu navigation. That comparison connects technical testing with design decisions, provided the metrics are interpreted alongside observations from real people.

An automatically produced usability score should not become a final verdict. An agent can reveal operational friction, but it does not alone represent the different needs, expectations, and contexts of an audience. User research, accessibility work, and product-team review remain necessary complements for a public website.

Where the difficult work begins

Automating a signed-in browser requires discipline. AWS says its example can maintain persistent sessions for authenticated flows; that capability calls for test accounts, least-privilege access, and non-sensitive data. Teams also need to define actions that are out of scope. A testing agent should not make real purchases, alter production information, or bypass controls intended for people.

Documentation is not an administrative afterthought either. If it describes the product poorly, generated journeys will inherit that confusion. AWS therefore recommends a hybrid approach: generate an initial baseline from existing documentation and add manually defined flows for edge cases, new features, or scenarios that require precision. The recommendation is sensible. Automation expands the map, but it does not decide on its own what should matter on it.

Nova Act was first introduced as a model for taking actions in browsers, and AWS now places it within a path of exploration, development, deployment, and monitoring. The UX-testing architecture illustrates one specific use of that idea: using an agent not to answer a question, but to travel through an interface and leave evidence of what happened.

A tool to look more closely, not less

The news is not that companies test websites automatically. The contribution of this example is to join documentation, natural-language instructions, visual execution, and analysis in one chain. Used with test data, supervision, and clear criteria, it can help teams discover routes that a conventional test suite had not covered.

Its value will be less dramatic and more practical: whether it lets a team find a confusing screen sooner, understand why a journey fails, and fix it without losing sight of the people who will use the product.