Entrevistas de QA Automation testam conhecimento de frameworks, padrões de automação e — acima de tudo — se você consegue escrever testes que ficam verdes por outro motivo além de sorte. Abaixo estão as perguntas mais comuns com respostas modelo. Senior: arquitetura, trade-offs, mentoria e tomada de decisão.
Em termos que essa pessoa já usa: custo por release, tempo do commit até a confiança, defeitos que chegam aos clientes. Uma suíte que custa dois engenheiros por mês e economiza dez horas manuais por release se paga em cadência semanal, não trimestral — a conta muda de equipe para equipe e deveria ser mostrada, não afirmada. A parte honesta da resposta é dizer claramente o que não vai ser automatizado e por quê.
Meça antes de mexer em qualquer coisa: quais testes falham mais, quais demoram mais, quais nunca pegaram um defeito real. Geralmente um número pequeno explica a maior parte da dor. Coloque os flaky em quarentena para o build ficar verde e a equipe voltar a confiar, depois conserte-os ou apague-os. Apagar é uma opção legítima — um teste em que ninguém confia tem valor negativo, porque consome atenção e não entrega nada.
Ajuda quando pessoas não técnicas realmente leem e escrevem os cenários, o que é raro e exige que alguém seja dono da linguagem. Piora as coisas quando a própria equipe escreve Gherkin para si mesma: você ganha uma camada em português sobre código que ninguém de fora lê, mais uma indireção de step-definitions que transforma uma mudança de duas linhas em uma caçada. Se o product owner nunca abre os feature files, abandone isso.
Pese o que é caro de mudar: a linguagem que a equipe já usa, como a ferramenta lida com espera, se ela roda no CI sem display, e a saúde do projeto — cadência de releases, idade das issues em aberto. Benchmarks de velocidade importam menos porque o tempo de execução da suíte é dominado pela sua aplicação, não pelo driver. Pergunte o que acontece se a ferramenta for abandonada.
Uma falha que diz o que quebrou em vez de dizer que uma assertion retornou false: o passo, o screenshot, o log de rede, o diff entre esperado e real. Agrupar por causa suspeita em vez de por arquivo importa mais que o estilo visual. A medida real é se um engenheiro consegue decidir em trinta segundos se a falha é dele — qualquer coisa mais demorada e o relatório é ignorado.
Defeitos que escaparam primeiro — bugs que chegaram à produção em uma área coberta por testes, já que é isso que a suíte existe para prevenir. Depois a taxa de flakiness e o tempo do commit até um sinal confiável. O percentual de cobertura é a métrica de que se deve desconfiar: é fácil aumentá-la sem testar nada relevante, e uma equipe cobrada para aumentá-la vai fazer isso.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Senior QA Automation →