Agente de QA com IA: 4 testes no site em 30 min

Um repositório de agente de navegador já passa de 106 mil estrelas no GitHub. Eu não olho para isso como troféu de nerd. Eu olho como sinal de compra: a IA está chegando na parte chata do negócio, inclusive testar site.

Neste artigo eu mostro como eu usaria QA com IA sem fingir que o robô virou gerente de qualidade. A promessa é simples: escolher uma página crítica, rodar 4 testes em 30 minutos e sair com uma lista de bugs que alguém consegue conferir.

TL;DR

• QA com IA usa um agente no navegador para abrir páginas, clicar, preencher campos e apontar erro visual ou de uso.
• Eu começaria com o método SITE: Sistema, Instrução, Trava e Evidência.
• O ganho não é substituir o QA. É achar bug bobo antes do cliente achar. Cliente é ótimo detector de bug, mas cobra caro em silêncio.

O problema: seu site quebra antes do robô avisar

Semana passada eu revisei um fluxo simples: página de contato, formulário, WhatsApp e confirmação. Nada de foguete.

Mesmo assim, era o tipo de fluxo que costuma quebrar depois de uma mudança pequena. Um botão some no mobile. Um campo obrigatório fica sem mensagem. O link do WhatsApp abre com texto errado. A página parece viva no desktop e morta no celular.

QA manual resolve. Só que ninguém faz todo dia porque é repetitivo, chato e fácil de empurrar para amanhã. Amanhã, como sempre, vira reunião.

Foi por isso que o sinal do Browser Use me chamou atenção. O README do projeto diz que um agente consegue usar o navegador como uma pessoa: abrir páginas, clicar, digitar e preencher formulários. Ele também cita QA de site local como caso de uso.

Isso é útil para founder. Não porque a IA ficou mágica. Porque ela ficou insistente. Robô não reclama de clicar no mesmo botão 40 vezes. Eu reclamo no terceiro.

O método SITE para QA com IA

Eu uso o método SITE para testar se um agente de QA vale piloto.

SITE significa: Sistema, Instrução, Trava e Evidência. Quatro palavras. Se precisar de 42 slides, já começou errado.

1. Sistema: escolha uma página que custa dinheiro

Não comece pela página mais bonita. Comece pela página que afeta lead, venda ou suporte.

Eu escolheria uma destas:

• página de contato;
• formulário de orçamento;
• área de login;
• checkout;
• página de agendamento.

A pergunta é: se essa página quebrar, alguém perde dinheiro ou tempo hoje?

Se a resposta for não, deixa para depois. Founder ocupado não precisa de robô auditando rodapé institucional às 9 da manhã.

2. Instrução: escreva a tarefa como se fosse para um estagiário bom

Agente de QA não adivinha prioridade. Eu preciso dizer o que ele deve fazer.

Um prompt simples funciona melhor:

Abra a página [URL]. Teste o fluxo como um visitante novo.
Verifique se o título aparece, se os botões principais funcionam,
se o formulário aceita dados válidos e se há erro claro quando falta campo obrigatório.
Liste bugs, prints necessários e passos para reproduzir.
Não envie formulário real nem compre nada.

Perceba a última frase. Ela é a parte que salva cartão de crédito, CRM e paciência.

3. Trava: proíba ações caras antes do teste

Eu nunca deixaria um agente testar site com acesso livre logo no primeiro dia.

Antes, eu colocaria 5 limites:

• não enviar formulário em produção;
• não apagar registro;
• não comprar;
• não alterar cadastro real;
• não acessar dados sensíveis.

Se o teste precisa enviar algo, use ambiente de staging ou formulário com e-mail de teste. Parece óbvio. Também parecia óbvio não colar senha no grupo da firma, e cá estamos.

4. Evidência: peça prova, não opinião

O pior relatório de QA é aquele que diz "o fluxo parece bom".

Eu quero evidência:

• URL testada;
• navegador e tamanho de tela;
• passos executados;
• resultado esperado;
• resultado encontrado;
• print ou trecho de erro;
• prioridade do bug.

Sem isso, o agente só gerou fofoca técnica. Bonita, educada e inútil.

Como aplicar hoje

Você consegue testar uma página em 30 minutos com este roteiro.

Passo 1: escolha um fluxo de dinheiro

Pegue uma página que recebe lead ou reduz suporte. Exemplo: `/contato`, `/demo`, `/checkout` ou `/login`.

Anote o que deveria acontecer em linguagem simples:

Visitante abre a página.
Clica no botão principal.
Preenche nome, e-mail e mensagem.
Recebe confirmação.
O time recebe o lead.

Passo 2: rode um teste com agente de navegador

Se você tem time técnico, peça para rodar com Browser Use ou outra ferramenta de agente no navegador. O projeto Browser Use tem biblioteca Python e CLI, e o README mostra exemplos de preencher formulário, extrair dados e fazer QA.

Se você não tem time técnico agora, faça a versão manual com IA: grave a tela, descreva o fluxo e peça para a IA transformar em checklist de bugs. Não é tão bom, mas já tira você do achismo.

Passo 3: use este prompt de QA

Você é meu agente de QA.
Teste a URL: [cole a URL]
Objetivo do fluxo: [explique em 1 frase]
Dispositivo: mobile primeiro.
Faça apenas ações seguras.
Não envie dados reais.
Não compre nada.
Não altere cadastro.
Entregue uma tabela com: passo, esperado, encontrado, evidência e prioridade.

Passo 4: transforme bug em tarefa

Bug sem dono vira decoração de backlog.

Para cada problema, registre:

Bug: botão de WhatsApp não abre no mobile.
Impacto: lead não consegue falar com vendas.
Prioridade: alta.
Dono: marketing ou dev.
Prazo: hoje.
Como conferir: abrir URL no iPhone e clicar no botão principal.

O agente ajuda a achar. Você ainda precisa decidir.

Resultados esperados

Eu esperaria 3 ganhos simples no primeiro mês.

Primeiro: menos bug bobo em página crítica. Botão quebrado, campo sem validação, link errado, layout estourado no mobile.

Segundo: mais velocidade antes de publicar. Em vez de depender da memória de alguém, você roda o mesmo checklist toda vez que mexer numa página de conversão.

Terceiro: melhor conversa entre marketing e tecnologia. O relatório sai com passo, evidência e prioridade. Menos "não está funcionando". Mais "clique aqui, veja isso, corrija aquilo".

O número que eu mediria é simples: quantos bugs o agente achou antes do cliente?

Se em 30 dias ele não achou nada relevante, mate o piloto. Ferramenta que não encontra problema e não economiza tempo é enfeite com login.

FAQ

O que é QA com IA?

QA com IA é usar um modelo ou agente para testar fluxos digitais, encontrar erro, gerar checklist e registrar evidência. Quando o agente usa navegador, ele pode clicar, digitar e navegar como uma pessoa.

Isso substitui meu time de QA?

Eu não usaria assim. Eu usaria para o trabalho repetitivo: testar página crítica, conferir formulário, simular fluxo e apontar erro comum. A decisão final continua humana.

Qual página eu devo testar primeiro?

Eu começaria pela página que vira dinheiro ou lead: contato, orçamento, checkout, login ou agendamento. Página institucional pode esperar.

Dá para usar em produção?

Dá, mas com trava. Não envie dados reais, não compre, não altere cadastro e não dê acesso sensível no primeiro teste. Melhor ainda: use staging.

Qual métrica mostra se valeu a pena?

Meça bugs encontrados antes do cliente, tempo economizado por teste e queda em chamados causados por erro simples. Se não mexer em nenhum desses números, corte.

Conclusão

QA com IA não é glamour. É faxina operacional.

E é exatamente por isso que eu gosto.

Founder não precisa de mais demo bonita. Precisa de menos botão quebrado, menos lead perdido e menos reunião para descobrir erro óbvio.

Meu conselho: escolha uma página crítica hoje, rode o método SITE e veja se o agente encontra um bug que você não tinha visto.

Se encontrar, você ganhou um detector barato de problema.

Se não encontrar, pelo menos clicou no próprio site. Tem founder que não faz isso desde o lançamento. Acontece nas melhores famílias.