Testes agênticos — o papel dos agentes na stack de testes E2E

• A equipe de engenharia do Slack executou mais de 200 workflows agênticos para verificar se testes E2E (End-to-End) baseados em agentes poderiam substituir os testes determinísticos tradicionais
• Enquanto testes E2E tradicionais impõem caminhos fixos na UI, agentes verificam se um objetivo (goal) foi alcançado e podem chegar ao mesmo resultado por rotas diferentes
• Cada execução de agente leva mais de 10 minutos e custa US$ 15–30, mas há casos de uso claros do ponto de vista de confiabilidade
• A abordagem com Playwright MCP registrou menor taxa de falha e menor uso de tokens do que as abordagens via CLI e geração de código; a estabilidade do ambiente de execução foi decisiva para os resultados
• Testes agênticos não substituem os testes existentes; eles são adicionados ao topo da pirâmide de testes como uma camada de exploração, depuração e validação de comportamentos complexos

---

De jornadas para objetivos (From Journeys to Goals)

• Testes E2E tradicionais validam uma jornada (journey) específica seguindo a UI → clique → clique → entrada → asserção (assert)
• Testes baseados em agentes validam se um objetivo expresso por instruções como “enviar uma mensagem em thread” pode ser alcançado → objetivo → adaptação do agente → validação do resultado
  • Diferença central: “o teste impõe a jornada, e o agente valida o objetivo”
• O workflow completo (login → busca → resultado → reinicialização) permaneceu constante, mas a ordem real das ações mudava a cada execução
  • diferentes formas de entrada (clicar em sugestão de busca vs. pressionar Enter)
  • diferentes padrões de navegação (refazer a busca vs. reutilizar o estado existente)
  • etapas adicionadas ou omitidas (cliques extras, snapshots, ações intermediárias)
• Essa flexibilidade vem com trade-offs em confiabilidade, custo e tempo de execução

• Questão levantada

  • A pergunta central era se uma abordagem que custa US$ 15–30 por execução e leva mais de 10 minutos poderia entrar em um workflow moderno de testes
  • Após mais de 200 execuções, confirmou-se que a abordagem é fundamentalmente diferente dos testes tradicionais, mas ainda assim apresenta alta confiabilidade e casos de uso bem definidos
  • Avanços em grandes modelos de linguagem (LLMs), que permitem escrever código, depurar falhas e manipular diretamente a UI, viabilizaram esse novo modelo de execução

Configuração do experimento (Our Experiment)

• Para medir confiabilidade, velocidade de execução e custo, foram feitas mais de 200 execuções automatizadas em várias configurações

• Modelo de execução (três formas)

  • Agent + Playwright MCP: o agente interage com o navegador por meio de ações predefinidas (clicar em elementos, inserir texto, ler estado do DOM etc.), mantendo contexto persistente (snapshots do DOM e logs)
  • Agent + Playwright CLI: executa comandos do Playwright CLI no shell, processando uma etapa por vez e decidindo a próxima ação com base no estado atualizado da UI
  • Generated Playwright Tests: um agente de IA gera código determinístico em Playwright a partir de descrições em linguagem natural, executa como teste E2E padrão e melhora iterativamente até passar

• Ambiente experimental

  • Modelos de agente MCP e CLI: Claude Sonnet 4.5
  • Modelo para testes Playwright gerados: Claude Opus 4.6
  • Execução: Claude Code não interativo (claude -p)
  • Ferramentas de navegador: Playwright MCP, Playwright CLI
  • Ambiente: Slack Dev API MCP; todos os experimentos foram realizados em um workspace de testes com dados não produtivos

• Fluxos de teste (dois níveis de complexidade)

  • Thread Reply (simples): workflow de cerca de 15–20 etapas envolvendo criação de canal, envio de mensagem, resposta em thread e validação do estado da thread
  • Search Discovery (complexidade média): workflow de cerca de 25–30 etapas envolvendo entrada do termo de busca, exploração de resultados, navegação entre views (busca, canal, thread) e validação do resultado esperado

• Formato de entrada

  • Linguagem natural (NL): instruções legíveis por humanos descrevendo o workflow e o resultado esperado em uma lista passo a passo
  • YAML estruturado: o mesmo workflow em um formato estruturado, explicitando etapas, ações, alvo e resultado esperado
    • A diferença não estava no nível de detalhe, mas na forma de representação — em linguagem natural o agente precisa interpretar e mapear; em YAML esse mapeamento fica mais explícito

• Matriz experimental

  • Cada configuração foi executada 20 vezes, totalizando 5 experimentos (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, geração de testes-NL) aplicados aos dois fluxos: Thread Reply e Search Discovery

O que foi observado (What We Observed)

• Resumo dos resultados

  • Agente (Playwright MCP): taxa de falha de 0% (thread reply) / cerca de 12% (search discovery), média de 5–8 minutos
  • Agente (Playwright CLI): taxa de falha de cerca de 12% / cerca de 20%, média de 9–11 minutos
  • Testes Playwright gerados: taxa de falha de cerca de 8% / cerca de 48%, média de 3 minutos

• Confiabilidade (Reliability)

  • Conforme o fluxo ficava mais complexo, a diferença de confiabilidade se tornava mais evidente
  • Playwright MCP foi o mais estável — taxa de falha praticamente 0% em cenários simples e entre 0–12% em fluxos complexos
  • Playwright CLI teve taxa de falha maior (cerca de 12–20%), principalmente por problemas de execução como autenticação, timing de navegação e instabilidade de sessão, não por falhas de raciocínio do modelo
  • Testes gerados tiveram bom desempenho em fluxos simples (cerca de 8%), mas pioraram bastante em workflows complexos (cerca de 48%)
    • Não estavam totalmente errados; normalmente avançavam 70–80% do fluxo antes de falhar na interação final ou na asserção
    • As falhas vieram de variabilidade do estado da UI e desalinhamento de abstrações — foram gerados a partir de fluxos em linguagem natural pouco rígidos e reutilizaram abstrações existentes de page objects, atrapalhando o direcionamento preciso de elementos
  • À medida que a complexidade aumentava, a diferença de confiabilidade crescia, e modelos de execução nativos para agentes, como o MCP, se mostravam mais estáveis
    • O MCP mantém uma visão estável e em tempo real do app, enquanto o CLI reconstrói o estado a partir de snapshots a cada etapa → quanto mais longo o fluxo, maior o acúmulo de inconsistências
    • O MCP parece reutilizar interações bem-sucedidas de etapas anteriores dentro da sessão, enquanto o CLI dá a sensação de recomeçar do zero a cada passo (isso não foi medido explicitamente)

• Velocidade (Speed)

  • Testes gerados foram consistentemente os mais rápidos (cerca de 3 minutos), seguidos pelo MCP com cerca de 5–8 minutos e pelo CLI com cerca de 9–11 minutos
  • O número dos testes gerados inclui criação + execução; cada teste foi gerado uma vez e depois executado 5 vezes para obter a média
    • A execução pura é muito mais rápida — thread reply em cerca de 32 segundos, search discovery em cerca de 45 segundos
    • Em ambientes de CI com execuções repetidas, o custo único de geração se torna desprezível, permitindo que testes determinísticos escalem com eficiência
  • Workflows agênticos têm custo em toda execução — cada etapa envolve observar o estado da UI, inferir a próxima ação, executá-la e validar o resultado

• Adaptabilidade (Adaptability)

  • Apenas cerca de 20% das execuções seguiram exatamente a mesma sequência de ações; a maioria encontrou caminhos válidos diferentes na UI para chegar ao mesmo objetivo
    • abrir menus em ordens diferentes
    • selecionar elementos de UI levemente diferentes
    • usar fluxos alternativos de navegação
  • Para medir isso, foi comparada entre execuções a assinatura de ações (action signature) — a lista ordenada de chamadas de ferramentas e ações de UI realizadas pelo agente
    • Antes da comparação, houve normalização: parâmetros, ações de espera/snapshot e variantes equivalentes de ferramentas (fill vs type) foram consolidados para calcular apenas diferenças significativas
  • Mesmo quando o resultado final era correto, a ordem das ações geralmente era diferente — E2E tradicional impõe uma única jornada determinística; agentes exploram a interface e verificam se o estado objetivo foi alcançado

• Custo e sua origem (Cost and Where It Comes From)

  • Execuções com agentes normalmente custam US$ 15–30 por execução, muito mais do que testes tradicionais
  • Análise do uso de tokens no mesmo fluxo search discovery
    • MCP (Opus 4.6) cerca de 3.8M, MCP (Sonnet 4.5) cerca de 3.5M, MCP (Haiku 4.5) cerca de 5.7M
    • CLI (Opus 4.6) cerca de 6M, Code Gen (Opus 4.6) cerca de 7M
  • Como se executa importa mais do que qual modelo é usado — o Haiku consumiu mais tokens, mas todas as abordagens MCP usaram menos tokens do que CLI e Code Gen
  • A análise da forma de execução de sessão do Claude Code mostrou que a API subjacente é stateless, então o prompt de sistema completo e todo o histórico da conversa são reenviados a cada turno
    • O custo não é determinado pela saída do modelo, e sim pela velocidade de acúmulo de contexto e pelo número de turnos
  • Número de turnos: MCP (Opus/Sonnet) cerca de 40, MCP (Haiku) cerca de 60, CLI (Opus) cerca de 85, Code Gen (Opus) cerca de 70
    • No CLI, cada interação com o navegador é quebrada em vários comandos como ação, espera, snapshot, leitura e consulta de elemento, resultando em média em 85 turnos
    • O MCP combina interação e retorno de estado em uma única ida e volta
    • Cada turno adicional traz o custo do prompt de sistema completo e do reenvio do contexto anterior da conversa
  • O que preenche o contexto
    • MCP e CLI: snapshots do navegador são a principal carga útil — snapshots da árvore de acessibilidade (accessibility tree) retornados pelo Playwright MCP se acumulam em todos os turnos seguintes
    • Code Gen: a cada nova tentativa se acumulam saída do runner de testes com trace completo de erro, falhas de asserção e estado do DOM
  • A maior parte do custo vem de reenviar conteúdo já visto; a quantidade de informação nova por turno é mínima
  • O uso de tokens ainda não foi otimizado — foram sugeridas reduções com prompt caching, compaction de contexto e menor frequência de snapshots
  • Por causa do custo, no momento isso é mais adequado para depuração direcionada e testes exploratórios do que para execuções frequentes em CI, embora modelos e ferramentas futuros possam melhorar isso

• Importância da infraestrutura (MCP vs CLI)

  • Não é só o modelo em si: o ambiente de execução teve grande impacto na confiabilidade — MCP com 0–12% de falha, CLI com 12–20%
  • A maioria das falhas do CLI veio de problemas de autenticação e navegação (erro de login, timeout, instabilidade de sessão), ou seja, problemas da camada de execução, não do raciocínio do agente
  • O Playwright MCP oferece primitives estruturadas de navegador e integração mais estreita com o workflow de chamadas de ferramentas do agente; o CLI introduz uma camada extra entre agente e navegador
  • Diferença de paralelização: o MCP facilita execução concorrente, enquanto o CLI dificulta paralelização e acaba sendo majoritariamente sequencial
  • Confiabilidade, velocidade e custo dependem não apenas do modelo, mas também da estabilidade e do design do ambiente de execução

• Limites da capacidade de execução (Execution Capability Boundaries)

  • Este experimento se concentrou em workflows de UI em uma única sessão
  • Fluxos entre workspaces ou workflows que abrem várias janelas de navegador trazem outros desafios, em que a escolha do modelo de execução passa a ser tão importante quanto o próprio agente
    • O MCP pode enfrentar problemas de custo com loops de observação mais longos
    • O CLI pode sofrer com complexidade de coordenação e alto consumo de tokens ao gerenciar várias sessões de navegador
  • Ambas as abordagens podem oferecer suporte, mas com trade-offs diferentes — isso não foi explorado aqui, embora seja um ponto importante para equipes de avaliação

Onde os testes agênticos se encaixam na pirâmide de testes

• Testes agênticos não substituem as abordagens existentes; eles adicionam uma nova capacidade acima delas

• Testes E2E determinísticos

  • São os mais adequados para verificações rápidas e repetíveis de regressão em CI
    • escritos por pessoas ou gerados por IA
    • rápidos e repetíveis, compatíveis com CI
    • baixo custo operacional
    • impõem jornadas específicas de UI

• Testes agênticos

  • Em vez de executar um script fixo, partem de um objetivo — observam a UI, inferem o estado atual e decidem como chegar ao resultado desejado
    • explorar comportamentos complexos da UI
    • depurar workflows instáveis (flaky)
    • reproduzir bugs de produção

• Pirâmide de testes com camada agêntica

  • Do ponto de vista do sistema, testes agênticos validam workflows reais de usuário via UI no mesmo nível de E2E; a diferença está em como o workflow é executado
  • A estratégia de testes mais eficaz no futuro deve combinar ambos — testes determinísticos fornecem a base estável do CI, enquanto testes agênticos assumem, no topo da pirâmide, a exploração, a depuração e a validação de comportamentos complexos