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. Middle: compreensão mais profunda, otimização e situações reais de trabalho.
1
O que pertence a cada camada do test pyramid, e o que acontece quando a forma se inverte?
Resposta
Unit tests cobrem lógica e rodam em milissegundos, integration tests cobrem as costuras entre componentes, e end-to-end tests cobrem um punhado de caminhos que nunca podem quebrar. Quando a forma se inverte em um cone de sorvete — majoritariamente testes de UI — a suíte fica lenta, flaky e cara de manter, e a equipe começa a ignorar builds vermelhos. A pirâmide é uma afirmação sobre velocidade de feedback, não sobre percentual de cobertura.
2
Como a biblioteca cliente conversa com o navegador?
Resposta
Selenium envia requisições HTTP para um processo driver, que as traduz para o próprio protocolo de automação do navegador — um round trip por comando, por isso testes que fazem muitas chamadas são lentos. Playwright mantém uma única conexão WebSocket e fala o protocolo DevTools diretamente, por isso consegue fazer auto-wait e interceptar tráfego de rede. Essa diferença arquitetural explica a maioria das práticas.
3
Como você roda testes em paralelo sem que eles interfiram entre si?
Resposta
Cada teste precisa dos seus próprios dados e do seu próprio contexto de navegador. Fixtures compartilhadas criadas uma única vez para a suíte costumam ser a culpada — dois testes alteram o mesmo usuário e só falham quando o timing coincide. A correção é criar dados por teste com uma chave única e limpá-los depois, e usar um contexto novo por worker para que cookies e storage não vazem entre eles.
4
Um teste passa localmente e falha no CI. Cite as causas prováveis em ordem.
Resposta
Timing primeiro — o CI é mais lento, então uma race condition que você nunca viu localmente se torna visível. Depois ambiente: versão diferente de navegador, uma fonte faltando que muda o layout, um fuso horário diferente. Depois dados: um registro que sobrou localmente e o CI não tem, ou o contrário. Depois paralelismo, se o CI roda em paralelo o que você rodou em série. Checar nessa ordem encontra o problema muito mais rápido do que ler o diff.
5
O que você mocka em um teste automatizado, e o que não mocka?
Resposta
Mocke serviços de terceiros que você não controla, especialmente pagamentos, e qualquer coisa não determinística — tempo, aleatoriedade. Não mocke o seu próprio backend em um teste end-to-end, porque aí você está testando o frontend contra uma ficção. A interceptação de rede é o meio-termo útil: deixe o sistema real rodar, e faça stub só da chamada que você precisa que falhe sob demanda.
6
Como um HashMap encontra um valor, e por que hashCode importa?
Resposta
Ele calcula o hash da chave para escolher um bucket, depois compara com equals dentro desse bucket. Se hashCode for ruim ou constante, tudo cai em um bucket só e a busca degrada de tempo constante para uma varredura linear de lista. Por isso sobrescrever equals sem sobrescrever hashCode é um bug: dois objetos que são iguais vão gerar hashes diferentes e desaparecer do map em que você acabou de colocá-los.
7
O que é um contract test e o que ele pega que o end-to-end não pega?
Resposta
Ele verifica se um produtor e um consumidor concordam quanto ao formato de uma mensagem, sem precisar rodar os dois ao mesmo tempo. Ele pega a mudança que ninguém avisou — um campo renomeado, um tipo ampliado, um opcional que virou obrigatório — no momento em que é introduzida, em vez de na execução noturna. Seu valor cresce com o número de serviços, e é por isso que um monólito único raramente precisa disso.