Sua equipe de QA móvel ainda está escrevendo XPath. Em 2026.

Sou o criador do Drengr, um servidor MCP que dá aos agentes de IA olhos e mãos em dispositivos móveis. Comecei este blog para compartilhar a engenharia por trás disso. Sem fingir ser um observador neutro escrevendo um artigo de opinião — eu construí isso, e estou aqui para falar sobre isso.

O teste que quebra a cada sprint

Você conhece o procedimento. Seu engenheiro de QA escreve uma bela suíte de testes. Login, navegar pelo catálogo, adicionar ao carrinho, finalizar compra. Cinquenta seletores, esperas cuidadosas, lógica de repetição para chamadas de rede instáveis. Passa na segunda-feira.

Na terça, a equipe de design move o botão de checkout. Três seletores quebram. O teste falha. O engenheiro de QA passa meio dia atualizando localizadores. O teste passa novamente.

Na quarta, um novo recurso adiciona uma folha inferior que sobrepõe o ícone do carrinho. O toque cai na folha em vez do carrinho. O teste falha. Mais meio dia.

Esse ciclo se repete a cada sprint, em toda equipe móvel, em todo lugar. A suíte de testes não testa mais o aplicativo — ela testa se os seletores ainda correspondem à interface do usuário.

A causa raiz: seletores nunca foram a abstração correta

XPath, IDs de recurso, identificadores de acessibilidade — todos são endereços. "Toque no elemento neste caminho na hierarquia de visualização." No momento em que a hierarquia muda, o endereço está errado.

Os humanos não navegam em aplicativos por endereço. Eles olham para a tela, veem "Checkout" e tocam nele. Eles não se importam que o botão se moveu de //android.widget.Button[@resource-id='checkout_btn'] para //android.widget.FrameLayout/android.widget.Button[2]. Eles apenas veem o botão e tocam nele.

Agentes de IA podem fazer a mesma coisa — se você lhes der a tela, não uma árvore de seletores.

Como é "dar a eles a tela"

Quando um agente de IA se conecta ao Drengr, ele pergunta: "O que está na tela?" O Drengr responde com uma descrição de texto compacta:

[1] "Checkout" (Botão)
[2] "Seu Carrinho: 3 itens" (TextView)
[3] "Remover" (Botão)
[4] "Continuar Comprando" (Botão)

Ou uma imagem anotada com elementos numerados. A IA lê isso, decide "tocar no elemento 1" e chama drengr_do. Após a ação, ela recebe um relatório de situação informando o que mudou.

Sem seletores. Sem XPath. Sem IDs de elementos para manter. A IA vê a tela da maneira que um humano vê — pelo que é visível, não por onde vive na árvore de visualização.

"Mas e quanto à confiabilidade?"

Boa pergunta. Se a IA está interpretando a tela toda vez, isso não introduz não-determinismo?

Sim. E esse é o ponto. Um teste determinístico que quebra quando a interface do usuário muda não é confiável — é rígido. Um agente de IA que se adapta às mudanças da interface do usuário é mais confiável na prática porque lida com as variações que quebram testes baseados em seletores.

O Drengr adiciona barreiras:

• Detecção de travamento — se a tela não mudar após uma ação, o agente sabe que deve tentar algo diferente
• Detecção de falhas — se o aplicativo falhar, o agente sabe imediatamente e pode reiniciar
• Relatórios de situação — após cada ação, o agente recebe uma diferença estruturada do que mudou, para que permaneça orientado

A IA não apenas toca cegamente. Ela observa, age e se adapta. Isso é mais robusto do que um script fixo que funciona exatamente de uma maneira.

O argumento de custo

"Chamadas de IA são caras." Claro, se você estiver enviando capturas de tela para o GPT-4o a cada passo.

O modo apenas texto do Drengr comprime uma tela para ~300 tokens. Um fluxo de teste de 15 etapas custa cerca de $0,05 com a precificação do GPT-4o. O mesmo fluxo com capturas de tela custa $0,45.

Mas aqui está a verdadeira comparação de custos: quanto sua equipe de QA gasta mantendo seletores? Se um engenheiro passa 2 horas por semana atualizando testes quebrados, isso é $5.000/mês em salário indo para a manutenção de XPath. Os custos da API de IA são erros de arredondamento perto disso.

Uma suíte de testes que sobrevive a redesigns

app: com.example.shop
tasks:
  - name: navegar
    task: "Pesquisar por fones de ouvido sem fio e abrir o primeiro resultado"
    timeout: 60s
  - name: comprar
    task: "Adicionar ao carrinho e finalizar a compra com o cartão de teste"
    timeout: 90s
  - name: verificar
    task: "Ir para histórico de pedidos e verificar se o pedido aparece"
    timeout: 45s

Este YAML sobreviveu a 3 redesigns do nosso aplicativo de teste. O fluxo de checkout mudou de uma página separada para uma folha inferior e depois para um modal de tela cheia. O YAML não mudou. A IA se adaptou a cada vez porque lê a tela, não os seletores.

drengr test tests.yml executa isso. A saída JUnit XML se conecta a qualquer pipeline CI. Sem servidor Appium para manter, sem grade Selenium, sem planilha de localizadores de elementos.

Isso não é teórico

O Drengr roda em verdadeiros telefones Android, simuladores iOS e fazendas de dispositivos em nuvem (BrowserStack, SauceLabs, AWS Device Farm, LambdaTest, Perfecto, Kobiton). Ele se conecta a qualquer cliente de IA compatível com MCP — Claude Desktop, Cursor, Windsurf, VS Code.

Um binário. Uma instalação:

npm install -g drengr

Sua equipe de QA pode parar de escrever XPath. A IA pode ler a tela.