20 perguntas de entrevista para QA (com respostas comentadas)

Entrevista de QA costuma ser mais variada do que parece. Em alguns processos seletivos, basta saber o que é um caso de teste e conhecer o ciclo de bugs. Em outros, especialmente em empresas de tecnologia com times ágeis, o recrutador quer saber se você entende de automação, se consegue trabalhar dentro de um sprint sem virar o gargalo e se tem alguma opinião sobre IA no contexto de testes.

Este guia reúne 20 perguntas que aparecem com frequência nesse tipo de entrevista. Elas estão divididas em três blocos: fundamentos, práticas e metodologias, e automação com tendências. Cada pergunta tem uma resposta e um comentário explicando o que o entrevistador realmente está avaliando.

Segundo o U.S. Bureau of Labor Statistics, a demanda por profissionais de QA deve crescer 15% entre 2024 e 2034, bem acima da média geral das ocupações. A área está aquecida e o nível de exigência subiu junto. Vale chegar preparado.

Como usar este guia

Não adianta decorar as respostas. O que funciona numa entrevista é conseguir explicar o raciocínio por trás de cada conceito e conectá-lo à sua experiência real. Se você nunca trabalhou com determinada ferramenta ou metodologia, diga isso, e complemente mostrando que entende o princípio.

Os comentários destacados ao longo do texto mostram o que o entrevistador geralmente quer avaliar em cada pergunta. Leia com atenção: às vezes a pergunta parece técnica, quando na verdade está medindo maturidade profissional ou capacidade de comunicação.

Bloco 1 — Fundamentos de QA

Estas sete perguntas aparecem em praticamente qualquer processo seletivo, independente do nível da vaga. São os conceitos que qualquer QA precisa dominar.

1. Qual a diferença entre QA, QC e Teste de Software?

Resposta: QA (Quality Assurance) é um processo preventivo: envolve definir padrões, acompanhar o desenvolvimento e garantir que o processo inteiro está orientado à qualidade. QC (Quality Control) é reativo: inspeciona o produto para verificar se ele atende aos requisitos. Teste de Software é uma atividade específica dentro do QC, é a execução de verificações sobre o sistema. 

2. O que é o STLC e como ele se relaciona com o SDLC?

Resposta: O SDLC (Software Development Life Cycle) é o ciclo completo de desenvolvimento, do levantamento de requisitos até a entrega e manutenção. O STLC (Software Testing Life Cycle) é o ciclo específico de testes, que corre em paralelo: análise de requisitos, planejamento, design dos casos de teste, configuração de ambiente, execução e encerramento. O QA entra desde a fase de requisitos, não só quando o código já está pronto.

3. Qual a diferença entre teste funcional e não funcional? Dê exemplos.

Resposta: Testes funcionais verificam se o sistema faz o que deveria fazer, um login que autentica o usuário corretamente, um cálculo que retorna o valor certo. Testes não funcionais verificam como o sistema se comporta, velocidade de resposta (performance), comportamento sob carga (stress), usabilidade, segurança, compatibilidade. Ambos são necessários; ignorar os não funcionais é uma das causas mais comuns de problemas em produção.

4. O que é um caso de teste? Como você escreveria um bom caso de teste?

Resposta: Um caso de teste é um conjunto de condições e passos que verificam um comportamento específico do sistema. Um bom caso de teste tem: identificador único, título claro, pré-condições (o que precisa estar verdadeiro antes de executar), passos numerados e objetivos, resultado esperado e critério de aceite definido. Além disso, deve ser independente o suficiente para ser executado sem depender de outros testes, e escrito de forma que alguém que não conhece o sistema consiga reproduzir.

🔍 O que o entrevistador avalia: entrevistadores percebem quando o candidato lista os campos mecanicamente sem entender por que cada um existe. Falar sobre o critério de aceite e a reprodutibilidade demonstra maturidade prática.

5. O que é um plano de testes? Quando ele é necessário?

Resposta: Um plano de testes documenta a estratégia, escopo, recursos, cronograma e critérios de entrada e saída para um ciclo de testes. É necessário em projetos com maior complexidade, múltiplas equipes ou requisitos regulatórios. Em times ágeis pequenos, pode ser substituído por uma definição de “done” bem estruturada e critérios de aceite nas histórias de usuário, o importante é que o acordo sobre qualidade esteja registrado de alguma forma.

6. Qual a diferença entre Smoke Test, Sanity Test e Regression Test?

Resposta: Smoke Test é uma verificação rápida das funcionalidades principais para saber se o build está estável o suficiente para testes mais detalhados, se a autenticação não funciona, não adianta testar o restante. Sanity Test é focado: verifica se uma correção específica ou uma pequena mudança funcionou sem causar quebras óbvias ao redor. Regression Test é mais amplo e sistemático: garante que funcionalidades que funcionavam antes continuem funcionando após qualquer alteração.

7. O que você faz quando encontra um bug crítico em produção e não há documentação do fluxo?

Resposta: Primeiro, avaliaria o impacto imediato: quantos usuários são afetados, se há workaround possível e se é necessário acionar alguém além do time de dev. Depois, reproduzo o bug com o máximo de detalhes que consigo, capturas de tela, logs, condições do ambiente. Comunico o time com essas evidências antes de esperar pela documentação. A ausência de docs não paralisa o trabalho; ela exige mais investigação e colaboração direta com quem conhece o sistema.

🔍 O que o entrevistador avalia: Pergunta comportamental disfarçada de técnica. Avalia autonomia, capacidade de comunicação sob pressão e senso de prioridade, não conhecimento técnico específico.

Bloco 2 — Práticas e Metodologias

Aqui entram as perguntas sobre como você trabalha no dia a dia, especialmente em times ágeis. 

8. Como você trabalha com QA dentro de um time Scrum?

Resposta: O QA entra desde o refinamento das histórias, ajudando a identificar critérios de aceite e riscos antes mesmo do desenvolvimento começar. Durante o sprint, testa incrementalmente conforme as tarefas são concluídas, não espera o final do ciclo para começar.

9. Como você prioriza o que vai testar quando o prazo é curto?

Resposta: Uso uma abordagem baseada em risco: primeiro identifico quais áreas têm maior impacto para o negócio e maior probabilidade de falha. Funcionalidades críticas, fluxos de pagamento, integrações com terceiros e partes do código que sofreram mudanças recentes entram na prioridade alta. 

🔍 O que o entrevistador avalia: Candidatos que dizem “priorizo o mais importante” sem detalhar o critério de priorização não convencem. Mencionar risk-based testing com exemplos concretos faz diferença.

10. O que é BDD? Você já trabalhou com ele na prática?

Resposta: BDD (Behavior-Driven Development) é uma abordagem em que os critérios de aceite são escritos em linguagem estruturada e compreensível para todos no time. O formato mais comum é o Gherkin, com a estrutura Given (dado que), When (quando), Then (então). Ferramentas como Cucumber ou SpecFlow transformam esses cenários em testes automatizados executáveis. Na prática, o maior valor do BDD é forçar a conversa sobre o comportamento esperado antes de escrever código.

11. Como você lida com um desenvolvedor que discorda que o comportamento reportado é um bug?

Resposta: Começo buscando os critérios de aceite definidos para aquela funcionalidade. Se o comportamento desvia do que foi acordado, o argumento é técnico, não pessoal. Se os critérios estão ambíguos ou ausentes, envolvo o product owner ou responsável pelo produto para alinhar a expectativa. O objetivo não é ganhar o debate, é garantir que a decisão seja tomada com base em evidências e que o impacto para o usuário esteja claro para todos.

🔍 O que o entrevistador avalia:maturidadee profissional. Candidatos que “entram em conflito” com devs são um sinal de alerta. O entrevistador quer ver capacidade de argumentação baseada em dados e facilidade para escalar quando necessário.

12. O que são testes de regressão e quando você os executa?

Resposta: Testes de regressão verificam que funcionalidades previamente validadas continuam funcionando após alterações no código. Devem ser executados sempre que há uma mudança, seja um bug fix, uma nova feature ou uma atualização de dependência. Em times com CI/CD, a regressão automatizada roda a cada push ou pull request.

13. Como você documenta os resultados de um ciclo de testes para um gestor não técnico?

Resposta: Resumo o ciclo em termos de cobertura (o que foi testado), qualidade (quantos bugs foram encontrados, por severidade e status) e risco residual (o que ficou fora do escopo e por quê). Evito jargões técnicos e foco no impacto: “3 bugs críticos foram corrigidos antes da entrega; 1 bug de baixa prioridade foi aceito como risco controlado para essa versão.” Gestores precisam entender o estado real do produto, não a lista de casos executados.

🔍 O que o entrevistador avalia: Habilidade de comunicação é cada vez mais cobrada de QAs em nível pleno e sênior. Uma análise de 400 vagas de QA publicada no Medium mostrou que ferramentas de gestão de testes aparecem em 45% dos requisitos, o mercado valoriza quem sabe não só testar, mas também reportar com clareza.

14. Você já trabalhou com testes de performance? Quais ferramentas conhece?

Resposta: Testes de performance avaliam como o sistema se comporta sob condições de carga, tempo de resposta, throughput, uso de recursos e comportamento no limite. As ferramentas mais usadas são JMeter (open source, versátil, boa para testes de carga e stress), k6 (orientado a código, fácil de integrar em CI/CD) e Gatling (voltado a alta concorrência, com relatórios detalhados). A escolha depende do tipo de teste, da stack do projeto e de quão integrado o teste precisa estar no pipeline.

🔍 O que o entrevistador avalia: mesmo candidatos que não são especialistas em performance ganham pontos ao mostrar que conhecem as ferramentas e sabem quando cada uma faz sentido. Desconhecer completamente o tema é um ponto negativo em vagas de nível pleno em diante.

Bloco 3 — Automação e Tendências

Este é o bloco que separa candidatos para vagas mais técnicas. 

15. Qual a diferença entre Selenium, Cypress e Playwright? Quando você escolheria cada um?

Resposta: Selenium é o mais maduro e suporta múltiplas linguagens e navegadores, mas exige mais configuração e tem manutenção mais trabalhosa por depender de WebDriver. Cypress é rápido de configurar, tem boa experiência de debug e funciona muito bem em aplicações JavaScript modernas, a limitação está no suporte a múltiplos domínios e à ausência nativa de testes mobile. Playwright é mais novo, suporta múltiplos browsers, múltiplas linguagens e tem suporte melhor a cenários assíncronos e testes mobile via emulação.

16. O que são flaky tests e como você lidaria com eles no dia a dia?

Resposta: Flaky tests são testes que passam em algumas execuções e falham em outras sem que o comportamento do sistema tenha mudado. As causas mais comuns são: dependência de timing (esperas insuficientes ou hardcoded), dados de teste instáveis, dependência de ordem de execução e problemas de ambiente. Para lidar com eles: identificar e isolar o teste problemático, investigar a causa raiz, remover esperas fixas em favor de esperas condicionais e garantir que cada teste seja independente e idempotente.

17. O que é um pipeline CI/CD e qual o papel dos testes automatizados nele?

Resposta: CI (Integração Contínua) é a prática de integrar código frequentemente, a cada commit, com validação automática. CD (Entrega/Deploy Contínuo) estende isso até a entrega em ambiente de staging ou produção. Os testes automatizados são a camada de segurança do pipeline: testes unitários rodam rápido a cada push, testes de integração validam componentes combinados e testes E2E cobrem os fluxos críticos antes da entrega. A ideia é que nenhuma mudança avance no pipeline sem passar pelas verificações de qualidade.

🔍 O que o entrevistador avalia: QAs que entendem CI/CD são muito mais valorizados em times DevOps. Falar apenas em “executar testes no Jenkins” sem entender a lógica do pipeline é insuficiente para vagas sênior.

18. Como você garante que seus testes automatizados continuem funcionando quando o layout da aplicação muda?

Resposta: O primeiro passo é evitar seletores frágeis, IDs gerados automaticamente, classes CSS genéricas ou posicionamento no DOM. O ideal é usar atributos de teste dedicados (data-testid) ou locators semânticos. Além disso, o padrão Page Object Model centraliza a lógica de interação com cada tela: quando o layout muda, você ajusta um único lugar. Mais recentemente, ferramentas com self-healing conseguem adaptar locators automaticamente quando detectam mudanças na interface, reduzindo o trabalho de manutenção de forma significativa.

🔍 O que o entrevistador avalia: O custo de manutenção de testes automatizados é um dos maiores pontos de dor do mercado. Candidatos que entendem como reduzir esse custo, com boas práticas ou com ferramentas adequadas, saem na frente.

19. Como a IA está mudando o trabalho de QA? O que você acha que muda na prática?

Resposta: A IA está acelerando principalmente duas coisas: a criação de casos de teste (gerando cenários a partir de requisitos ou do comportamento real dos usuários) e a manutenção de testes automatizados (com self-healing que adapta os scripts a mudanças de interface). O papel do QA não deixa de existir, ele muda: menos tempo em tarefas repetitivas, mais foco em estratégia de cobertura, testes exploratórios e análise de risco. O raciocínio crítico sobre o que testar e por quê continua sendo insubstituível.

🔍 O que o entrevistador avalia: Não espera um especialista em IA. Quer saber se o candidato está atualizado, tem uma opinião formada e consegue pensar de forma crítica sobre como a área está evoluindo 

20. Qual ferramenta de automação você escolheria hoje para um projeto novo, partindo do zero?

Resposta: Depende de alguns fatores. Qual é o tipo da aplicação, web, mobile, API? Qual é a linguagem principal do time? Quanto tempo existe para onboarding? Qual o custo de manutenção aceitável? Para quem quer velocidade de criação sem depender de código, existem ferramentas baseadas em IA e linguagem natural que eliminam a curva de seletores frágeis.

Falando em automação de testes…

Várias das perguntas deste terceiro bloco, sobre manutenção de testes, self-healing, criação sem código e integração com CI/CD, giram em torno de um problema que times de QA enfrentam toda semana: quanto tempo se perde mantendo testes que quebram quando o layout muda, e quanto custo de entrada existe em ferramentas tradicionais como Selenium e Cypress.

O TestBooster.ai é uma plataforma brasileira que resolve esse problema de forma direta. Com ela, você escreve testes em linguagem natural, em português, sem código, sem seletores frágeis, e a IA orientada por intenção executa e mantém esses testes automaticamente. Quando o layout da aplicação muda, o TestBooster se adapta, sem testes quebrados esperando manutenção manual.

A ferramenta é até 24x mais rápida que Cypress ou Selenium na criação de testes e é pioneira mundial em automação de testes mobile com linguagem natural.

Se você quer chegar numa entrevista com automação que realmente funciona e não vira dívida técnica, vale conhecer: testbooster.ai/pt-br