Perguntas de entrevista de emprego: 10 respostas práticas sobre teste manual

Comece com estas dez perguntas e adapte as respostas de exemplo a trabalhos que você possa explicar com honestidade. Para perguntas de entrevista de emprego sobre teste de software, relacione o requisito, a entrada, o resultado esperado e o motivo da sua escolha.

1. Como você testaria um campo de quantidade?

Exemplo de resposta: “Eu confirmaria os valores permitidos e o comportamento ao enviar; depois, testaria quantidades aceitas, rejeitadas e os limites. Para um intervalo de inteiros de 1 a 10, incluiria 0, 1, 10 e 11, com resultados esperados explícitos.”

2. Qual é a diferença entre particionamento de equivalência e análise de valor-limite?

“O particionamento agrupa entradas que devem receber tratamento semelhante; a análise de valor-limite verifica os extremos de partições ordenadas. Para a quantidade, escolheria 5 como valor válido comum e, depois, verificaria onde a aceitação muda em torno de 1 e 10.”

3. O que deve constar em um caso de teste?

“Preciso de detalhes suficientes para que outra pessoa que testa consiga repetir a verificação. Para o checkout, especificaria o carrinho inicial, o estado da conta, a quantidade, a ação e o total esperado do pedido; depois, registraria o resultado observado em relação à compilação testada.”

4. Como você testaria regras de negócio que interagem entre si?

“Eu listaria as condições e as ações esperadas antes de escolher as combinações. Se o checkout exigir estoque disponível e pagamento aprovado, cobriria as duas condições em conjunto, incluindo um item disponível com pagamento recusado.”

5. Quando o estado é importante?

“Eu testaria a mesma ação em diferentes estados iniciais. Enviar um pedido a partir de um carrinho pronto pode ser válido; enviá-lo novamente enquanto o pagamento está pendente deve seguir uma regra acordada para envios duplicados.”

6. O que você testa depois que um defeito é corrigido?

“O teste de confirmação verifica a correção; o teste de regressão verifica possíveis efeitos adversos em outras áreas. Depois de corrigir a rejeição da quantidade 10, repetiria essa falha e escolheria verificações próximas de quantidade e checkout com base na alteração.”

7. Como você relataria uma falha intermitente?

“Eu registraria as condições, as tentativas, os horários e as evidências. Se o checkout falhasse duas vezes em dez tentativas, relataria essa observação, preservaria as sequências que funcionaram e as que falharam e evitaria apresentar uma causa suspeita como comprovada.”

8. Qual é a diferença entre gravidade e prioridade?

“A gravidade diz respeito ao impacto; a prioridade, ao momento de corrigir. Eu descreveria o fluxo de compra afetado e a alternativa disponível e, depois, conversaria com a equipe sobre o cronograma, em vez de tratar minha avaliação inicial como definitiva.”

9. E se o requisito não estiver claro?

“Eu faria uma pergunta concreta: inserir 2.0 conta como uma quantidade inteira? Registraria a interpretação acordada e a usaria nas expectativas dos testes, em vez de escolher silenciosamente o comportamento que prefiro.”

10. E se houver pouco tempo?

“Eu começaria pelas falhas que poderiam impedir compras ou gerar cobranças incorretas e, em seguida, explicaria o que ainda não foi testado. Minha atualização identificaria a compilação testada, os resultados, as lacunas e a recomendação, para que a pessoa responsável pelo lançamento possa decidir.”

Transforme o intervalo em comportamentos observáveis antes de citar técnicas. Requisito de exemplo: um campo obrigatório de quantidade aceita números inteiros de 1 a 10, inclusive. Um envio válido adiciona exatamente essa quantidade ao carrinho. Um envio inválido exibe uma mensagem de validação da quantidade e não altera o carrinho. Considere que há estoque suficiente e que o carrinho começa vazio em cada caso.

Para este exercício, combine que entradas em branco, números decimais como 1.5 e textos como “dois” serão rejeitados. A aceitação de representações como 2.0, zeros à esquerda ou espaços em volta exige uma regra de formatação separada. Não trate silenciosamente essas escolhas como parte do requisito do intervalo de números inteiros.

Use três partições numéricas: números inteiros abaixo de 1, números inteiros de 1 a 10 e números inteiros acima de 10. Escolha representantes e, em seguida, concentre-se nos limites de aceitação. A tabela combina um valor interno, verificações de limites e verificações do formato de entrada.

Exemplo de resposta falada: “Eu esvaziaria o carrinho, inseriria 10, enviaria uma vez e verificaria se o carrinho contém 10 itens. Depois, esvaziaria o carrinho e tentaria 11, esperando uma validação e nenhuma alteração no carrinho. Isso verifica o limite superior de aceitação sem confundir um valor exibido com uma atualização bem-sucedida.”

Se a interface impedir a digitação de letras, registre esse comportamento e teste os caminhos de interação disponíveis; não afirme ter enviado uma entrada que não conseguiu inserir. Se a pessoa entrevistadora mudar o estoque para oito itens, pare e esclareça como a regra de estoque interage com o limite de quantidade.

A terminologia segue o programa CTFL v4.0.1 da ISTQB, elaborado pela equipe responsável pelo programa Foundation Level, reconhecendo aqui a ISTQB e os autores do programa como fonte e titulares dos direitos autorais. Os requisitos e as respostas elaborados neste guia são exemplos de entrevista.

Separe as condições que determinam um resultado da sequência que leva até ele. Premissas de exemplo: o carrinho contém um item válido; o estoque é verificado antes do pagamento; o pagamento só é solicitado quando há estoque disponível; o pedido só é confirmado depois da aprovação do pagamento. Um pagamento recusado deixa o carrinho disponível para outra tentativa.

Em uma tabela de decisão compacta, use “não solicitado” quando o pagamento não puder ocorrer. Isso evita fingir que uma combinação impossível precisa de um resultado de teste.

Em seguida, descreva os estados: Pronto, Pagamento pendente, Pagamento falhou e Confirmado. Percorra Pronto → Pagamento pendente → Pagamento falhou → Pagamento pendente → Confirmado. Em cada etapa, verifique o status visível e se existe um pedido.

Um segundo clique durante o estado Pagamento pendente exige uma regra própria. Considere que o comportamento acordado é ignorar envios duplicados enquanto o progresso é exibido. O resultado esperado é uma tentativa de pagamento e um único pedido eventual, não dois. Explique quais evidências você precisaria verificar para confirmar esse resultado no ambiente de teste fornecido; um botão desativado, por si só, não comprova o que aconteceu nos sistemas seguintes.

Ao responder a perguntas de entrevista sobre teste de software, deixe clara a dependência: uma tabela de condições organiza as escolhas, enquanto a sequência de estados revela comportamentos que dependem de eventos anteriores. Peça à pessoa entrevistadora que confirme as expectativas para novas tentativas e envios duplicados antes de considerar um resultado como defeito.

Primeiro, descreva a falha original; depois, explique o possível alcance da alteração. Exemplo: a compilação Q-17 rejeita a quantidade 10, embora o requisito a permita. A compilação Q-18 contém a correção. Comece repetindo na Q-18 as etapas registradas, com as mesmas condições iniciais, e verificando o resultado no carrinho, não apenas a ausência de uma mensagem de erro.

Em seguida, monte uma seleção de regressão direcionada:

• Verifique 1 e 10 como limites aceitos e 0 e 11 como valores vizinhos rejeitados.
• Verifique 5 para detectar uma correção que, por engano, só aceita um dos limites.
• Altere de 9 para 10 uma linha já existente no carrinho e verifique a quantidade e o total.
• Remova a linha e adicione-a novamente para verificar um fluxo relacionado do carrinho.
• Conclua o fluxo de checkout acordado com a quantidade 10 e verifique a quantidade do pedido.

Se a pessoa responsável pelo desenvolvimento alterou um validador compartilhado com a edição do carrinho, esse fluxo merece atenção. Se a alteração estiver isolada, converse sobre uma seleção menor, considerando ainda o impacto da falha. Pergunte quais componentes foram alterados em vez de adivinhar pelo título do chamado.

Registre o resultado de cada verificação e associe-o à correção e à compilação. Se a quantidade 10 agora funcionar, mas a 11 também for aceita, relate a nova falha; o desaparecimento do sintoma original não é motivo suficiente para encerrar todos os testes. Termine sua resposta indicando o escopo restante e as verificações bloqueadas.

Apresente à pessoa entrevistadora um relatório que ela poderia entregar a alguém da equipe. Relatório de defeito de exemplo: o requisito de quantidade continua sendo de 1 a 10, inclusive, mas o ambiente de teste rejeita o limite superior. Os identificadores e as observações abaixo pertencem a este exemplo.

ID: QTY-24
Título: A quantidade 10 é rejeitada ao adicionar um item em estoque
Observado: 2026-11-05
Relator: Alex, pessoa responsável por testes manuais
Status: Aberto
Compilação: Q-17
Ambiente: Loja de teste QA, navegador para computador; versão exata anexada
Referência: Requisito QTY-01; caso de teste QTY-BOUNDARY-10
Pré-condições: Carrinho vazio; conta de teste autenticada; estoque do item é 20
Dados: Quantidade 10; item TEST-MUG

Etapas:
1. Abra a página do produto TEST-MUG.
2. Insira 10 em Quantidade.
3. Selecione Adicionar ao carrinho uma vez.
4. Verifique a mensagem de validação e o carrinho.

Esperado: Nenhum erro de validação da quantidade; o carrinho contém 10 unidades de TEST-MUG.
Obtido: Aparece um erro de validação da quantidade; o carrinho permanece vazio.
Reprodução: 3 falhas em 3 tentativas, esvaziando o carrinho a cada vez.
Impacto: Clientes não conseguem adicionar de uma só vez a quantidade máxima permitida.
Alternativa observada: Adicionar 5 duas vezes resulta em uma quantidade de 10 no carrinho.
Gravidade proposta: Média segundo a escala de impacto desta equipe.
Prioridade proposta: Avaliar na triagem antes da promoção de compras em grandes quantidades.
Evidências: Captura de tela da mensagem; gravação da sessão; horários anexados.

Em um relatório real, substitua o texto provisório do ambiente e anexe as evidências mencionadas. Mantenha os dados da conta e as gravações de acordo com as regras de tratamento da equipe. Descreva separadamente uma possível causa: “Possível problema na comparação do limite superior” é uma hipótese, não um resultado observado.

Discuta o impacto e o cronograma com contexto. A alternativa pode reduzir a interrupção imediata, enquanto uma promoção próxima pode tornar a correção mais urgente. Outra equipe pode usar rótulos de avaliação diferentes. Primeiro, explique a consequência para os clientes e o prazo; depois, associe-os à escala local. Se a pessoa responsável pelo desenvolvimento não conseguir reproduzir o defeito, compare em conjunto a compilação, os dados, a conta e a sequência antes de alterar o status do chamado.

Transforme a incerteza em um pedido de decisão específico. Exemplo: “O chamado diz que os clientes podem tentar pagar novamente, mas não diz se a reserva do carrinho continua válida após uma recusa. A nova tentativa deve verificar o estoque de novo?” Registre a resposta ao lado do requisito e atualize os resultados esperados. Até lá, marque a expectativa como não resolvida, em vez de contar a verificação como aprovada.

Diante de um prazo, proponha uma ordem relacionada ao dano provável e à funcionalidade afetada. Para o exemplo de checkout, comece pela criação do pedido, falha no pagamento, envio duplicado e totais das quantidades. Depois, cubra detalhes de apresentação de menor impacto, se houver tempo. Se uma dependência de configuração impedir uma verificação de alto risco, informe o bloqueio enquanto executa testes independentes que ainda sejam úteis.

Faça uma breve atualização sobre o lançamento com quatro partes: o que foi testado, o que aconteceu, o que não se sabe e qual decisão é necessária.

Exemplo: “Na Q-18, as verificações de quantidades aceitas e rejeitadas foram aprovadas, e um checkout com pagamento aprovado criou o pedido esperado. A nova tentativa após uma recusa está bloqueada porque a configuração de pagamento de teste não está disponível. Recomendo restabelecer essa configuração e concluir a verificação da nova tentativa antes do lançamento. Se o lançamento acontecer agora, o fluxo de nova tentativa continuará sendo um risco explícito que a pessoa responsável pelo lançamento deverá aceitar.”

Evite transformar “nenhuma falha nas verificações executadas” em “o sistema não tem defeitos”. Diferencie verificações aprovadas, reprovadas, bloqueadas e não executadas. Ao responder a perguntas de entrevista sobre testes e divergências, explique como compararia as evidências com alguém da equipe de desenvolvimento e levaria comportamentos de negócio ainda não resolvidos à pessoa responsável pela decisão. Termine com uma próxima ação prática, como providenciar a configuração ausente ou esclarecer a regra para novas tentativas.

Use o SayNow AI para praticar como explicar suas decisões de teste com clareza. A entrevista simulada com IA oferece uma conversa por voz com perguntas e perguntas de acompanhamento, seguida de uma pontuação e sugestões sobre fluência, estrutura do conteúdo, adequação ao cenário e alcance dos objetivos.

Prepare um exemplo deste guia com os aspectos técnicos verificados antes de abrir o cenário de entrevista de emprego. Nas respostas faladas, comece pela decisão, explique o requisito relevante e dê o resultado esperado. Use o método STAR para uma experiência passada, como a investigação de um defeito contestado. Quando a conversa explorar um ponto vago, responda diretamente em vez de recomeçar toda a sua história.

Depois, escolha uma mudança com base no feedback: apresente o resultado esperado mais cedo, encurte o contexto ou deixe mais clara sua ação individual. Pratique novamente tendo essa mudança em mente. O SayNow AI não verifica a correção técnica; confira seu raciocínio de teste separadamente, comparando-o com o requisito e conversando com alguém que conheça o assunto. Mantenha a pontuação de fala em seu devido papel: o de feedback para o ensaio.

Pratique sua explicação para a entrevista no cenário de entrevista de emprego.

Faça um último ensaio com uma condição alterada em vez de memorizar cada frase. Peça a alguém que faça uma simulação para mudar o limite de quantidade, retirar a alternativa ou perguntar quais evidências sustentam uma falha relatada. Sua tarefa é ajustar a expectativa de teste e explicar a consequência.

Use esta lista para revisar a resposta:

• A pessoa que ouve consegue identificar o requisito e as premissas?
• Você forneceu dados de teste concretos e um resultado esperado observável?
• Alguém consegue repetir seu relatório de defeito a partir das condições iniciais descritas?
• Você explicou por que os testes escolhidos são importantes após a alteração?
• Você separou os resultados observados, as causas suspeitas e as questões não resolvidas?
• Você indicou a próxima ação e quem precisa da informação?

Para perguntas de entrevista de emprego para vagas de teste de software, prepare uma história de projeto junto com os exemplos técnicos. Descreva sua própria contribuição e o resultado que realmente observou. Use os guias relacionados sobre entrevistas comportamentais e o método STAR para manter a história focada.

Boas respostas a perguntas de entrevista de emprego sobre teste manual relacionam um requisito claro a entradas escolhidas com intenção, resultados esperados e uma próxima decisão justificável. Ensaie o exemplo da quantidade, adapte o relatório de defeito a uma experiência que possa discutir com honestidade e explique o risco que permanece depois das verificações escolhidas.