Uma entrevista de QA Manual avalia seu domínio da teoria de testes, das técnicas de design de testes e sua capacidade de escrever bug reports sobre os quais um desenvolvedor realmente consiga agir. Abaixo estão as perguntas mais cobradas em nível Junior e Middle, cada uma com uma resposta modelo. Junior: teoria básica, definições e casos práticos simples.
Verification pergunta se construímos o produto corretamente — se ele condiz com a especificação, o design, os requisitos combinados. Validation pergunta se construímos o produto certo — se ele realmente resolve o problema do usuário. Uma feature pode passar totalmente na verification e ainda assim falhar na validation, e é assim que uma equipe lança algo que bate com a spec e que ninguém quer.
Você divide o input em classes nas quais cada valor deveria se comportar igual, e então testa um valor de cada uma em vez de todos. Aqui isso dá três partições: menos de 18, de 18 a 65, e mais de 65, além das classes inválidas — letras, vazio, negativo. O ponto é ter cobertura sem redundância: se 30 passa, 31 não te diz nada de novo.
Os bugs se concentram nas bordas de um intervalo, porque é ali que vivem os erros off-by-one e os operadores de comparação errados. Para um campo que aceita de 18 a 65 você testa 17, 18, 19 e 64, 65, 66. O partitioning te diz quais intervalos existem; a boundary analysis te diz onde dentro deles os defeitos de fato estão.
Um report útil tem um título que diz o que está quebrado, passos de reprodução exatos, resultado esperado versus real, ambiente, e uma evidência — um screenshot, vídeo ou log. O que torna um report inútil é uma pré-condição faltando ou um passo que quem reportou fez sem perceber, porque o desenvolvedor não consegue reproduzir e fecha como "funciona na minha máquina".
Severity é o impacto técnico, priority é o quão rápido deve ser corrigido, e são definidas por pessoas diferentes — severity pelo tester, priority pelo product owner. Um erro de digitação no nome da empresa na landing page é severity baixa e priority máxima. Um crash em uma tela de admin usada duas vezes por ano é severity alta e priority baixa.
Não, e esse é um dos sete princípios do ISTQB. O teste pode mostrar que existem defeitos; ele nunca pode mostrar que não sobrou nenhum, porque testar exaustivamente cada input e caminho é impossível em qualquer sistema real. O que o teste te dá é evidência para decidir se o risco é aceitável — não uma garantia.
Um test case detalha pré-condições, passos e resultado esperado, então qualquer pessoa pode executá-lo de forma idêntica. Um checklist só nomeia o que cobrir e deixa o como a cargo do tester. Test cases valem o esforço em fluxos regulados ou de alto risco e para gente nova no produto; checklists ganham em trabalho exploratório e em uma equipe que já conhece o sistema, onde test cases completos viram documentação que ninguém atualiza.
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 Junior QA Manual →