IA e Automação Inteligente em QA
Até aqui, IA em teste apareceu de um jeito específico: você escreve o requisito, o modelo sugere casos de teste, uma pessoa revisa. É o uso mais maduro e mais fácil de confiar. Esta nota olha para o que vem depois disso, onde a IA para de só sugerir texto e começa a interagir com a aplicação: comparar telas, consertar um seletor quebrado, ou até executar o teste sozinha.
Da geração de casos de teste a QA agêntico
Seção intitulada “Da geração de casos de teste a QA agêntico”A geração de casos de teste com IA generativa já apresentada é só o primeiro degrau de uma escada maior:
flowchart LR A[IA sugere o que testar] --> B[IA ajuda a escrever o teste] B --> C[IA observa a tela e aponta diferença] C --> D[IA conserta o teste quando a tela muda] D --> E[IA planeja e executa o teste sozinha]
Cada degrau depende menos de quem testa escrever passo a passo, e exige mais supervisão de outro tipo: não “como fazer”, mas “a IA fez a coisa certa?”.
Engenharia de prompt para quem testa
Seção intitulada “Engenharia de prompt para quem testa”Um prompt vago devolve teste vago. “Escreva testes para essa tela” é tão específico quanto “escreva um caso de teste” sem dizer qual. Um prompt que rende teste utilizável costuma ter quatro partes:
- Papel: quem o modelo deve simular (“você é uma pessoa de QA sênior revisando uma história de usuário”)
- Contexto: o requisito, a regra de negócio, o que já existe
- Formato de saída: tabela, Gherkin, lista numerada, o que for mais fácil de revisar
- Restrições: quantidade de casos, o que incluir (casos de borda, negativos) ou excluir
Você é uma pessoa de QA revisando a história abaixo.Gere casos de teste em formato Dado/Quando/Então,cobrindo cenário positivo, negativo e dois casos de borda.Não invente regra de negócio que não está no texto.
História: como usuária, quero redefinir minha senhausando o e-mail cadastrado.Para tarefas maiores, vale quebrar em prompts menores em sequência (técnica chamada de prompt chaining): um prompt lista os cenários, o seguinte detalha os passos de um cenário específico, em vez de pedir tudo de uma vez e revisar uma resposta gigante. Fica mais fácil achar onde o modelo errou.
Testes visuais com IA
Seção intitulada “Testes visuais com IA”Teste de regressão visual compara um print da tela antes e depois de uma mudança, para pegar quebra que nenhuma asserção de texto detecta: um botão que saiu do lugar, uma cor errada, um elemento sobreposto.
A comparação pixel a pixel tradicional tem um problema chato: qualquer diferença mínima (uma fonte renderizada de um jeito levemente diferente, um pixel de anti-aliasing) já acusa falha, mesmo quando ninguém olhando a tela notaria diferença. Ferramentas com IA tentam comparar de um jeito mais parecido com o olho humano, ignorando ruído visual irrelevante e destacando só a diferença que realmente muda a experiência (um elemento que sumiu, um texto cortado, uma sobreposição).
Vale a pena quando a tela muda pouco e o visual importa de verdade (uma página de checkout, por exemplo). Para uma tela que muda de layout toda hora, teste visual vira fonte de alarme falso constante.
Self-healing tests
Seção intitulada “Self-healing tests”Self-healing (“autocorreção”) é a promessa de a ferramenta encontrar um jeito alternativo de localizar um elemento quando o seletor original quebra, em vez de o teste simplesmente falhar.
Um ponto que confunde iniciante: o auto-wait do Playwright, visto em Browser, Context e Page, não é self-healing. Auto-wait espera o elemento aparecer e ficar estável, ou seja, resolve problema de tempo. Self-healing tenta resolver problema de estrutura: o elemento mudou de atributo, de posição no DOM, e a ferramenta tenta achar outro jeito de identificar “a mesma coisa”. O Playwright, por si só, não faz isso; quem oferece self-heal de verdade em cima dele são serviços de terceiros.
Os limites importam tanto quanto o recurso:
- nem toda falha é recuperável. Se o elemento foi removido de verdade, não tem o que “curar”
- o risco mais sério é o falso positivo: se um botão mudou de comportamento mas um elemento parecido continua existindo por perto, a ferramenta pode “curar” o seletor e o teste passa, mesmo que a experiência real esteja quebrada
- mudança pequena de atributo costuma ser bem resolvida; mudança grande de estrutura da página, não
Self-healing reduz manutenção de seletor frágil. Não substitui revisar o que o teste está verificando de fato.
QA agêntico e testes autônomos
Seção intitulada “QA agêntico e testes autônomos”A diferença entre “IA ajuda a escrever teste” e “QA agêntico” é a mesma diferença entre um assistente que sugere e alguém que age: um agente observa o estado da aplicação, decide o próximo passo, executa essa ação (clicar, chamar uma API, navegar) e repete o ciclo até cumprir um objetivo, sem alguém escrevendo cada passo em código.
flowchart LR A[Observa o estado da tela] --> B[Decide a próxima ação] B --> C[Executa: clique, API, navegação] C --> D[Avalia o resultado] D --> A
Vale tratar isso com os pés no chão: é um tema recente, e ainda não existe um corpo de boas práticas consolidado nem um padrão amplamente aceito sobre como avaliar a qualidade de um agente de teste. O que já está mais claro é o papel de quem testa nesse cenário: deixa de escrever o passo a passo do teste e passa a supervisionar o agente, definindo o que ele pode fazer, revisando o que ele decidiu e corrigindo quando ele erra o objetivo.
Testes contínuos
Seção intitulada “Testes contínuos”Testes contínuos significam testar em cada etapa do pipeline, não só numa fase isolada no fim. Isso já apareceu em Terminologias de QA, na definição de CI/CD, e em Framework com Playwright e TypeScript, na integração da suíte Playwright com o pipeline.
O que muda com os recursos desta nota é o tanto de teste que cabe em cada etapa sem travar a esteira: geração de caso de teste e teste visual rodam bem num pipeline automatizado, porque são rápidos e não dependem de ninguém decidir nada no meio. Já um agente que planeja e executa sozinho ainda pede supervisão, o que hoje limita onde ele entra num fluxo de entrega totalmente automatizado.
Riscos e papel de quem testa
Seção intitulada “Riscos e papel de quem testa”Os riscos se acumulam conforme a IA ganha mais autonomia:
- alucinação: o modelo descreve um comportamento que o sistema não tem
- viés: o modelo repete padrões dos dados de treinamento, inclusive os ruins
- falso positivo mascarado: tanto em teste visual quanto em self-healing, a ferramenta pode “resolver” uma diferença que na verdade é um bug
- confiança automática: aceitar o que a IA produziu sem checar, só porque veio de uma ferramenta nova
O fio que conecta toda esta nota, da geração de caso de teste ao agente autônomo: quanto mais a IA faz sozinha, mais importa a revisão de quem entende o negócio, não menos. A certificação ISTQB CT-GenAI resume esse princípio formalizando um currículo em cima dele, mas a ideia é simples, a IA acelera o trabalho repetitivo, e quem testa continua sendo quem decide o que importa testar.
Referências
Seção intitulada “Referências”- Certified Tester - Testing with Generative AI (CT-GenAI) - ISTQB, en
- Writing Effective Prompts for Testing Scenarios - Microsoft Tech Community, en
- Self-Heal for your Playwright tests - BrowserStack (documentação oficial), en