Perguntas de entrevista QA Manual

Qual é a diferença entre verification e validation?

Verification pergunta "estamos construindo o produto corretamente?" — ela confere o trabalho contra especificações e documentos de design, geralmente por meio de reviews e análise estática. Validation pergunta "estamos construindo o produto certo?" — ela verifica se o software pronto realmente resolve o problema do usuário, por meio de testes dinâmicos. Verification acontece durante todo o desenvolvimento; validation acontece contra requisitos e usuários reais.

O que é Equivalence Partitioning? Aplique isso a um campo "idade" que aceita de 1 a 120.

Equivalence Partitioning divide os dados de entrada em grupos nos quais se espera que cada valor se comporte da mesma forma, então testar um valor por grupo já é suficiente. Para um campo de idade de 1 a 120, as partições são: válido de 1 a 120, inválido abaixo (0 e negativos), inválido acima (121+) e tipo inválido (letras, símbolos, vazio). Isso dá quatro testes em vez de 120.

O que é Boundary Value Analysis? Dê um exemplo para um campo de 1 a 100.

Boundary Value Analysis mira nas bordas de cada partição, porque é ali que os erros off-by-one se concentram. Para um campo de 1 a 100 você testa 0, 1, 2 na borda inferior e 99, 100, 101 na borda superior. Quase sempre é usada junto com Equivalence Partitioning: as partições mostram quais grupos existem, as bordas mostram onde eles quebram.

Qual é a diferença entre Severity e Priority? Dê um exemplo de Severity alta com Priority baixa.

Severity descreve o impacto técnico do defeito no sistema; Priority descreve o quão urgente o negócio quer que ele seja corrigido. Elas são definidas por pessoas diferentes — Severity geralmente pelo tester, Priority pelo product owner ou gestor. Um crash em uma tela de exportação do admin raramente usada é Severity alta mas Priority baixa; um erro de digitação no nome da empresa na landing page é Severity baixa mas Priority alta.

Descreva o Bug Life Cycle. Quais status um bug pode ter?

Um defeito costuma passar por New → Assigned → Open (em andamento) → Fixed → Retest → Closed. Desfechos alternativos são Rejected (não é um defeito), Duplicate, Deferred (adiado para um release futuro) e Reopened, quando um retest mostra que a correção não funcionou. Os status exatos variam de equipe para equipe, mas o importante é que todo bug termine em um estado final com um motivo documentado.

O que são smoke, sanity e regression testing? Qual é a diferença entre eles?

Smoke testing é uma checagem rasa e ampla de que o build está estável o suficiente para sequer começar a testar — se o login está quebrado, o teste para por aí. Sanity testing é estreito e profundo: depois de uma correção específica, ele confirma que uma área funciona como esperado. Regression testing é amplo e repetido: confirma que mudanças novas não quebraram funcionalidades que já funcionavam, e é o principal candidato à automação.

O que é exploratory testing e em que ele difere do ad-hoc testing?

Exploratory testing significa projetar e executar testes ao mesmo tempo — o tester aprende o produto e usa o que descobre para decidir o que testar em seguida. Ele é estruturado: existe um charter, um time box e anotações. Ad-hoc testing não é estruturado nem documentado, guiado puramente pelo instinto. Exploratory testing é repetível e reportável; ad-hoc não.

Liste os campos obrigatórios de um bug report. Por que os passos para reproduzir são tão importantes?

Um bug report útil tem um resumo claro, ambiente (build, sistema operacional, navegador, dispositivo), pré-condições, passos para reproduzir, resultado real, resultado esperado, severity, priority e anexos como screenshots ou logs. Os passos para reproduzir importam mais porque um defeito que o desenvolvedor não consegue reproduzir costuma ser fechado como "não foi possível reproduzir" — o report perde todo o seu valor.

O que é um test plan e quais seções ele contém?

Um test plan descreve como o teste será conduzido em um projeto ou release. As seções típicas são escopo (o que será testado e o que não será), abordagem e níveis de teste, critérios de entrada e saída, ambientes e dados de teste, papéis e responsabilidades, cronograma, riscos com mitigação e entregáveis. É um documento de gestão — o objetivo é que qualquer pessoa saiba o que será testado, por quem e quando o teste é considerado concluído.

Como você testaria um formulário de login? Liste casos positivos e negativos.

Positivos: credenciais válidas fazem login e redirecionam corretamente, "lembrar de mim" mantém a sessão, a redefinição de senha funciona de ponta a ponta. Negativos: senha incorreta, usuário inexistente, campos vazios, payloads de SQL injection e XSS, espaços no início e no fim, sensibilidade a maiúsculas e minúsculas, input extremamente longo, bloqueio de conta após tentativas repetidas. Vale também checar aspectos não funcionais: a senha fica mascarada, o formulário funciona no celular, as credenciais são enviadas via HTTPS, e as mensagens de erro não revelam se o username existe.

Quais são os sete princípios de teste do ISTQB?

Testar mostra a presença de defeitos, mas não pode provar sua ausência; testes exaustivos são impossíveis; testar cedo economiza tempo e dinheiro; os defeitos se concentram em um número pequeno de módulos; o paradoxo do pesticida diz que testes repetidos param de encontrar bugs novos; testar depende do contexto; e a ausência de erros é uma falácia — um software sem defeitos conhecidos ainda pode ser inutilizável se resolver o problema errado.

O que é uma Decision Table e quando você a usa?

Uma Decision Table mapeia combinações de condições de entrada para as ações esperadas do sistema. Você a usa quando o comportamento depende de várias condições interagindo — por exemplo, um desconto que depende do tipo de cliente, do tamanho do pedido e de um código promocional. Ela deixa evidentes as combinações que faltam e vira casos de teste diretamente, por isso é a técnica padrão para regras de negócio complexas.

Qual é a diferença entre um test case e um checklist? Quando você usa cada um?

Um test case descreve passos precisos, dados de teste e um resultado esperado — é repetível por qualquer pessoa e serve bem para funcionalidades reguladas ou complexas. Um checklist é uma lista de pontos a verificar sem passos prescritos, confiando no julgamento do tester. Checklists são mais rápidos de escrever e manter e combinam com trabalho exploratório ou áreas estáveis e bem conhecidas; test cases combinam com onboarding, auditorias e features em que o fluxo exato importa.

Qual é a diferença entre functional e non-functional testing?

Functional testing verifica o que o sistema faz — se as features se comportam conforme os requisitos. Non-functional testing verifica quão bem ele faz isso: performance, carga, segurança, usabilidade, acessibilidade, compatibilidade e confiabilidade. Defeitos non-functional costumam ser mais caros de corrigir porque tendem a estar enraizados na arquitetura, e não em uma única linha de código.