Um modelo de IA gera a continuação mais provável do seu input. Um prompt vago como "escreva um teste Playwright para login" produz um esqueleto com placeholders YOUR_URL e seletores CSS, porque é isso que a maioria dos dados de treinamento parece. O mesmo pedido com um papel, contexto específico e restrições explícitas sobre tipos de locator produz código que você pode colar diretamente.

Por que a qualidade do output de IA é principalmente um problema seu

Claude, ChatGPT e GitHub Copilot não são mecanismos de busca. Eles geram a continuação mais provável do seu input. Se o input for vago, a continuação é genérica. Se for específico e bem estruturado, o output é útil.

O modelo não sabe:

  • Qual framework você está usando
  • Como é seu código
  • Qual nível de detalhe você quer
  • O que você já tentou
  • Quais restrições você tem

Quando você recebe um output ruim, a primeira pergunta não é "esse modelo é ruim?" É "meu prompt deu ao modelo o que ele precisava para fazer bem?"

A estrutura de prompt de quatro partes

Um prompt que funciona para tarefas de QA tipicamente tem quatro componentes. Você nem sempre precisa de todos os quatro, mas quando o output é ruim, geralmente um deles está faltando.

Papel: diga ao modelo qual especialista ele deve ser. "Você é um engenheiro sênior de automação de QA" ou "Você é um especialista em TypeScript especializado em arquitetura de testes Playwright" muda o registro e a profundidade do output. Contexto: descreva a situação. Qual framework, qual linguagem, que tipo de aplicação, qual restrição você está trabalhando. Quanto mais específico, melhor. Tarefa: o pedido em si, formulado com precisão. Não "escreva um teste" mas "escreva um teste Playwright em TypeScript que faz login usando storageState e verifica que o cabeçalho do dashboard mostra o nome do usuário." Formato: como você quer o output. Só código? Código com comentários? Com uma breve explicação antes? Uma tabela? Especifique isso ou você vai receber o que o modelo usa por padrão.

Exemplo de prompt ruim:

"Escreva um teste Playwright para login"

Exemplo do mesmo prompt com os quatro componentes:

"Você é um engenheiro sênior de automação de QA. Estou trabalhando em um projeto Playwright TypeScript usando o padrão Page Object Model. A página de login está em https://lab.becomeqa.com, usa um formulário de email/senha e redireciona para /dashboard no sucesso. Escreva um teste que: faz login com credenciais de teste das variáveis de ambiente, verifica que a URL muda para /dashboard, e verifica que um heading com o texto 'My Travel Items' está visível. Use apenas locators getByRole e getByLabel. Sem comentários no código."

O segundo prompt produz código que você pode colar diretamente. O primeiro produz um esqueleto com placeholders.

Prompts para geração de testes

Ao gerar testes Playwright, os problemas mais comuns são:

Locators genéricos. A IA usa por padrão o que viu mais nos dados de treinamento, que inclui muitos seletores CSS. Force explicitamente a evitá-los.
"Use apenas locators getByRole, getByLabel, getByPlaceholder ou getByTestId. Não use seletores CSS ou XPath."
Asserções faltando. Testes gerados frequentemente têm uma asserção no final. Testes reais precisam de mais.
"Inclua asserções em cada passo relevante, não só no estado final. Verifique estados intermediários onde eles importam."
Sem contexto de tratamento de erro. Se você está testando um cenário de erro, diga explicitamente.
"Escreva um teste para o caso em que o usuário envia o formulário com o campo de email vazio. Verifique que a mensagem de erro 'Email is required' aparece abaixo do campo de email."
Dados de teste fixos no código. Previna isso desde o início.
"Use process.env para credenciais. Não coloque nenhum username, senha ou URL fixos no código. Use referências a variáveis de ambiente como placeholders."

Gerando testes a partir de uma user story

Esse padrão de prompt é particularmente útil. Cole uma user story diretamente e peça testes:

"Você é um engenheiro de automação de QA. Aqui está uma user story:
>
'Como usuário logado, quero adicionar um novo item à minha lista de viagem para rastrear o que preciso levar.'
>
A aplicação está em https://lab.becomeqa.com. Escreva testes Playwright TypeScript que cobrem: o happy path (item é adicionado e aparece na lista), adicionar um item duplicado, e adicionar um item com nome que ultrapassa o limite de caracteres. Use locators getByRole. Inclua uma asserção por teste que verifica o resultado específico. Retorne apenas o código dos testes."

Gerando dados de teste

Para geração de dados de teste, a sintaxe do Faker.js muda entre versões e modelos de IA às vezes inventam nomes de métodos. Ancore isso:

"Gere uma função factory TypeScript que cria um objeto de usuário aleatório com os campos: email (formato válido), firstName, lastName, password (mínimo 8 caracteres, uma letra maiúscula, um número). Use apenas a sintaxe do @faker-js/faker v8. Retorne apenas a função."

Prompts para revisão de código

Revisão de código com IA é subutilizada por engenheiros de QA. É particularmente boa em pegar coisas fáceis de perder na primeira leitura.

Revisar qualidade de testes:
"Revise este teste Playwright para: esperas fixas no código (page.waitForTimeout), seletores CSS, asserções faltando, testes que dependem da ordem de execução, e qualquer prática que reduza a estabilidade dos testes. Liste cada problema com a linha em que aparece e por que é um problema."
Revisar consistência do Page Object Model:
"Estou construindo um Page Object Model em TypeScript. Aqui estão minha classe base de página e um page object. Revise se: todos os seletores estão na classe de página (não nos testes), os métodos de ação retornam promises corretamente, o construtor segue o padrão, e a classe está faltando algum método que seria útil baseado no que está importado. Sugira adições específicas."
Verificar qualidade de locators:
"Olhe esses locators dos meus testes Playwright. Para cada um, diga: é frágil (propenso a quebrar em um redesign de UI)? Se sim, sugira uma alternativa mais estável usando locators semânticos."

Prompts para depuração

Quando um teste falha e você não sabe por quê, a IA pode ajudar, mas você precisa dar o output da falha, não só o código.

Template para ajuda com depuração:
"Este teste Playwright está falhando. Aqui estão:
1. O código do teste
2. A mensagem de erro completa e o stack trace
3. O que a aplicação deveria fazer
>
[cole cada um]
>
Quais são as causas mais prováveis dessa falha? Liste-as em ordem de probabilidade e, para cada uma, explique o que eu devo verificar."

A mensagem de erro é crítica. Sem ela, o modelo está chutando. Com ela, muitas vezes consegue apontar o problema exato: um await faltando, um locator que não casa, um problema de timing.

Diagnóstico de teste flaky:
"Este teste passa cerca de 70% das vezes e falha 30% das vezes com este erro: [erro]. O teste faz: [descreva o fluxo]. Quais são as causas prováveis dessa falha intermitente no Playwright? O que você verificaria primeiro?"

Prompts para documentação

Gerar documentação para código de teste existente é um dos usos de maior valor de IA em QA. Ninguém gosta de escrever, leva tempo, e a IA faz razoavelmente bem.

Gerar README de suite de testes:
"Escreva uma seção de README para este diretório de suite de testes Playwright. Inclua: o que a suite cobre, pré-requisitos (variáveis de ambiente necessárias, passos de setup), como rodar todos os testes, como rodar um arquivo específico, e como rodar em modo de depuração. Baseie-se neste playwright.config.ts e neste arquivo de teste de exemplo: [cole os dois]"
Resumir cobertura de testes:
"Aqui estão meus arquivos de teste Playwright. Para cada arquivo, escreva uma frase descrevendo o que ele testa. Depois escreva um parágrafo de resumo do que está coberto e do que está faltando com base nos fluxos típicos de uma aplicação web com login, gerenciamento de dados e funcionalidades de exportação."
Gerar bug report a partir de teste falhando:
"Este teste Playwright está falhando e preciso escrever um bug report. Aqui estão o teste, o erro e os screenshots. Escreva um bug report neste formato: Título, Ambiente, Passos para Reproduzir, Resultado Esperado, Resultado Atual, Severidade."

Prompts para aprendizado

Quando você está aprendendo um novo recurso do Playwright, não peça exemplos genéricos. Peça exemplos específicos para seu tipo de projeto:

"Explique como o storageState do Playwright funciona, usando um exemplo concreto onde uma suite de testes tem roles de admin e usuário regular. Mostre o arquivo de setup que gera os states e um teste que usa cada role. Use TypeScript."
"Entendo como page.route() funciona para mocking simples. Explique como usar route.fallback() para mockar parcialmente uma API, deixando algumas requisições chegarem ao backend real enquanto intercepta apenas as específicas. Mostre um exemplo concreto."

A restrição concreta força o modelo a ir além da explicação introdutória para a parte que realmente é útil.

Quando iterar e quando recomeçar

Depois de receber output de IA, você tem duas opções: iterar ou recomeçar com um prompt melhor.

Itere quando a estrutura está correta mas algo específico está errado. Faça perguntas de acompanhamento direcionadas:
  • "Mude o locator na linha 8 para usar getByLabel em vez de getByPlaceholder"
  • "Adicione uma asserção após o envio do formulário que verifica que o toast de sucesso está visível"
  • "Refatore o helper de login em uma função separada"
Recomece quando a abordagem geral está errada: o modelo gerou JavaScript quando você queria TypeScript, produziu testes sem Page Object quando você queria POM, ou entendeu errado o cenário de teste. Nesse ponto, um prompt inicial melhor é mais rápido do que tentar redirecionar.

Um bom critério: se você iterou três vezes e ainda está corrigindo problemas estruturais, recomece com um prompt mais detalhado.

Janelas de contexto e conversas longas

Ferramentas de IA perdem contexto ao longo de conversas longas. Após 20 ou mais trocas, o modelo pode começar a "esquecer" coisas que você estabeleceu no início: a convenção de locator que especificou ou a estrutura de classe que pediu.

Três práticas ajudam:

Mantenha um documento de templates de prompts. Para tarefas comuns (gerar um teste, revisar um page object, escrever um bug report), salve seus melhores prompts. Não redigite. Copie e ajuste. Inicie uma nova conversa para cada tarefa. Contexto reutilizável em uma conversa cria confusão em outra. Conversas curtas e focadas produzem output melhor do que sessões longas. Reafirme as restrições principais se o output derivar. Se o modelo começar a usar seletores CSS depois que você disse para não usar, lembre explicitamente: "Lembre-se: apenas getByRole, getByLabel, getByPlaceholder, getByTestId. Sem seletores CSS."

O que as ferramentas de IA não conseguem fazer em QA

Entender os limites evita frustração e ajuda a saber quando parar de tentar.

Não conseguem rodar seus testes. O modelo não tem acesso ao seu browser, à sua aplicação ou ao seu test runner. Pode escrever código que acredita que funcionará, mas não consegue verificar. Não conseguem inspecionar sua aplicação ao vivo. Sem o Playwright MCP configurado, o modelo não tem ideia de como é sua UI. Está escrevendo testes contra uma versão imaginária da sua aplicação baseada no que você descreve. Se a descrição estiver incompleta, os locators gerados estarão errados. Inventam detalhes de API. Ferramentas de IA às vezes geram chamadas de métodos Playwright que não existem, ou usam métodos reais com assinaturas de parâmetro erradas. Sempre verifique o código gerado contra a documentação do Playwright antes de commitar. Não conhecem as convenções do seu time. A menos que você cole seu código real como contexto, o modelo não sabe se seu time usa factories ou fixtures para dados de teste. Não sabe como sua classe base de página funciona ou como é sua estrutura de imports. Dê exemplos. Não conseguem tomar decisões sobre cobertura. "O que devo testar?" exige entender o risco da funcionalidade, a velocidade do time, o que tem falhado em produção e qual é o nível de risco aceitável. A IA pode sugerir coisas para testar, mas as decisões de cobertura são suas.

Construindo uma biblioteca pessoal de prompts

Com o tempo, colete os prompts que funcionam. Guarde-os em um arquivo markdown, uma página no Notion ou uma pasta .claude de comandos no seu projeto.

Categorias úteis para desenvolver:

  • Gerar um novo teste a partir de uma descrição
  • Revisar um arquivo de teste por problemas de qualidade
  • Gerar dados de teste com Faker
  • Escrever uma classe Page Object a partir de uma descrição de página
  • Depurar um erro do Playwright
  • Gerar um bug report a partir de um teste falhando
  • Resumir lacunas de cobertura de testes
  • Gerar YAML de workflow de CI para Playwright

Cada prompt é um pequeno investimento em qualidade consistente. Você não precisa reinventar a abordagem toda vez que sentar com uma ferramenta de IA.

→ Veja também: IA no QA 2026: O que é Realmente Útil e o que é Hype | Usar ChatGPT para Gerar Casos de Teste: Guia Prático para QA | GitHub Copilot para Engenheiros QA: Para que Realmente Serve | Ferramentas de Geração de Testes por IA Comparadas: O que Funciona em 2026