Perguntas de entrevista para QA que testam relato de bug e coragem de segurar release
QA é trabalho de comunicação com fantasia técnica. Achar o defeito costuma ser a parte fácil. O valor está num relato sobre o qual alguém consegue agir sem precisar de conversa, e em ter coragem de dizer que a release não está pronta quando todo mundo na sala quer que esteja. As duas coisas aparecem numa entrevista, e nenhuma aparece num certificado de teste.
O que o trabalho envolve de verdade
O analista de QA desenha e executa teste, explora o software atrás das falhas que ninguém especificou, registra defeito e dá um parecer sobre prontidão para release. Em muitos times também cuida da suíte automatizada e da instabilidade que vem junto.
A posição é estruturalmente desconfortável e isso é o trabalho. QA é quem diz às pessoas que o trabalho delas não está pronto, normalmente sob pressão de prazo, normalmente como último passo antes de subir. Fazer isso de um jeito que gera ação em vez de ressentimento é a habilidade de verdade.
As perguntas, e como soa uma boa resposta
Use as perguntas como estão. Cada uma vem com o que é uma resposta forte, para que duas pessoas avaliando o mesmo candidato cheguem à mesma conclusão pelo mesmo motivo.
1. Me mostra como você escreveria o relato de um bug que você não consegue reproduzir de forma confiável.
Uma boa resposta: Declara a frequência com honestidade, dá tudo o que sabe (ambiente, passos tentados, o que variou) e nem enterra nem exagera. Defeito intermitente é onde a disciplina de relato aparece.
2. É dia de release e você acha que não deveria subir.
Uma boa resposta: Coloca o risco em termos de impacto no usuário, não em contagem de defeito, entrega a decisão a quem é dono dela, e não cede na pressão. Resposta forte aceita que a decisão pode ir contra e diz isso com clareza.
3. Uma pessoa desenvolvedora diz que o seu bug não é bug.
Uma boa resposta: Volta ao comportamento esperado e a onde ele está definido, em vez de escalar por autoridade. Se a especificação é ambígua, diz isso — é um achado de verdade, não uma discussão perdida.
4. Você tem dois dias para testar algo que pede duas semanas.
Uma boa resposta: Prioriza por risco e declara explicitamente o que ficou sem teste. A metade crítica é avisar o que não foi testado. Cobertura parcial silenciosa é como QA vira teatro.
5. Como você decide o que automatizar?
Uma boa resposta: Estabilidade, repetição e custo da falha. Não tudo. Resposta forte cita o custo de manutenção e teste instável, que é o custo honesto que ninguém coloca no business case.
6. Um defeito que você levantou foi fechado como não corrigir e depois chegou no usuário.
Uma boa resposta: Documentou na época, e não gasta a resposta se justificando. O que você quer é alguém que torna o risco visível e depois aceita a decisão.
7. Como você testa algo sem especificação?
Uma boa resposta: Explora, constrói um modelo do comportamento esperado a partir do produto e do usuário, e pergunta. Conforto com ambiguidade é a maior parte do teste exploratório.
8. Qual bug você tem orgulho de ter achado?
Uma boa resposta: De preferência algo sutil, achado pensando no sistema e não clicando na tela. É onde o instinto de teste real aparece e é difícil de inventar.
Uma ficha de avaliação para pontuar
Dê de 1 a 4 em cada linha, e anote a nota antes de assistir ao próximo. A nota escorrega quando ela é dada em relação a quem você acabou de ver.
| Critério | Como é uma nota 4 |
|---|---|
| Qualidade do relato | Escreve relato acionável para defeito intermitente. Nota 2 enterra ou exagera. |
| Segurar release | Coloca risco em impacto no usuário e não cede. Nota 2 acompanha a sala. |
| Discordar de quem desenvolve | Volta ao comportamento esperado definido. Nota 2 escala por autoridade ou desiste. |
| Declarar o que não foi testado | Nomeia as áreas sem cobertura. Nota 2 reporta só o que passou. |
| Julgamento de automação | Pesa custo de manutenção e instabilidade. Nota 2 automatizaria tudo. |
Como rodar a triagem
- QA encaixa melhor em rodada gravada que a maioria das vagas técnicas, porque relatar e convencer são as habilidades centrais e as duas aparecem na fala.
- Junte um relato de bug escrito a partir de um cenário curto. O artefato escrito é a entrega de verdade e fala não testa escrita.
- Faça três ou quatro perguntas, com limite de dois minutos. Comunicar risco de forma concisa é o trabalho.
- Dê peso à pergunta do dia de release. QA que não sustenta posição sob prazo entrega confiança, não garantia.
- Guarde um exercício exploratório prático para a lista curta. Instinto de teste aparece fazendo, não descrevendo.
Rodar isso numa pilha grande de inscritos é onde a conta cresce. A VoxScreen manda essas perguntas num link só, transcreve e avalia cada resposta pelos critérios que você definiu e devolve a lista ranqueada — de graça para 50 candidatos por mês, sem cartão.
Erros comuns ao contratar para esta vaga
- Entrevistar sobre ferramenta e certificação. Os dois se ensinam e nenhum prevê se um relato é acionável.
- Contratar QA agradável. O valor inteiro da função é alguém que diz não na hora que conta, o que é desconfortável na entrevista e certo em produção.
- Não testar escrita. Relato de bug é escrito, lido de forma assíncrona por gente com pressa, e resposta falada testa outra habilidade.
- Tratar contagem de caso de teste como entrega. Cobertura de risco importa. Contagem mede atividade.
- Usar rodada gravada para avaliar exploração. Ela mostra como a pessoa pensa sobre teste, não como testa. O exercício prático faz isso.
Perguntas frequentes
O que perguntar para um analista de QA?
Pergunte como escreveria o relato de um defeito que não reproduz de forma confiável, o que faz no dia da release quando acha que não deveria subir, o que acontece quando alguém diz que o bug dele não é bug, e como lida com dois dias para testar duas semanas de trabalho. Isso cobre relato, coragem, discordância e cobertura honesta.
Entrevista gravada serve para contratar QA?
Serve melhor que para a maioria das vagas técnicas. As habilidades centrais — comunicar risco, escrever defeito acionável, sustentar posição sob prazo — são majoritariamente de comunicação e aparecem na fala. Junte um relato de bug escrito, porque o artefato escrito é a entrega, e guarde um exercício exploratório para a lista curta.
Como separar relato de bug bom de ruim?
O bom permite agir sem conversa: ambiente, passos exatos, esperado contra obtido, frequência declarada com honestidade, e severidade argumentada por impacto no usuário em vez de afirmada. A pergunta do defeito intermitente revela isso rápido, porque é ali que a disciplina de relato existe ou não existe.
QA deve se reportar à engenharia?
É pergunta de desenho de time e não de contratação, mas influencia a entrevista: se QA se reporta ao time cujo trabalho avalia, a disposição de segurar uma release importa ainda mais, porque a pressão estrutural para ceder é maior. Dê peso a essa pergunta de acordo.