Pular para o conteúdo

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.

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?”.

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 senha
usando 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.

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 (“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.

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 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.

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.