Senior QA Manual — Perguntas de entrevista QA Manual

Você entra em uma equipe sem nenhum processo de teste. O que você faz no primeiro mês?

Primeiro descubra onde a qualidade realmente dói: converse com o suporte, leia os incidentes dos últimos três meses, pergunte aos desenvolvedores o que eles têm medo de mexer. Depois corrija o que for mais barato com maior efeito, geralmente uma suíte de smoke no caminho crítico mais um fluxo de bugs que as pessoas de fato sigam. Escrever um documento de estratégia de teste na primeira semana é o erro clássico — ninguém lê, e você ainda não ganhou credibilidade para isso.

Como você justifica o headcount de QA para um gestor que vê o teste como custo?

Você para de discutir sobre cobertura e passa a mostrar o que escapou. Rastreie os defeitos encontrados depois do release, quanto eles custaram em tempo de suporte, hotfixes e clientes perdidos, e compare com o custo de pegá-los antes. O argumento que convence não é "precisamos de mais testers", é "foi isso que nos custou lançar quebrado no trimestre passado, e é isso que gastaríamos para prevenir a maior parte".

O que faria você argumentar contra automatizar um teste?

Quando a feature ainda está mudando bastante, porque você manteria o teste mais do que ele te protege. Quando a verificação é barata para um humano e cara para uma máquina, como julgamento visual ou usabilidade. Quando o teste é inerentemente flaky — timing, terceiros, pagamentos reais — já que um build vermelho em que ninguém confia é pior que nenhum build. A automação compensa em caminhos estáveis, repetitivos e de alto valor, não em tudo.

Um bug crítico chegou em produção. Como você conduz o follow-up?

Sem culpar ninguém, e focado no mecanismo, não na pessoa. Reconstrua a linha do tempo, separe o gatilho do motivo pelo qual ele passou, e pergunte por que cada camada deixou passar — requisitos, review, testes, ambiente. O resultado é um número pequeno de mudanças com dono definido, não uma resolução de "ter mais cuidado". Se a mesma classe de bug escapou duas vezes, o defeito está no processo, não no tester.

Como você decide quais métricas de qualidade reportar, e quais delas mentem?

Métricas úteis respondem a uma pergunta sobre a qual alguém vai agir: defeitos que escaparam, tempo até a detecção, taxa de flakiness, cobertura dos fluxos críticos. Número de test cases e número de bugs encontrados são as clássicas enganosas, porque ambas premiam produzir mais de alguma coisa em vez de encontrar o que importa — e ambas sobem quando a qualidade piora. Qualquer métrica que você reporte vai ser otimizada, então reporte só as que você ficaria tranquilo em ver manipuladas.

O produto quer cortar QA do sprint para cumprir um prazo. Como você reage?

Não com uma recusa, com uma troca. Nomeie especificamente o que não vai ser verificado e o que isso pode significar para os usuários, nos termos deles — receita, carga de suporte, reputação. Ofereça um escopo menor que você realmente consiga cobrir em vez de fingir que o escopo completo cabe. O objetivo é que a decisão seja tomada com o risco visível; se mesmo assim lançarem, essa é uma decisão de negócio legítima e agora está documentada.