Epsilon automatiza testes de interface com Nova Act em navegadores gerenciados pela AWS
Imagen generada con gpt-image-2.5-sunburst para InferamaFonte ↗
Ilustración editorial para Epsilon automatiza pruebas de interfaz con Nova Act en navegadores gestionados por AWS
Ilustración editorial para Epsilon automatiza pruebas de interfaz con Nova Act en navegadores gestionados por AWSImagen generada con gpt-image-2.5-sunburst para Inferama · Original de Inferama · generada con IAFonte ↗
01

O que muda nos testes de interface da Epsilon

A AWS apresenta a Agentic Platform da Epsilon como um serviço gerenciado de testes de interface do usuário. As equipes descrevem os testes em linguagem natural, e eles são executados em navegadores gerenciados pela AWS. A proposta busca reduzir a infraestrutura que cada equipe teria de preparar e manter separadamente, além de permitir que os testes expressem a intenção do fluxo que se deseja verificar.

A mudança prática não é o desaparecimento da necessidade de projetar testes, mas a transferência de parte da execução para um sistema que interpreta instruções e opera um navegador. Na abordagem descrita, o Nova Act participa da automação das ações na interface, enquanto o Bedrock AgentCore Browser Tool fornece o ambiente de navegador. A publicação da AWS descreve essa combinação, mas não apresenta um relatório independente que permita medir seu desempenho em produção.

A expressão “baseados em intenção” refere-se a descrever o resultado que se pretende verificar, em vez de restringir o teste a uma sequência fixa de etapas técnicas. Isso pode ser útil quando o percurso de um aplicativo muda com frequência, embora uma instrução mais flexível não garanta que o agente interprete corretamente cada variação ou detecte todas as falhas relevantes.

As informações disponíveis permitem identificar a abordagem técnica e operacional geral: serviço gerenciado, equipes de produto como usuárias e navegadores administrados pela AWS. Não permitem concluir quantas equipes o utilizam, quais tipos de aplicativos são cobertos pela implementação concreta ou que proporção dos testes é executada sem intervenção.

02

Como Nova Act e o navegador gerenciado se complementam

Um teste de navegador costuma combinar uma intenção — por exemplo, verificar se é possível concluir uma operação — com ações concretas: abrir uma página, selecionar controles, inserir dados e conferir o resultado. No sistema descrito pela AWS, as instruções são escritas em linguagem comum e o Nova Act é usado para automatizar interações com a interface. O AgentCore Browser Tool fornece o navegador gerenciado no qual essas interações são executadas.

Essa divisão ajuda a entender a função de cada componente sem atribuir capacidades além das descritas. O Nova Act é a peça de automação baseada em modelos; o navegador gerenciado é o ambiente em que o aplicativo é observado e operado. As informações disponíveis não detalham como cada instrução é convertida em etapas, quais mecanismos determinísticos validam o resultado nem como os erros são tratados quando a interface não corresponde ao esperado.

A automação baseada em modelos pode interpretar uma instrução e decidir quais ações são prováveis, mas isso não equivale a garantir que o fluxo será concluído corretamente. Controles explícitos — como validar um texto esperado, um estado ou uma resposta estruturada — são diferentes da decisão probabilística sobre onde clicar ou o que fazer em seguida. Para avaliar um teste, é importante conhecer tanto a interpretação da instrução quanto os critérios finais de aprovação.

Também não se deve confundir o fato de um navegador ser gerenciado pela AWS com a documentação de todos os aspectos de segurança ou isolamento das sessões. A descrição afirma que o navegador é administrado pela AWS, mas as evidências disponíveis não especificam como sessões, credenciais, dados temporários ou registros são separados entre as equipes clientes.

Componentes e perguntas que cada um responde

A divisão a seguir resume a função atribuída a cada componente e separa o que foi descrito do que ainda não foi especificado.

ElementoFunção descritaLimite das informações disponíveis
Instrução em linguagem naturalExpressa o fluxo ou resultado que a equipe deseja testar.Não foi publicado um formato completo nem um método para resolver instruções ambíguas.
Amazon Nova ActAutomatiza a interação com a interface do navegador.Não há métricas específicas da Epsilon sobre acertos, erros ou cobertura.
Bedrock AgentCore Browser ToolFornece o navegador gerenciado no qual os testes são executados.As evidências consultadas não detalham garantias de isolamento entre clientes.
Equipe de produtoDefine o comportamento que deseja verificar e avalia os resultados.Não é explicado quais etapas exigem aprovação ou intervenção humana.
03

O que o exemplo de automação de QA oferece

Um repositório de exemplo da AWS mostra outra forma de organizar testes de qualidade com o SDK do Nova Act e o pytest. O projeto combina testes de navegador, execução paralela e geração de relatórios HTML que podem incluir resultados, duração, falhas, capturas de tela e registros. Também ilustra asserções para verificar valores booleanos, texto ou estruturas de dados.

O exemplo é útil como referência de engenharia: mostra como integrar um agente a ferramentas conhecidas de teste e organizar relatórios. Não é uma avaliação da plataforma da Epsilon e não demonstra que qualquer teste escrito em linguagem natural será estável ou válido em outro ambiente. Uma amostra de código evidencia a existência de uma implementação de referência; por si só, não comprova uma taxa de sucesso nem um comportamento em produção.

O repositório informa os requisitos do ambiente, configura o pytest-xdist para executar testes em paralelo e permite agrupar aqueles que precisam ser executados sequencialmente. Essa configuração responde a uma necessidade comum: alguns testes são independentes, enquanto outros compartilham dados ou dependem do resultado de um teste anterior. Executá-los em paralelo pode economizar tempo em determinadas cargas, mas não elimina as dependências nem garante resultados reproduzíveis.

O projeto também prevê o armazenamento de registros e dados do navegador por teste, além da geração de um relatório de execução. Para uma equipe que avalia uma solução desse tipo, esses artefatos podem facilitar a análise de falhas. Ainda assim, ter registros ou capturas de tela não demonstra que o sistema detecta todos os erros e tampouco define, por si só, por quanto tempo os dados devem ser mantidos ou quem pode acessá-los.

04

O que significa ser um serviço multiusuário gerenciado

A AWS descreve a plataforma da Epsilon como um serviço gerenciado e multiusuário, com execução em navegadores administrados. Em termos operacionais, isso sugere que as equipes de produto podem usar uma infraestrutura comum em vez de manter cada uma seu próprio ambiente de navegador. A publicação caracteriza o objetivo como evitar infraestrutura por equipe; não apresenta um detalhamento de custos, recursos humanos necessários ou economia medida.

O rótulo multiusuário não basta para determinar quais recursos são compartilhados ou como são separados. Pode haver componentes comuns e, ao mesmo tempo, controles de isolamento por sessão ou cliente, mas as informações consultadas não especificam esse projeto. Não é possível deduzir da descrição quais proteções se aplicam a cookies, credenciais, perfis do navegador, capturas de tela, registros ou dados extraídos durante um teste.

Para uma organização que avalia um serviço assim, essas diferenças são importantes porque os testes podem acessar contas, dados de teste ou ambientes com informações sensíveis. As informações públicas disponíveis aqui não confirmam políticas de retenção, controles de acesso, localização dos dados ou mecanismos de separação entre clientes. Essa falta de detalhes não demonstra que tais controles não existam; significa que eles não estão estabelecidos pelas evidências consultadas.

A gestão centralizada também pode reduzir tarefas locais de instalação e manutenção, mas transfere parte das questões operacionais para o fornecedor e para a configuração do serviço. É importante distinguir a conveniência de não administrar navegadores próprios das evidências sobre segurança, continuidade, isolamento e recuperação diante de falhas.

Avaliação prática antes de integrar uma plataforma de testes

Estas etapas ajudam uma equipe a avaliar se a solução se adapta ao aplicativo e às obrigações operacionais.

  1. 01Defina um conjunto pequeno de fluxos críticos e o resultado observável que cada teste deve aprovar.
  2. 02Teste os mesmos fluxos em condições normais e diante de mudanças na interface, dados ausentes e respostas lentas.
  3. 03Analise quais evidências de execução são geradas: resultados, registros, capturas de tela e erros; limite o acesso de acordo com o risco dos dados.
  4. 04Esclareça com o fornecedor o alcance do isolamento, o tratamento de credenciais, a retenção de artefatos e a participação humana.
  5. 05Compare execuções repetidas com uma referência determinística, quando houver, e registre separadamente falhas de interpretação e falhas do aplicativo.
05

Confiabilidade, supervisão e limites das evidências

As evidências disponíveis descrevem a abordagem da Epsilon, mas não oferecem métricas reproduzíveis e específicas dessa implementação sobre precisão, cobertura, falhas intermitentes ou economia de tempo. Também não explicam quais tarefas são executadas autonomamente, quais resultados exigem aprovação humana ou qual mecanismo é acionado se o agente interpretar uma instrução de forma incorreta.

A Amazon anunciou números gerais de confiabilidade do Nova Act em fluxos de trabalho de primeiros clientes. Esse dado corporativo tem um alcance diferente: não é uma medição independente da plataforma da Epsilon e não permite atribuir a ela a mesma taxa de sucesso. Além disso, um número agregado depende das tarefas, dos ambientes e do critério de confiabilidade utilizados; sem esses detalhes, não serve como garantia para um aplicativo específico.

A automação de interface enfrenta mudanças no design, elementos que aparecem de forma variável, tempos de carregamento e resultados inesperados. Um sistema pode executar um fluxo corretamente e falhar em outro semelhante; por isso, os testes devem ser avaliados com cenários representativos, critérios de aceitação observáveis e análise dos casos que falharam. O fato de uma instrução estar escrita em linguagem natural não torna o teste intrinsecamente robusto.

A conclusão razoável é limitada: a AWS descreve uma arquitetura que combina instruções em linguagem natural, Nova Act e navegadores gerenciados para que a Epsilon ofereça testes de interface como serviço. O exemplo de QA fornece uma referência prática de SDK, pytest e relatórios. As evidências consultadas não permitem afirmar uma confiabilidade específica da Epsilon, uma cobertura determinada, ausência de intervenção humana ou isolamento multiusuário com características específicas.

Questões em aberto

  • Não são publicadas métricas reproduzíveis específicas da Epsilon sobre precisão, cobertura, estabilidade ou economia de tempo.
  • As informações consultadas não determinam quais tarefas exigem aprovação humana nem como um erro de interpretação é tratado.
  • Não é especificado como sessões, credenciais e artefatos do navegador são isolados entre equipes clientes.
06

Continue a explorar

06

Fontes consultadas

03

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.

Propor uma correção