Top 50 Perguntas de Entrevista para QA Engineer em 2026 (Com Respostas)

Entrevistas de QA avaliam três coisas: fundamentos, habilidades técnicas e julgamento. Você consegue falar claramente sobre conceitos de teste, escrever código de teste funcional e tomar a decisão certa quando não há resposta óbvia? A diferença entre uma resposta fraca e uma forte é especificidade, não profundidade técnica. "Testo tudo com cuidado" reprova; nomear os critérios baseados em risco que você realmente usa passa.

Fundamentos de testes

Verificação pergunta "estamos construindo o produto certo?" ao checar se o produto corresponde a especificações, designs e requisitos. Validação pergunta "estamos construindo o produto correto?" ao checar se o produto resolve de verdade o problema do usuário.

Resposta fraca: "Verificação checa o código, validação checa o produto." É vago e confunde os dois.

Resposta forte: "Verificação é interna: o build corresponde ao que foi especificado? Validação é externa: o que construímos satisfaz de verdade a necessidade do usuário? Um produto pode passar na verificação (corresponde exatamente à spec) e reprovar na validação (a spec estava errada sobre o que os usuários precisam)."

Um cenário de teste é uma descrição de alto nível do que testar, como "usuário consegue fazer login com credenciais válidas". Um caso de teste é a implementação passo a passo detalhada: inputs exatos, outputs esperados, pré-condições, pós-condições.

Smoke testing é uma passagem superficial pela funcionalidade mais crítica após um build. O app inicia, o usuário consegue fazer login, o fluxo principal funciona? O objetivo é decidir rapidamente se o build vale a pena ser testado mais a fundo.

Regression testing verifica que a funcionalidade existente ainda funciona após novas mudanças. É mais amplo e mais lento, porque você está protegendo o que já funcionava de ser quebrado pelo novo código.

Teste exploratório é aprendizado, design de testes e execução de testes simultâneos. Em vez de seguir um script predefinido, o testador explora a aplicação, usa o que aprende para guiar onde olhar a seguir, e se adapta em tempo real. É valioso para encontrar bugs que testes com scripts não cobrem porque ninguém pensou em escrever um caso de teste para eles.

Teste caixa-preta trata o sistema como uma caixa preta: você só conhece os inputs e os outputs esperados, não a implementação interna. Teste caixa-branca usa o conhecimento do código interno, então você escreve testes baseados em caminhos de código, branches e lógica.

A maioria dos engenheiros de QA faz testes caixa-preta. O conhecimento caixa-branca é útil para entender quais casos extremos testar.

Design de testes

Testes baseados em risco: priorize pela probabilidade de falha e pelo impacto da falha. Um fluxo de pagamento falhando tem alto impacto. Um "tooltip ao passar o mouse" falhando tem baixo impacto. Uma nova feature tem maior probabilidade de falha do que uma estável que não foi alterada em meses.

Resposta fraca: "Testo tudo com cuidado." Ninguém testa tudo. Tempo e pipelines de build não permitem.

Resposta forte: "Começo entendendo o que mudou e o que tem maior risco. Novo código recebe mais cobertura do que código não alterado. Fluxos visíveis ao usuário recebem mais cobertura do que os apenas de admin. Também conversaria com o desenvolvedor para entender quais casos extremos ele tem mais dúvida."

Particionamento de equivalência divide o espaço de inputs em grupos onde todos os valores do grupo se comportam da mesma forma. Em vez de testar toda idade possível, você testa um valor de cada partição: abaixo de 18, 18 a 65, acima de 65.

Análise de valor de fronteira testa as bordas dessas partições (17, 18, 65, 66) porque bugs se concentram nas fronteiras. Código que trata "18 a 65" corretamente frequentemente tem um erro de off-by-one exatamente em 18 ou 65.

Uma resposta forte inclui: happy path (credenciais válidas → sucesso), caminhos negativos (senha errada, usuário errado, campos vazios, SQL injection, inputs muito longos). Também casos de fronteira (comprimento mínimo/máximo do campo) e considerações não funcionais (e se o botão de submit for clicado duas vezes?).

Título (conciso, descreve o problema), ambiente (browser, sistema operacional, versão do app), passos para reprodução (exatos, numerados), resultado esperado, resultado real. E severidade/prioridade e anexos (screenshot, vídeo, logs de rede se relevante).

Automação

Automatize quando: o teste é executado frequentemente (regressão), os dados de teste são consistentes, e o cenário é estável. Também quando a automação vai economizar mais tempo do que custa construir e manter.

Não automatize quando o teste requer julgamento humano (usabilidade, design visual), ou quando a feature muda todo sprint e os testes seriam reescritos constantemente. Também não automatize testes rodados uma vez e descartados (verificação pontual de migração de dados).

POM é um padrão de design que encapsula interações com a página em uma classe. Em vez de chamar page.getByLabel('Username').fill(email) em cada teste, você cria uma classe LoginPage com um método login(email, password). Os testes chamam o método; quando o formulário de login muda, você corrige em um só lugar.

Testes unitários na base: muitos, rápidos, baratos de escrever e rodar. Testam funções e componentes individuais. Testes de integração no meio: menos, testam interações entre componentes. Testes end-to-end no topo: menos ainda, mais lentos, testam fluxos completos de usuário pela UI.

O formato de pirâmide importa. Invertê-la (principalmente testes E2E) gera feedback lento, custo de manutenção alto e suites flaky.

Testes flaky falham aleatoriamente no mesmo código. Causas comuns: problemas de timing (elemento não está pronto quando o teste age sobre ele), poluição de estado entre testes. E conflitos de execução paralela (dois testes modificando os mesmos dados simultaneamente).

Correção: para timing, use waits adequados (aguarde condições específicas, não delays fixos). Para poluição, garanta que cada teste configure e limpe seu próprio estado. Para conflitos paralelos, use dados de teste únicos por teste ou rode testes conflitantes em série.

Perguntas específicas de Playwright

Cada ação do Playwright aguarda automaticamente que o elemento-alvo atinja um estado "acionável" antes de prosseguir. Para click(): o elemento precisa estar visível, estável e habilitado. Para fill(): o elemento precisa ser editável. Essa espera acontece automaticamente com um timeout configurável (padrão de 30 segundos).

Use storageState. Faça login uma vez num arquivo de setup, salve os cookies de autenticação e localStorage do browser em um arquivo JSON, então configure cada teste para carregar esse estado:

// Setup global: faz login e salva o estado de auth
await page.context().storageState({ path: 'auth.json' });

// playwright.config.ts
use: {
  storageState: 'auth.json'
}

Cada teste começa já autenticado sem passar pela UI de login.

Agile e processo

O QA deve estar envolvido desde o início: revisando requisitos e critérios de aceite durante o planejamento, fazendo perguntas de esclarecimento durante o refinamento. Também escrevendo ou revisando casos de teste antes do desenvolvimento começar. Os testes não deveriam começar só quando o desenvolvimento estiver "pronto". Isso cria um gargalo no final do sprint.

Mover as atividades de teste para mais cedo no processo de desenvolvimento. Em vez de testar depois que o código está completo, você revisa requisitos para testabilidade e escreve casos de teste durante o desenvolvimento. Roda testes como parte do processo de build. O objetivo é encontrar defeitos mais cedo, quando são mais baratos de corrigir.

Traga evidências: passos exatos de reprodução, comportamento esperado dos requisitos ou design, e o comportamento real. Se for genuinamente ambíguo (não está na spec), escalone para o product owner que pode decidir se o comportamento atual é aceitável. Não discuta. Documente.

Avalie o impacto: quem é afetado, com que frequência acontece, existe um contorno? Escalone imediatamente para o tech lead e o product owner com a avaliação de impacto. Não segure o release silenciosamente. A decisão de lançar, atrasar ou fazer hotfix pertence ao product owner, não ao QA. Seu trabalho é expor o risco com clareza e rapidez.

Carreira e situacionais

QA Engineer foca em estratégia de testes, execução de testes e processo de qualidade. SDET (Software Development Engineer in Test) é um cargo com maior carga de engenharia: construir frameworks de testes, infraestrutura de testes, pipelines de CI/CD e ferramentas de teste. SDETs escrevem código de qualidade de produção para sistemas de teste, não apenas scripts de teste.

Na prática, os títulos se sobrepõem e as empresas os usam de formas diferentes. Olhe a descrição da vaga, não o título.

Estruture com STAR: Situação (o que estava sendo lançado), Tarefa (seu papel), Ação (como você encontrou, o que fez), Resultado (o que aconteceu). Seja específico: números, prazos, impacto real. "Encontrei um bug que teria afetado todos os usuários do checkout e atrasamos o release para corrigir" é melhor do que "encontrei um bug importante uma vez."

Cite coisas específicas: blogs que lê (Ministry of Testing, changelog do Playwright), conferências (TestBash), newsletters, cursos que completou. "Leio artigos online" é uma resposta fraca. Fontes e exemplos específicos são fortes.