Perguntas comportamentais em entrevistas de QA testam uma coisa específica. Você consegue questionar um desenvolvedor que fecha um bug válido, dizer a um PM que o prazo dele compromete a cobertura, e assumir um erro quando algo vai para produção? Os entrevistadores esperam o formato STAR (Situação, Tarefa, Ação, Resultado). O erro mais comum é parar na Ação e pular o Resultado, que é a única parte que torna a história crível.

Por que perguntas comportamentais importam para QA

QA é um papel colaborativo. Você trabalha com desenvolvedores que podem discordar dos seus bug reports, PMs que querem pular testes para cumprir um prazo, e stakeholders que querem garantias que você não pode dar. Os entrevistadores usam perguntas comportamentais para descobrir: você consegue lidar com essas situações de forma profissional?

O que eles avaliam sem dizer explicitamente:

  • Comunicação: Você consegue explicar problemas técnicos para pessoas não técnicas?
  • Colaboração: Você trabalha com os desenvolvedores, ou contra eles?
  • Julgamento: Você toma boas decisões sob pressão?
  • Responsabilidade: Você assume a responsabilidade ou repassa a culpa?
  • Mentalidade de crescimento: Você aprende com falhas e erros?

O formato STAR

Toda resposta comportamental deve seguir essa estrutura:

S: Situação — Qual era o contexto? (1-2 frases) T: Tarefa — Qual era sua responsabilidade específica? (1 frase) A: Ação — O que você fez? (Essa é a parte principal: seja específico) R: Resultado — O que aconteceu? Quantifique se possível. (1-2 frases)

Não pule o R. O resultado é o que torna a história crível. "O bug foi corrigido" é aceitável. "O bug foi corrigido antes de publicarmos, e descobrimos depois que afetaria 30% dos usuários" é muito melhor.

As perguntas principais e respostas fortes

"Me conte sobre uma vez em que você encontrou um bug crítico pouco antes de um release."

O que eles avaliam: Como você lida com situações de alta pressão, suas habilidades de comunicação, seu julgamento sobre risco. Resposta forte (STAR): Situação: "Estávamos na fase final de testes de uma feature importante de pagamento, programada para publicar na manhã seguinte. Tarde da noite eu estava rodando testes de regressão." Tarefa: "Eu era responsável pelo sign-off do release do ponto de vista do QA." Ação: "Descobri que o código de desconto estava sendo aplicado incorretamente: ele subtraía do total errado, então usuários que aplicavam um desconto podiam acabar pagando mais em alguns casos extremos. Documentei o bug imediatamente com os passos para reproduzir, criei um ticket de alta prioridade, e mandei mensagem diretamente para o engenheiro líder e o gerente de produto. Não apenas no ticket. Dei o cenário exato: 'aqui está o input, aqui está o que acontece, aqui está o impacto financeiro.'" Resultado: "Tomamos a decisão de atrasar 24 horas, corrigir o cálculo e retestar. O bug foi corrigido e verificado no dia seguinte. O PM me disse depois que pegar isso antes do release nos salvou de um problema significativo de atendimento ao cliente e possíveis reembolsos."

"Me conte sobre uma vez em que você discordou de um desenvolvedor sobre um bug."

O que eles avaliam: Sua capacidade de defender qualidade sem ser confrontador, sua comunicação técnica. Resposta forte: Situação: "Reportei um bug onde o seletor de data permitia selecionar datas no passado em uma feature de agendamento futuro. O desenvolvedor fechou como 'não é bug' — disse que o spec não dizia explicitamente para bloquear datas passadas." Tarefa: "Precisei decidir se escalaria ou deixaria pra lá." Ação: "Em vez de simplesmente reabrir o ticket, escrevi meu raciocínio: a feature é um sistema de agendamento, e permitir datas passadas cria agendamentos inválidos que falham na validação do servidor. Usuários que selecionam uma data passada recebem um erro confuso. Incluí um screenshot do que os usuários veriam. Depois pedi ao desenvolvedor para revisar os critérios de aceite junto comigo, não para 'ganhar' mas para alinharmos. Também levantei o ponto no nosso daily como pergunta, não como conflito: 'Podemos esclarecer o comportamento esperado para datas passadas?' O PM confirmou que deveria bloquear datas passadas." Resultado: "A correção foi adicionada ao próximo sprint. O desenvolvedor e eu tivemos uma boa conversa sobre como ler nas entrelinhas dos critérios de aceite — às vezes 'agendamento' implica apenas futuro, mesmo que não esteja escrito explicitamente."

"Me conte sobre uma vez em que você teve que testar algo sem documentação ou com requisitos pouco claros."

O que eles avaliam: Sua capacidade de improviso, como você lida com ambiguidade, se você faz as perguntas certas ou apenas testa às cegas. Resposta forte: Situação: "Uma feature foi desenvolvida por um contratado e entregue sem casos de teste ou specs claros. Me pediram para testá-la antes de adicioná-la ao produto." Tarefa: "Testar e avaliar a qualidade de uma feature sem documentação." Ação: "Primeiro conversei com o desenvolvedor. Até uma call de 30 minutos me deu a intenção: quem usa isso, o que é sucesso, quais são os edge cases com que se preocupavam? Depois usei testes exploratórios, fazendo anotações conforme descobria o comportamento. Tratei como engenharia reversa do spec: documentei o que a feature realmente fazia e comparei com o que faria sentido lógico para o usuário. Encontrei várias lacunas onde o comportamento parecia errado, não contra um spec escrito, mas contra o que um usuário razoável esperaria. Escrevi isso primeiro como perguntas, não como bugs, e revisei com o PM para confirmar antes de registrar." Resultado: "Identificamos 4 defeitos reais, 2 dos quais a equipe concordou que eram problemas mesmo sem spec. Também criei um documento de spec informal a partir das minhas anotações de teste, que se tornou a referência para futuros testes de regressão."

"Me conte sobre uma vez em que você deixou passar um bug que chegou à produção."

O que eles avaliam: Sua responsabilidade, sua capacidade de aprender com erros, seu pensamento pós-mortem. Essa é uma pergunta armadilha para candidatos que afirmam que nada nunca escapa. Resposta forte: Situação: "Um bug passou em que os e-mails de notificação de usuário mostravam o status errado do pedido. Só acontecia para uma combinação específica de tipo de pedido e método de pagamento." Tarefa: "Assumir minha parte do que aconteceu e prevenir recorrências." Ação: "Quando foi descoberto após o release, fiz uma análise de causa raiz dos meus testes. Tinha testado o fluxo de notificação, mas apenas com o tipo de pedido padrão. A combinação que acionou o bug não estava nos meus casos de teste: não pensei na matriz de tipo de pedido × método de pagamento. Após a correção ser publicada, adicionei uma suite de testes com tabela de decisão especificamente para cenários de notificação, cobrindo todas as combinações relevantes. Também adicionei essa classe de teste à nossa definição de pronto para qualquer feature que envia notificações." Resultado: "Nos próximos três sprints, a suite de testes expandida pegou 2 problemas na lógica de notificação antes de chegarem ao release. A retrospectiva foi desconfortável mas melhorou genuinamente nosso processo."

"Me conte sobre uma vez em que você teve que priorizar com mais testes do que tempo."

O que eles avaliam: Seu pensamento baseado em risco, sua comunicação sobre escopo. Resposta forte: Situação: "Três features saíram do desenvolvimento ao mesmo tempo no penúltimo dia do sprint. Realisticamente eu conseguia testar apenas duas delas de forma completa." Tarefa: "Decidir o que testar e comunicar a situação." Ação: "Avaliei o risco de cada feature. Pagamento: alto risco (dinheiro envolvido, muitos usuários). Perfil de usuário: risco médio (mudança cosmética). Relatórios admin: risco menor (audiência pequena). Dediquei tempo completo de teste ao pagamento, testes completos porém mais rápidos ao perfil, e smoke testing básico nos relatórios. Avisei o PM: 'Fiz smoke testing nos relatórios admin mas não cobri todos os cenários; se publicarmos, devemos monitorar por problemas e planejar testes completos no próximo sprint.'" Resultado: "Publicamos. Houve um bug visual menor nos relatórios admin que foi encontrado por usuários em um dia, mas como era só para admins e cosmético, o impacto foi baixo. Nenhum problema crítico. O PM apreciou a transparência: prefere saber o que não foi testado do que descobrir depois de um incidente em produção."

"Como você lida com pressão de stakeholders para reduzir o tempo de testes?"

Situação: "Um lançamento de produto foi adiantado em uma semana sem redução de escopo." Tarefa: "Manter qualidade trabalhando com menos tempo." Ação: "Tive uma conversa direta com o PM: 'Temos menos tempo mas o mesmo escopo. Aqui está o que consigo cobrir de forma completa e aqui está o que vou ter que pular ou fazer apenas smoke testing. O que importa mais pra você?' Criei uma matriz de risco simples: features por impacto no negócio e probabilidade de bug. Essa conversa nos tirou do 'testar menos' para o 'priorizar o que testamos'. Também propus automatizar a suite de regressão para os caminhos felizes, para rodarmos em 10 minutos em vez de 90 manualmente." Resultado: "Encontramos o equilíbrio certo. Três features receberam testes completos, duas receberam apenas caminho feliz. Nenhum bug crítico passou. A conversa sobre automação gerou um sprint dedicado a automação três meses depois."

Outras perguntas para preparar

  • "Me conte sobre uma vez em que você teve que aprender uma nova ferramenta de testes rapidamente."
  • "Descreva uma situação em que você melhorou um processo de testes."
  • "Me conte sobre uma vez em que você trabalhou com um desenvolvedor ou colega difícil."
  • "Como você lidou com feedback crítico sobre seu trabalho?"
  • "Me conte sobre uma vez em que você foi além da sua função para melhorar a qualidade."

Para cada uma dessas, pense em uma história específica antes da entrevista. Respostas vagas ("Em geral eu tento me comunicar...") são muito mais fracas do que específicas ("No sprint 4 do meu último projeto...").

Erros comuns

A não-resposta: "Não tive realmente essa situação." Isso quase nunca é verdade e soa como evasão. A resposta da culpa: Descrever o conflito como "eu estava certo, eles estavam errados." Mesmo que você estivesse certo, faça a história ser sobre encontrar um terreno comum. O resultado que falta: Terminar com "e então enviei o bug report." O que aconteceu depois? Foi corrigido? O que você aprendeu? A resposta longa demais: STAR deve levar no máximo 2 a 3 minutos. Pratique reduzir.

Entrevistas comportamentais recompensam preparação. Antes da sua próxima entrevista, escreva 5 a 7 histórias específicas da sua experiência real. Você vai descobrir que elas se aplicam a mais perguntas do que espera. Uma boa história sobre um bug crítico pode responder 3 perguntas comportamentais diferentes, dependendo de como você a enquadra.

→ Veja também: Top 50 Perguntas de Entrevista para QA Engineer em 2026 (Com Respostas) | Perguntas de Entrevista Agile para QA: O que Esperar e Como Responder | Como Se Preparar para uma Entrevista Técnica QA: Guia Passo a Passo