O Que Acontece Quando Você Deixa a IA Testar Seu Aplicativo por Uma Semana

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 reflexivo — eu construí isso, e estou aqui para falar sobre.

O teste móvel com IA é ou o futuro da QA ou uma maneira cara de gerar relatórios de bugs falsos, dependendo de quem você perguntar. Decidi descobrir por conta própria. Apontei o agente OODA-loop do Drengr para três aplicativos diferentes — uma calculadora, um aplicativo de clima e um cliente de mídia social — e deixei-o rodar autonomamente por uma semana. Aqui está o que aconteceu, incluindo as partes que não funcionaram.

Este não foi um experimento controlado em nenhum sentido científico. O tamanho da amostra é pequeno, os aplicativos são específicos e os resultados podem não ser generalizáveis. Estou compartilhando isso como um ponto de dados, não como uma prova. O teste móvel autônomo é realmente um território novo e acho que relatórios honestos importam mais do que afirmações impressionantes.

A Configuração

Cada aplicativo recebeu o mesmo tratamento:

• 10 execuções autônomas de exploração por dia, cada uma com um prompt de objetivo de alto nível diferente
• Cada execução limitada a 50 ações para limitar os custos de token
• Os objetivos variavam de específicos ("calcular 15% de gorjeta sobre $47,50") a abertos ("explorar o aplicativo e relatar qualquer coisa que pareça quebrada")
• Claude Sonnet 4 como o modelo de tomada de decisão, escolhido pelo equilíbrio entre capacidade e custo
• Emulador Android, imagem Pixel 7, API 34

Total ao longo da semana: 210 execuções nos três aplicativos, aproximadamente 2,1 milhões de tokens consumidos, cerca de $14 em custos de API.

Os Prompts

Aprendi rapidamente que o design do prompt importa enormemente. "Teste a calculadora" produziu toques sem rumo. "Verifique se a calculadora lida com casos extremos em operações aritméticas, incluindo números negativos, precisão decimal, divisão por zero e números muito grandes" produziu uma exploração útil e direcionada.

O ponto ideal era específico o suficiente para guiar o agente, mas aberto o suficiente para deixá-lo descobrir coisas que eu não havia antecipado.

O Que Ele Encontrou

App 1: Calculadora — O Bug do Número Negativo

O aplicativo de calculadora era um projeto pessoal, algo que eu construí e considerei "pronto" por meses. O agente encontrou um bug no segundo dia que eu nunca havia notado: inserir um número negativo, depois pressionar o botão de porcentagem, e então pressionar igual produziu NaN em vez de um resultado numérico.

Eu nunca testei essa sequência manualmente. Por que eu faria isso? Porcentagem negativa de um número não é uma operação comum. Mas o agente, explorando combinações que eu não pensaria em tentar, esbarrou nisso. O problema subjacente era uma verificação de valor absoluto ausente no caminho de cálculo de porcentagem.

Isso por si só tornou o experimento válido para mim. É um bug trivial, mas já havia sido lançado. Um usuário real poderia ter encontrado isso.

App 2: Aplicativo de Clima — O Link Profundo Quebrado

O aplicativo de clima suportava links profundos para compartilhar URLs de previsões. O agente, quando recebeu o objetivo "navegar até a página de configurações usando todos os caminhos disponíveis", descobriu que o link profundo weather://settings/notifications fazia o aplicativo travar. O travamento foi capturado pela monitorização logcat do Drengr antes que o agente precisasse até mesmo relatar — o mecanismo de situação sinalizou uma exceção fatal.

A causa raiz era uma verificação nula ausente em um argumento de fragmento. O manipulador de link profundo assumiu que um parâmetro de bundle estaria sempre presente, mas o fragmento de configurações de notificações esperava que fosse passado pela atividade pai, não por um link profundo.

App 3: Cliente de Mídia Social — O Problema de Acessibilidade

Esta foi a descoberta mais interessante. O cliente de mídia social tinha vários botões de ícone — curtir, compartilhar, marcar — que não tinham descrições de conteúdo. O agente os relatou como "elementos interativos sem rótulo" porque a hierarquia da UI mostrava visualizações clicáveis sem texto e sem rótulos de acessibilidade.

O agente não estava fazendo testes de acessibilidade de propósito. Ele estava tentando descrever o que via, e não conseguiu identificar aqueles botões. O mesmo problema que confundiu a IA confundiria um leitor de tela. UI inacessível é UI ambígua, e a ambiguidade prejudica tanto agentes automatizados quanto usuários humanos que dependem de tecnologia assistiva.

O Que Ele Não Pegou

Igualmente importante é o que o agente não pegou.

Uma condição de corrida sensível ao tempo. O aplicativo de clima tinha um bug onde alternar rapidamente entre cidades enquanto as previsões estavam carregando poderia exibir os dados da cidade errada. Isso exigia um tempo específico — alternar durante a janela de 200-400ms entre a resposta da API chegando e a atualização da UI. O ciclo de ação do agente era muito lento (3-5 segundos entre ações) para nunca acionar essa janela.

Problemas de alinhamento visual. O cliente de mídia social tinha um bug de layout onde nomes de usuário longos causavam sobreposição de texto com o timestamp em certas larguras de tela. A hierarquia da UI relatou limites de elementos corretos — a sobreposição era um problema de renderização, não um problema de layout. Os elementos estavam "corretamente posicionados" de acordo com o mecanismo de layout, mas visualmente sobrepostos. O agente, que depende mais da árvore da UI do que da análise em nível de pixel, não percebeu.

Problemas sutis de UX. O recurso de histórico da calculadora era confuso — mostrava resultados em ordem cronológica reversa sem timestamps claros, e entradas antigas pareciam idênticas às novas. Um testador humano marcaria isso como um problema de usabilidade. O agente, que não tem conceito de "confuso", viu uma lista funcional e seguiu em frente.

Falsos Positivos

O agente relatou 23 "problemas" ao longo da semana. Após revisão manual, 14 eram descobertas genuínas e 9 eram falsos positivos. Isso resulta em uma taxa de falso positivo de 39% — alta o suficiente para exigir revisão humana de cada relatório.

O falso positivo mais comum: interpretar carregamentos lentos como travamentos. O agente tocava um botão, esperava a tela mudar, e se nada acontecesse dentro de sua janela de paciência (cerca de 8 segundos), relatava uma falha. Vários desses foram apenas respostas lentas da rede no emulador.

O segundo mais comum: interpretar estados intencionais da UI como erros. Uma folha inferior descartada foi relatada como "conteúdo desapareceu inesperadamente." Uma página de resultados de busca vazia foi relatada como "aplicativo falhou ao carregar conteúdo." Essas são observações corretas — o conteúdo realmente desapareceu, a página está vazia — mas a interpretação do agente estava errada.

Análise de Custos

Ao longo de 210 execuções:

• Total de tokens: ~2,1 milhões (entrada + saída)
• Custo total da API: ~$14
• Média por execução: ~10.000 tokens, ~$0,07
• Duração média da execução: 3-4 minutos
• Tempo de revisão humana: ~5 horas no total para avaliar todos os relatórios

Para comparação, o teste manual de QA desses três aplicativos em uma profundidade semelhante teria levado cerca de 15-20 horas. O teste com IA levou cerca de 5 horas do meu tempo (configuração, design de prompt e revisão de relatórios) mais $14 em custos de API.

Isso representa um ganho de eficiência significativo, mas não é esforço zero. O humano ainda está no loop, revisando relatórios e separando sinal do ruído.

Minha Opinião Honesta

O teste de QA com IA não é um substituto para o QA humano. Ele encontra diferentes tipos de bugs através de diferentes tipos de exploração. Um testador humano aplica conhecimento de domínio, julgamento estético e intuição sobre o que "parece errado". Um agente de IA aplica exploração combinatória exaustiva, paciência para repetitividade.