Amazon Nova Act: como a IA pode ampliar testes de interface sem substituir o Playwright

Pessoa testa um painel web genérico em um notebook enquanto acompanha uma lista de verificações; a marca AWS e o nome Amazon Nova Act aparecem no canto inferior direito.Software
Capa editorial gerada para ilustrar testes de interface com Amazon Nova Act. A tela é conceitual e não reproduz uma aplicação real nem o serviço da AWS.

Uma equipe da Epsilon, empresa de tecnologia do grupo Publicis, combinou Amazon Nova Act e navegador gerenciado da AWS para criar testes de interface escritos em linguagem natural. O ponto mais útil do caso, publicado pela AWS em 29 de outubro de 2026, é que a IA não substituiu a suíte de regressão em Playwright: ela acrescentou uma forma de cobrir jornadas visuais que quebram quando a interface muda, mesmo sem uma mudança na regra do produto.

A Epsilon relata que um fluxo de 18 etapas levou de cinco a dez minutos para ser escrito com Nova Act, contra 30 a 90 minutos para o equivalente em Playwright. A AWS atribui esses números a medições internas da própria Epsilon. Eles são um estudo de caso, não uma garantia de que qualquer equipe ganhará de quatro a seis vezes em velocidade.

O que a Epsilon montou

O fluxo combina três partes: uma API que recebe o endereço da aplicação e os passos do teste; um trabalhador em segundo plano que abre o navegador; e o agente que navega pela tela, registra resultados e guarda evidências. No exemplo da Epsilon, o teste entra em uma conta, preenche campos, lida com uma tela de boas-vindas caso ela apareça e confirma que o novo agente foi salvo.

Diagrama oficial da arquitetura de testes de interface da Epsilon com Amazon Nova Act, navegador Chromium, autenticação, fila e armazenamento na AWS.

Diagrama publicado pela AWS para explicar a arquitetura da Epsilon; não representa uma implantação da Pump.

A diferença em relação a um roteiro tradicional está no modo de descrever o passo. Em vez de localizar um seletor como #saldo e codificar esperas, uma instrução pode dizer “confirme que o saldo de pontos está visível”. O agente interpreta a tela e tenta cumprir o objetivo. Isso pode reduzir retrabalho quando um ajuste visual troca seletores ou reorganiza elementos, além de tornar o roteiro mais fácil de revisar por produto e negócio.

Mas “escrito em linguagem natural” não significa “sem engenharia”. É preciso definir pré-condições, o que conta como sucesso, como reconhecer falhas e quais ações o teste pode executar. A documentação do Playwright sobre locators e verificações automáticas mostra por que testes determinísticos continuam valiosos: eles esperam que elementos estejam visíveis, estáveis e habilitados antes de agir. Para caminhos previsíveis e regras críticas, esse comportamento explícito ainda oferece controle e repetibilidade.

Onde a abordagem pode ajudar

O caso é mais interessante para jornadas visuais extensas: criar uma conta, atualizar um cadastro, solicitar um orçamento ou concluir um agendamento. São fluxos que o cliente percebe e nos quais uma falha de navegação pode bloquear a tarefa, ainda que as APIs estejam respondendo. Testes de API verificam contratos entre sistemas; testes de navegador veem a experiência que chega à pessoa.

Isso não transforma o agente em substituto de toda a estratégia de qualidade. Um teste baseado em intenção pode ser útil para explorar variações e cobrir cenários menos rígidos; regras de cálculo, permissões e comportamentos que precisam passar sempre do mesmo jeito devem continuar protegidos por verificações determinísticas. A própria Epsilon diz que manteve Playwright como base de regressão e adicionou os testes de intenção para ampliar a cobertura.

A AWS relata também uma taxa de 100% nas repetições de trajetórias salvas. Esse resultado depende do método descrito pela Epsilon: primeiro ajustar o fluxo em uma fase de exploração, depois salvar e repetir a trajetória aprovada. Não é uma medida independente de sucesso em qualquer interface. Antes de adotar, a equipe deve medir acertos e falsos positivos no próprio produto.

Para escolher um primeiro piloto, ajuda medir métricas que liguem o uso do produto a uma decisão. O time pode acompanhar quantas jornadas foram cobertas, quanto tempo leva para criar e manter cada teste, quantas falhas reais foram detectadas e quantos alertas exigiram revisão humana. O número de etapas automatizadas, sozinho, não diz se a experiência ficou melhor.

O que observar em segurança e operação

Na arquitetura apresentada, a AWS fornece sessões de navegador isoladas; a equipe ainda precisa cuidar da aplicação testada, das credenciais e dos dados. O guia do Amazon Bedrock AgentCore Browser descreve sessões remotas, visualização ao vivo, registros e permissões. A documentação de gravação e reprodução detalha que os registros podem incluir ações, mudanças no DOM, eventos de rede e mensagens do console, armazenados em um bucket S3 configurado pela equipe.

Essas evidências são úteis para depurar uma falha, mas também podem conter dados de formulário ou informações internas. Para um piloto, use ambiente de homologação, contas de teste e dados fictícios; limite as permissões do papel IAM e defina quem pode consultar os registros e por quanto tempo. Em fluxos de pagamento, exclusão de dados ou envio de mensagens, o teste deve parar antes da ação irreversível ou exigir uma etapa de confirmação supervisionada.

O relato técnico da AWS sobre o projeto da Epsilon descreve ainda uma implementação multi-equipe com papéis de acesso separados, gravação de sessões e evidência por etapa. Esse nível de plataforma faz sentido para uma organização com muitos produtos e centenas de testes. Uma empresa menor pode começar com poucos fluxos prioritários e uma execução manual supervisionada, sem construir logo de início uma infraestrutura multi-conta.

Como testar sem trocar tudo

  1. Escolha uma jornada de alto valor e baixo risco em homologação.
  2. Escreva cada etapa como uma intenção observável e inclua o resultado esperado, condições alternativas e o ponto em que o teste deve parar.
  3. Rode o fluxo ao lado da suíte existente. Compare tempo de criação, manutenção, estabilidade e falhas encontradas.
  4. Mantenha testes determinísticos para regras de negócio e ações críticas; use o agente onde a navegação visual ou a variação da interface torna a manutenção cara.
  5. Revise gravações e permissões antes de permitir acesso a dados reais.

Essa é uma decisão de custo e cobertura, não uma corrida para automatizar tudo com IA. Se a escolha for automatizar processos manuais, vale primeiro mapear frequência, exceções e risco — o mesmo roteiro de como decidir se uma tarefa da empresa deve ser automatizada. Para uma equipe que já testa interfaces, a experiência da Epsilon oferece uma hipótese concreta para experimentar: deixar a automação por intenção ampliar a cobertura, mantendo controles tradicionais onde previsibilidade importa mais.

#Software#Amazon Nova Act#AWS#Testes de software#Desenvolvimento web
Davi
Davi
Fundador da Pump e redator desde 2021. Apaixonado por tecnologia e cultura pop.
← Voltar ao blog