Uma entrevista de QA Manual avalia seu domínio da teoria de testes, das técnicas de design de testes e sua capacidade de escrever bug reports sobre os quais um desenvolvedor realmente consiga agir. Abaixo estão as perguntas mais cobradas em nível Junior e Middle, cada uma com uma resposta modelo. Middle: compreensão mais profunda, otimização e situações reais de trabalho.
Você seleciona por risco, não por cobertura. Isso significa o que mudou neste release e o que isso afeta, os fluxos que custam dinheiro se quebrarem — auth, checkout, pagamento — e as áreas com mais histórico de defeitos. Depois você deixa claro o que não foi executado, para que a decisão de lançar seja da equipe e não silenciosamente sua.
Você não decide sozinho, mas prepara o terreno: quantos usuários são afetados, com que frequência, se existe um workaround, e qual o risco de a correção quebrar outra coisa. Um desalinhamento cosmético em uma tela pouco usada com release amanhã é um "agora não" legítimo. O que não é legítimo é fechar silenciosamente — ele vai para o backlog com a justificativa, senão o mesmo bug é redescoberto todo trimestre.
Comece assumindo que os ambientes são diferentes, não que o teste está errado. Compare dados, configuração, feature flags, versões e timing — o staging costuma ser mais lento, o que expõe race conditions e esperas implícitas. Depois verifique se o teste depende de estado deixado por outro teste. Rotular como flaky e simplesmente rodar de novo é o que transforma um bug real de ambiente em um vermelho permanentemente ignorado.
Códigos de status tanto para sucesso quanto para falha, o schema e os tipos da resposta, campos obrigatórios versus opcionais, e o que acontece com campos faltando, extras ou de tipo errado. Depois autorização — a mesma requisição sem token e com o token de outra pessoa. Por fim os extremos: arrays vazios, payloads enormes e chamadas repetidas, já que idempotência é onde os bugs de API se escondem.
Você não espera por requisitos perfeitos, você torna a ambiguidade visível. Escreva como você interpretou, liste os casos que a spec não responde, e leve isso ao analista ou product owner antes de construir casos em cima de uma suposição. Perguntas feitas antes do fim do desenvolvimento custam uma conversa; as mesmas perguntas feitas depois custam retrabalho.
Ele diz que a maioria das verificações deveria ser unit tests rápidos, menos integration tests, e bem poucos end-to-end lentos. Para o QA manual a consequência é que seu tempo é desperdiçado reexecutando manualmente algo que um unit test já cobre. O esforço manual deve ficar onde humanos são melhores que máquinas: exploratory testing, usabilidade e cenários que ninguém pensou em automatizar.
Um bug é um comportamento que contradiz um requisito, uma especificação ou uma expectativa razoável do usuário. Um pedido de feature pede um comportamento que nunca foi combinado. A zona cinzenta é o terceiro caso — a spec fica em silêncio e o comportamento é ruim — e discutir sobre o rótulo nesse caso é perda de tempo. Descreva o impacto, deixe o product owner decidir o rótulo, e garanta que não se perca de nenhuma forma.
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 Middle QA Manual →