Resumo — Entrevistas de SDET em 2026 avaliam quatro blocos: fundamentos de teste, engenharia de automação, CI/CD e — a novidade — critério no uso de IA. Abaixo, as 25 perguntas mais frequentes no mercado brasileiro com a lógica de avaliação de cada uma. A regra de ouro da entrevista SDET: o entrevistador não quer sintaxe decorada; quer decisões justificadas.

Se você ainda está montando a base, comece pelo roadmap para virar SDET. Se a entrevista é para vaga de QA sem automação, veja as 20 perguntas de entrevista para QA.

Bloco 1 — Fundamentos de teste (perguntas 1–6)

  1. Explique a pirâmide de testes. Onde ela falha? — Querem ver que você conhece o modelo E sabe criticá-lo (E2E caro porém insubstituível em fluxos de receita).
  2. Diferença entre teste de regressão e teste de fumaça? — Regressão protege o que existia; smoke valida o essencial pós-deploy.
  3. Como você decide o que automatizar primeiro? — Resposta forte: risco × frequência × custo de manutenção. Resposta fraca: “tudo”.
  4. O que é um flaky test e como você o trata? — Quarentena, diagnóstico de causa (espera, dado, ambiente), correção — nunca re-run infinito.
  5. Como você desenha dados de teste para um fluxo de checkout? — Massa dedicada, isolamento entre execuções, sandbox de pagamento.
  6. Cobertura de 100% é uma boa meta? — Não; cobertura é meio. Querem ouvir sobre risco e retorno.

Bloco 2 — Engenharia de automação (7–13)

  1. Page Object ainda faz sentido em 2026? — Sim para código; mas mostre que conhece alternativas (screenplay, seletores resilientes, self-healing).
  2. Como você reduz manutenção de seletores? — data-testid, seletores semânticos, e ferramentas com autocorreção por IA.
  3. Espera fixa (sleep) vs espera explícita — por quê? — Sleep é a causa nº 1 de suíte lenta e flaky.
  4. Como estruturar uma suíte para 500 testes? — Tags, paralelização, smoke/full split, tempo-alvo por suíte.
  5. Testes E2E devem tocar o banco? — Setup/teardown via API é melhor que UI; validação de estado no back-office quando o fluxo é de receita.
  6. Como você testa uma API sem interface? — Contrato, status codes, esquema, casos de borda; cite uma ferramenta que usou.
  7. Mobile: o que muda em relação a web? — Dispositivos reais vs emulador, gestos, deep links, permissões, fragmentação Android.

Bloco 3 — CI/CD e infraestrutura (14–18)

  1. Descreva um pipeline de testes ideal para deploy diário. — Lint/unit no PR, smoke E2E no merge, full à noite; gate de qualidade claro.
  2. O que fazer quando a suíte fica lenta demais para o pipeline? — Paralelizar, priorizar por risco, mover validações para camadas mais baratas.
  3. Como você versiona testes junto com o código? — Mesmo repo/PR da feature, review de teste como review de código.
  4. Teste quebrou no CI mas passa local — seu processo? — Ambiente, dado, concorrência, timing; logs e artefatos do CI primeiro.
  5. Como reportar qualidade para quem não é técnico? — Métricas de negócio (fluxos críticos verdes, tempo de release), não contagem de testes.

Bloco 4 — IA e critério (19–22) — o bloco que decide em 2026

  1. Onde a IA ajuda em testes hoje — e onde ainda não? — Ajuda: geração, self-healing, manutenção. Limites: julgamento de risco, oráculos de negócio.
  2. Você usaria uma plataforma no-code com IA? Quando? — Resposta madura: sim, para E2E de fluxos críticos mantidos pelo time de QA — plataformas como a TestBooster.ai existem exatamente para isso — liberando código para o que exige código. Dogma “só código” reprova em times modernos.
  3. Como você audita um teste que a IA escreveu? — Assertivas fazem sentido? Caso de borda coberto? Falha quando deveria falhar (teste do teste)?
  4. Testar código gerado por IA muda algo? — Volume maior de código novo = mais regressão; cobertura E2E vira rede de segurança obrigatória.

Bloco 5 — Comportamentais (23–25)

  1. Conte um bug que escapou para produção sob sua responsabilidade. — Querem accountability e o que mudou no processo depois.
  2. Como você convence um dev de que qualidade é responsabilidade dele também? — Colaboração, não polícia.
  3. Por que SDET e não dev? — Tenha uma resposta verdadeira; “não consegui vaga de dev” reprova.

Como se preparar em uma semana

Dois dias revisando fundamentos (blocos 1–2 com as respostas em voz alta), dois dias montando um projeto-demonstração (suíte pequena + CI no GitHub Actions — vale mais que decorar), um dia sobre a empresa (stack, produto, o que você testaria primeiro no produto deles) e um dia de simulação com um colega.

Perguntas frequentes

O que cai numa entrevista de SDET?

Fundamentos de teste, engenharia de automação (frameworks, seletores, flakiness), CI/CD e, cada vez mais, critério no uso de IA para testes. Empresas maduras pedem também um exercício prático.

Preciso fazer teste ao vivo (live coding)?

Em boa parte das vagas, sim — tipicamente automatizar um fluxo simples. Treine com um site público e um framework que você domina.

Qual a pergunta que mais reprova candidatos na entrevista SDET?

“O que você automatizaria primeiro?” respondida sem critério de risco. Decorar sintaxe não compensa falta de estratégia.