Engenheiro QA Perguntas de Entrevista & Respostas

Resposta modelo

Durante os testes de regressão de uma atualização no sistema de pagamentos, percebi que a conversão de moeda estava arredondando incorretamente em transações abaixo de $1. O conjunto de testes automatizados passava porque todos os casos de teste usavam valores acima de $10. Descobri o problema com testes exploratórios: testei sistematicamente os valores de contorno próximos a zero e constatei que transações de $0,99 ou menos estavam sendo arredondadas para $0,00 após a conversão. A causa raiz era o uso de divisão inteira em vez de divisão de ponto flutuante na função de conversão. Se tivesse chegado à produção, afetaria cerca de 15% das nossas micro-transações, aproximadamente 8.000 transações diárias, representando uma perda estimada de $3.200 por dia. Após a correção, adicionei 20 casos de teste de valor de contorno ao conjunto automatizado, cobrindo valores pequenos, valores zero e valores máximos em cada moeda suportada.

Resposta modelo

Nossa suíte de testes de ponta a ponta levava 3 horas para executar e bloqueava cada merge de pull request. Os desenvolvedores ou pulavam os testes ou agrupavam os PRs para evitar a espera. Analisei a suíte e identifiquei três problemas: os testes rodavam em sequência em vez de em paralelo, 30% eram redundantes (cobrindo os mesmos caminhos de código) e testes instáveis causavam falha em 40% das execuções logo na primeira tentativa. Containerizei o ambiente de testes para que rodassem em paralelo com 8 workers, eliminei 45 testes redundantes e coloquei em quarentena 12 testes instáveis enquanto corrigia as causas raiz, principalmente condições de corrida e dados de teste fixos no código. O tempo de execução caiu de 3 horas para 25 minutos, a instabilidade passou de 40% para menos de 2%, e a frequência de merge de PRs dos desenvolvedores dobrou. O time passou a confiar nos testes como uma rede de segurança genuína.

Resposta modelo

Identifiquei que nosso recurso de busca retornava resultados em ordem diferente quando a mesma consulta era executada duas vezes. O desenvolvedor disse que era 'intencional' porque os resultados tinham pontuações de relevância iguais e o banco de dados não garantia ordem em caso de empate. Argumentei que era um bug de UX, mesmo que tecnicamente correto: os usuários esperam resultados consistentes. Mostrei gravações de sessão de usuários confusos com os resultados mudando entre buscas. Chegamos a um acordo: adicionamos uma ordenação secundária por data de criação para resultados com relevância igual, garantindo ordem determinística sem alterar o algoritmo de relevância. Aprendi que debates de 'bug versus funcionalidade' se resolvem melhor analisando o impacto no usuário, não a correção técnica. Se os usuários ficam confusos, algo precisa mudar, independentemente do que diz a especificação.

Resposta modelo

Quando entrei na equipe, os desenvolvedores escreviam testes unitários mínimos e dependiam totalmente do QA para encontrar bugs. Em vez de dar palestras sobre cobertura de testes, comecei a fazer pair programming de testes com os desenvolvedores durante revisões de código. Dizia: 'Assim é como eu testaria esta função. Quer adicionar esses casos?' Após algumas sessões, os desenvolvedores passaram a escrever seus próprios testes. Também criei um 'painel de bugs': um dashboard mostrando onde os bugs eram encontrados (teste unitário, teste de integração, QA, produção). Em 3 meses, os dados mostravam claramente que bugs encontrados mais tarde custavam exponencialmente mais para corrigir. A quantidade de bugs em produção caiu 55% à medida que os desenvolvedores internalizaram a mentalidade de shift-left. O segredo foi tornar o processo colaborativo: me posicionei como um facilitador de qualidade, não como fiscal de bugs.

Resposta modelo

A pirâmide de testes tem três camadas: testes unitários na base (rápidos, isolados, em grande quantidade), testes de integração no meio (testam interações entre componentes, em quantidade moderada) e testes de ponta a ponta no topo (lentos, sistema completo, em pequena quantidade). Na prática, busco uma proporção aproximada de 70% unitários, 20% de integração e 10% E2E. Os testes unitários cobrem funções individuais e casos extremos: executam em milissegundos e fornecem feedback imediato. Os testes de integração verificam se os componentes funcionam juntos: endpoints de API retornam respostas corretas, consultas ao banco de dados funcionam com um schema real, consumidores de mensagens processam mensagens corretamente. Os testes E2E cobrem os fluxos críticos do usuário: cadastro, compra, fluxo principal. Mantenho estes ao mínimo porque são lentos, instáveis e caros de manter. O antipadrão que mais combato é a 'pirâmide invertida', onde equipes têm 500 testes E2E e 20 testes unitários. Isso resulta em execuções de 3 horas, instabilidade constante e desenvolvedores que ignoram as falhas.

Resposta modelo

Testaria em quatro níveis. Testes de contrato: validar que os schemas de requisição e resposta correspondem à especificação OpenAPI. Isso detecta mudanças que quebram compatibilidade antes de afetar os consumidores. Testes funcionais: para cada endpoint, testar caminhos de sucesso, erros de validação (campos ausentes, tipos incorretos, valores de contorno), autenticação e autorização (acesso não autorizado, papel incorreto) e casos extremos (coleções vazias, tamanhos máximos de payload, caracteres especiais). Testes de integração: verificar se a API interage corretamente com suas dependências, como operações no banco de dados, chamadas a serviços externos e publicação em filas de mensagens. Use um banco de dados real com dados de teste, mas simule serviços externos na camada de rede. Testes de desempenho: medir o tempo de resposta sob carga normal (linha de base), teste de estresse para encontrar o ponto de ruptura e teste de duração para detectar vazamentos de memória em períodos prolongados. Automatizaria tudo isso no pipeline de CI: testes de contrato e funcionais em cada PR, testes de integração no merge para main e testes de desempenho todas as noites. Usaria Postman/Newman para testes funcionais, k6 ou JMeter para desempenho e Pact para testes de contrato.

Resposta modelo

Um stub retorna respostas pré-configuradas: substitui uma dependência por uma versão simplificada que fornece saída previsível. Uso stubs quando preciso que uma dependência retorne dados específicos para meu teste, mas não me importo com como ela é chamada. Um mock é um stub que também registra como foi chamado e permite verificar interações: esse método foi chamado com esses argumentos? Uso mocks quando o comportamento que estou testando é a interação em si, por exemplo, verificar se um serviço envia um e-mail após o cadastro e não o conteúdo do e-mail. Um fake é uma implementação funcional com atalhos: um banco de dados em memória em vez de PostgreSQL, um sistema de arquivos local em vez de S3. Uso fakes quando preciso de comportamento realista, mas não posso usar a dependência real nos testes. Minha regra geral: prefiro fakes para armazenamento de dados (mais realista), stubs para APIs externas (previsível) e mocks com parcimônia para verificação de interações. O excesso de mocks é um antipadrão comum: se você simula tudo, está testando os mocks, não o código.

Resposta modelo

Testes instáveis são um problema sério: corroem a confiança na suíte de testes e ensinam os desenvolvedores a ignorar falhas. Minha abordagem tem quatro etapas. Primeiro, identificar os testes instáveis de forma sistemática: marco os testes que falham de forma intermitente e acompanho a taxa de falha. Qualquer teste que falhe mais de uma vez sem alteração de código é considerado instável. Segundo, quarentena: mover os testes instáveis para uma suíte separada que executa, mas não bloqueia implantações. Isso preserva a relação sinal-ruído da suíte principal. Terceiro, corrigir as causas raiz. As fontes mais comuns são problemas de temporização (adicionar esperas explícitas para operações assíncronas em vez de sleep), estado compartilhado (garantir isolamento dos testes com setup/teardown adequados), dependências externas (simular ou containerizar) e dependência de ordem (testes que passam individualmente, mas falham quando executados após outro). Quarto, prevenir novos testes instáveis: adicionar detecção de retry ao CI. Se um teste passa na segunda tentativa, marcá-lo como potencialmente instável e criar um ticket. Tratar testes instáveis com a mesma urgência que bugs em produção mantém a suíte confiável.

Resposta modelo

Não argumentaria por 'tempo de testes' de forma abstrata: tornaria o risco concreto. Perguntaria: 'Qual é o custo se entregarmos um bug crítico para nossos 50 mil usuários?' Então apresentaria um plano de testes baseado em risco. Como não consigo testar tudo, identificaria as áreas de maior risco: código novo, código alterado e fluxos críticos do usuário (pagamento, autenticação, integridade de dados). Proporia um plano de testes focado de 2 dias cobrindo essas áreas, com testes de regressão automatizados rodando em paralelo. Também apresentaria a alternativa: podemos lançar sem testes, mas precisamos de um plano de rollback rápido e alguém de plantão para responder a incidentes. Tornar o tradeoff explícito, 'economizamos 2 dias, mas aceitamos o risco X', geralmente muda a conversa. Se o gerente insistir em zero testes, documentaria a decisão e os riscos por escrito. Na minha experiência, quando você quantifica o risco claramente, a resposta quase sempre é 'vamos encontrar esses 2 dias'.

Resposta modelo

Primeiro, avaliaria a gravidade e o impacto. Se afeta funcionalidades essenciais (perda de dados, segurança, pagamento), escalaria imediatamente e recomendaria adiar o lançamento, sem exceções. Se for um problema de interface ou afeta um fluxo secundário, avaliaria se podemos lançar com um problema conhecido e corrigir em até 24 horas. Comunicaria com clareza ao responsável pelo lançamento e ao dono do produto: aqui está o bug, aqui está o impacto, aqui estão as opções. Opção A: adiar o lançamento, corrigir o bug e executar regressão. Opção B: lançar sem o recurso afetado (desativá-lo via feature flag). Opção C: lançar com um problema conhecido e fazer o hotfix no dia seguinte. Apresentaria minha recomendação, mas deixaria os responsáveis pelo negócio decidirem. O que não faria: ignorar, minimizar ou tentar uma correção apressada sem testes. Toda 'correção rápida' feita 1 hora antes de um lançamento que já vi introduziu um segundo bug, pior do que o primeiro.

Resposta modelo

Começaria testando o que consigo inferir pelo próprio recurso: usando-o como um usuário faria e documentando minhas premissas. Criaria um plano de testes com base nessas premissas e o compartilharia com o gerente de produto e o desenvolvedor: 'Aqui está o que planejo testar. Estas são as premissas que estou adotando. Estão corretas? O que estou deixando de fora?' Essa abordagem é mais rápida do que aguardar requisitos perfeitos e frequentemente revela lacunas que o gerente ainda não havia considerado. Para cada lacuna, faria perguntas específicas: 'O que acontece quando o usuário digita mais de 500 caracteres? Qual deve ser a mensagem de erro? O formulário deve preservar os dados em caso de falha na validação?' Também consultaria recursos semelhantes do produto para identificar padrões de consistência. O objetivo é transformar requisitos vagos em critérios de aceitação testáveis por meio de conversas. Uma especificação perfeita pode nunca chegar.

Resposta modelo

Trataria como uma investigação genuína, não como um confronto. Primeiro, verificaria a asserção do teste em relação aos requisitos atuais: o teste está verificando um comportamento desatualizado? Se o recurso mudou intencionalmente e o teste não foi atualizado, isso é uma lacuna de processo. Atualizaria o teste para corresponder ao novo comportamento. Segundo, verificaria se a mudança foi intencional consultando o histórico de commits, a descrição do pull request e os tickets vinculados. Se houver uma decisão documentada de mudar o comportamento, o teste deve ser atualizado. Se não houver documentação, perguntaria ao desenvolvedor e ao gerente de produto para confirmar. Às vezes, os desenvolvedores alteram o comportamento inadvertidamente durante uma refatoração, e o teste 'errado' na verdade detectou uma regressão real. De qualquer forma, a conversa produz um bom resultado: ou atualizamos o teste (e a mudança fica documentada) ou descobrimos uma regressão não intencional. Também ressaltaria a melhoria de processo: mudanças de comportamento devem gerar atualizações de testes no mesmo PR.