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.
Cada pergunta vem com uma resposta modelo para você comparar com a sua.
Page Object Model encapsula cada página ou componente em uma classe que expõe locators e ações de alto nível, então os testes descrevem intenção em vez de cliques. O problema que ele resolve é manutenção: quando a UI muda, você atualiza um page object em vez de cinquenta testes. Também elimina duplicação e deixa os testes legíveis para quem não os escreveu.
Um wait implícito é uma configuração global que faz cada busca de elemento tentar novamente por até N segundos. Um wait explícito mira em uma condição específica — elemento clicável, texto presente — e só espera por ela. Um fluent wait é um wait explícito com intervalo de polling configurável e exceções ignoráveis. Misturar waits implícitos e explícitos causa timeouts acumulados imprevisíveis, então a maioria das equipes desliga o wait implícito por completo e usa só waits explícitos.
A ordem preferida é um atributo de teste dedicado como data-testid, depois id, depois um seletor CSS estável. XPath tem má fama porque o XPath absoluto quebra com qualquer mudança no DOM, e XPaths relativos longos são difíceis de ler. XPath em si é válido e às vezes necessário — por exemplo, selecionar por texto visível ou navegar até um pai — o problema é o XPath frágil, não a linguagem.
Um teste flaky passa e falha sem nenhuma mudança de código. As causas mais comuns são suposições de timing (sleeps fixos em vez de esperar uma condição), dados de teste mutáveis compartilhados, dependência da ordem dos testes, animações, e ambientes ou serviços de terceiros instáveis. Correções: esperar condições explícitas, gerar dados isolados por teste, tornar os testes independentes e idempotentes, fazer stub de serviços externos, e colocar em quarentena os testes flaky em vez de simplesmente rodar de novo até passar.
O paralelismo é configurado no nível do runner e geralmente combinado com um Selenium Grid ou contêineres. Os problemas são estado compartilhado: testes escrevendo na mesma conta de usuário ou linhas de banco de dados, colisões de porta e arquivo, e suposições dependentes de ordem. A correção é cada teste criar seus próprios dados com identificadores únicos, evitar setup global que altera recursos compartilhados, e nunca assumir que roda sozinho.
Playwright conversa com os navegadores via protocolo DevTools, faz auto-wait para garantir que os elementos estão acionáveis, e já vem com tracing, interceptação de rede e isolamento paralelo embutidos — então exige bem menos código de espera manual. Selenium é um padrão W3C com o maior suporte de navegadores, linguagens e grid, e está consolidado em infraestrutura corporativa já existente. Escolha Playwright para um projeto novo focado em navegadores modernos; escolha Selenium quando precisar de suporte legado amplo ou tiver que se encaixar em um ecossistema Selenium já existente.
Você verifica códigos de status, schema da resposta, valores do body, headers e tratamento de erros para input inválido, além de limites de autenticação e autorização. As ferramentas costumam ser Postman ou Insomnia para exploração e RestAssured, Playwright APIRequest, requests ou supertest para suítes automatizadas. Testes de API são mais baratos e muito mais estáveis que testes de UI, então a maior parte da cobertura deveria estar ali.
A pirâmide diz que você deveria ter muitos unit tests rápidos, menos integration tests e bem poucos end-to-end tests, porque o custo e a flakiness aumentam conforme você sobe. Uma divisão comumente citada é cerca de 70/20/10, mas o número importa menos que o princípio: empurre cada verificação para o nível mais baixo capaz de pegar o bug. Testes E2E deveriam cobrir só as jornadas críticas do usuário, não regras de negócio.
Os testes rodam a cada pull request, geralmente divididos entre uma suíte de smoke rápida a cada commit e a regression completa no merge ou à noite. O pipeline provisiona um ambiente limpo, roda suítes em paralelo, publica relatórios e artefatos como screenshots e traces, e derruba o build em caso de regressão. A regra que faz isso funcionar é que um pipeline vermelho bloqueia o merge — senão, a suíte se degrada com o tempo.
Data-driven testing separa a lógica do teste dos dados do teste, então um teste roda contra vários conjuntos de input vindos de um CSV, JSON ou um provider parametrizado. Isso multiplica a cobertura sem multiplicar o código e transforma adicionar um caso novo em uma mudança de dados em vez de código. A armadilha é gerar falhas ilegíveis — sempre inclua os dados de input no nome do teste, para que uma falha diga qual caso quebrou.
Automatize verificações estáveis, repetitivas e de alto valor: suítes de regression, smoke tests, contratos de API e cenários pesados em dados. Não automatize UI que muda rápido, checagens pontuais, trabalho exploratório, julgamento visual e de usabilidade, ou qualquer coisa em que escrever e manter o teste custe mais do que rodá-lo manualmente. A pergunta decisiva é quantas vezes a verificação vai rodar antes de mudar.
Cada teste deveria criar os dados de que precisa e limpar depois de si mesmo, idealmente via chamadas de API ou seeding de banco de dados em vez da UI, porque isso é mais rápido e menos frágil. Fixtures de dados compartilhadas levam a dependência de ordem e falhas misteriosas. Para ambientes, contêineres ou instâncias efêmeras por execução do pipeline garantem isolamento; quando um ambiente compartilhado é inevitável, dê a todos os dados um namespace com um identificador de execução único.
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 QA Automation →