Entrevistas e evolução na carreira de QA: de júnior a sênior e lead

· Algoritmos e guias, QA e automação, Qualidade de software

Neste guia você vai entender o que normalmente se espera de uma pessoa de QA em cada nível de carreira, como mostrar o seu impacto sem inflar resultados, quais são os formatos de entrevista mais comuns, como responder perguntas comportamentais com o método STAR e como usar o Lab do AppsQuality para treinar na prática. No fim, falamos de algo que muita gente esquece: pedir feedback e montar um plano de desenvolvimento.

Trabalho com qualidade de software desde 2010 e já estive dos dois lados da mesa: sendo entrevistada e entrevistando. O que trago aqui é uma visão prática, não uma regra universal. Cada empresa define seus níveis de um jeito, então use este texto como mapa, não como contrato.

O que se espera em cada nível

A diferença entre os níveis raramente está só na ferramenta que você domina. Ela está principalmente no tamanho do problema que você consegue resolver sozinha e em quanto você influencia as pessoas ao redor.

Júnior

Executa bem tarefas definidas: escreve casos de teste a partir de critérios de aceite, roda testes manuais com atenção, registra bugs claros e reproduzíveis e começa a automatizar cenários simples. Precisa de orientação para priorizar e para entender o contexto de negócio. O que mais conta aqui é curiosidade, organização e vontade de aprender.

Pleno

Tem autonomia dentro de uma squad ou funcionalidade. Desenha a estratégia de teste de uma entrega, escolhe o que automatizar e em que camada (unidade, API, interface), mantém testes estáveis e participa ativamente do refinamento, questionando requisitos ambíguos antes do código existir. Começa a ajudar quem está chegando.

Sênior

Olha para o produto e para o processo, não só para a tarefa. Identifica riscos que ninguém mapeou, propõe melhorias na arquitetura de testes, reduz testes instáveis, conversa de igual para igual com desenvolvimento e produto sobre trade-offs e sabe dizer “isso não precisa ser testado assim” com argumentos. Mentora pessoas e deixa práticas que continuam funcionando quando ela sai do projeto.

Lead, especialista ou SDET

Aqui o caminho se divide, e vale saber qual te atrai:

  • Lead de QA: foco em pessoas e estratégia. Define padrões entre times, ajuda na contratação, acompanha o crescimento do time e representa qualidade em decisões de produto.
  • Especialista: profundidade técnica em um tema, como performance, segurança, acessibilidade ou testes de API. É a referência que outros times consultam.
  • SDET (engenharia de software em teste): perfil fortemente de código. Constrói frameworks, ferramentas internas, integra testes ao pipeline e escreve código com o mesmo rigor de quem desenvolve o produto.

Nenhum desses caminhos é “acima” do outro. Muita gente sênior cresce sem nunca liderar pessoas, e tudo bem.

Como mostrar impacto sem inventar números

É comum ver currículos com frases como “reduzi bugs em 80%”. Se você não mediu isso de verdade, não escreva. Entrevistadores experientes perguntam “como você mediu?”, e uma resposta vaga derruba a credibilidade do resto. Impacto honesto pode ser descrito de várias formas:

  • Antes e depois qualitativo: “a regressão era manual e bloqueava a release; automatizei o fluxo principal e passamos a rodar a cada pull request”.
  • Problemas evitados: “identifiquei no refinamento que a regra de desconto não tratava cupons expirados; o cenário entrou no critério de aceite”.
  • Mudança de processo: “propus um checklist de testes exploratórios que o time adotou nas sprints seguintes”.
  • Pessoas: “acompanhei a entrada de duas pessoas no time e montei o material de onboarding de automação”.
  • Números reais, quando existirem: se o pipeline mostra o tempo de execução antes e depois, use. Só cite o que você consegue explicar de onde veio.

Uma dica simples: mantenha um “diário de conquistas”, um arquivo onde você anota toda semana o que resolveu e por que importou. Na hora da entrevista ou da avaliação, você não depende da memória.

Tipos de entrevista em QA

Entrevista técnica conversada

Perguntas sobre conceitos e experiência: pirâmide de testes, diferença entre teste de unidade, integração e ponta a ponta, como lidar com testes instáveis, como testar uma API, o que é um bom relatório de bug. Responda sempre conectando o conceito a uma situação que você viveu.

Live coding

Você automatiza algo ao vivo: um login na interface, uma chamada a uma API, às vezes um exercício de lógica. O que se avalia não é só se funciona, mas como você pensa. Fale em voz alta, comece pelo caminho feliz, depois trate erros, escolha seletores estáveis e explique o que faria com mais tempo. Travou? Diga o que está tentando descobrir; silêncio total é o pior cenário.

Caso de teste ou desafio de cenário

O clássico “como você testaria isto?”, seja um campo de CPF, um carrinho de compras ou um elevador. Antes de listar cenários, faça perguntas: quem usa, quais regras existem, o que acontece em caso de erro. Depois organize por categorias, como funcional, limites, entradas inválidas, segurança, acessibilidade e desempenho. Mostrar priorização vale mais do que uma lista enorme.

Funcionalidade: Aplicar cupom no carrinho

Cenário: Cupom válido reduz o total
  Dado que tenho um produto no carrinho
  Quando aplico o cupom "BEMVINDO"
  Então o desconto aparece no resumo
  E o total é recalculado

Cenário: Cupom expirado é recusado com mensagem clara
  Dado que o cupom "VERAO" está expirado
  Quando aplico o cupom "VERAO"
  Então vejo a mensagem "Cupom expirado"
  E o total não muda

Entrevista comportamental

Perguntas sobre como você age em situações reais: conflito, prazo apertado, erro em produção, discordância com uma decisão. Quanto mais sênior a vaga, mais peso essa etapa tem.

Perguntas comuns e o método STAR

Algumas perguntas aparecem com frequência em processos de QA:

  • Conte sobre um bug importante que você encontrou. Como chegou nele?
  • Um bug seu escapou para produção. O que aconteceu e o que mudou depois?
  • Como você decide o que automatizar e o que não automatizar?
  • Como você lida quando o desenvolvimento diz que “não é bug, é feature”?
  • O prazo não permite testar tudo. Como você prioriza?
  • Conte uma melhoria de processo que você propôs.

Para as comportamentais, o método STAR ajuda a não se perder: Situação (o contexto, em uma ou duas frases), Tarefa (qual era a sua responsabilidade), Ação (o que você fez, não o time) e Resultado (o que mudou e o que aprendeu). Um rascunho simples:

Situação: a regressão do checkout era manual e atrasava as entregas.
Tarefa:   eu era responsável pela qualidade desse fluxo.
Ação:     mapeei os cenários críticos, automatizei via API o que
          não precisava de tela e deixei na interface só o fluxo principal.
Resultado: a suíte passou a rodar no pipeline a cada mudança e o time
          ganhou confiança para entregar com mais frequência.
Aprendizado: começar pela API deixou os testes mais rápidos e estáveis.

Prepare de quatro a seis histórias reais que cubram temas diferentes: um bug difícil, um conflito, um erro seu, uma melhoria, uma situação de prazo e uma de aprendizado rápido. Com elas, você consegue responder a maioria das variações.

Como se preparar usando o Lab

Ler sobre testes ajuda, mas o que dá segurança em live coding é ter praticado. O Lab do AppsQuality foi pensado para isso: uma loja de prática com cinco versões de front (HTML, React, Vue, um front legado e um com Shadow DOM), além de uma página de elementos difíceis. Algumas ideias de treino:

  • Automatize o mesmo fluxo de compra em fronts diferentes e compare o que muda nos seletores.
  • Encare a página de elementos difíceis com um cronômetro, simulando a pressão de uma entrevista.
  • Use a API de prática, que tem documentação OpenAPI e usuários como standard_user e locked_user, para escrever testes de caminho feliz e de erro.
  • Escreva casos de teste para uma funcionalidade da loja antes de automatizar, treinando o formato “como você testaria isto?”.
  • Grave sua tela explicando o que faz. Assistir depois mostra vícios de comunicação que você não percebe na hora.

Se quiser, publique esse projeto em um repositório público com um README explicando suas decisões. Isso vira assunto concreto na entrevista.

Pedir feedback e montar um plano de desenvolvimento

Depois de uma entrevista, mesmo com resposta negativa, vale pedir um retorno de forma educada e específica: “Em que ponto eu poderia ter ido melhor na etapa técnica?”. Nem toda empresa responde, mas quando responde, é ouro.

Dentro da empresa onde você já trabalha, o caminho para subir de nível costuma ser mais claro se você perguntar diretamente à sua liderança: “O que falta para eu ser considerada no próximo nível?”. Com a resposta, monte um plano simples:

  • Onde estou: pontos fortes e lacunas, com exemplos.
  • Onde quero chegar: nível ou trilha (lead, especialista, SDET).
  • Ações: poucas e concretas, como liderar a estratégia de teste da próxima entrega ou estudar testes de contrato.
  • Evidências: o que vai mostrar que você chegou lá.
  • Revisão: combine conversas periódicas para acompanhar.

Crescer em QA é menos sobre colecionar ferramentas e mais sobre ampliar o alcance das suas decisões. Quem entende isso se prepara melhor para entrevistas e para a carreira como um todo.

Próximos passos