Um caso de teste é uma descrição estruturada de uma verificação específica. Seu objetivo é tornar a verificação inequívoca, reproduzível e útil para a equipe, em vez de simplesmente documentar algo.
O que um bom caso geralmente contém
- →Um título claro que expresse o objetivo da verificação.
- →Pré-condições: o estado inicial do sistema necessário.
- →Etapas de teste: ações executadas pelo testador ou sistema.
- →Resultado esperado: exatamente o que deveria acontecer.
- →Onde necessário, dados de teste, prioridade, links de requisitos e notas.
O que torna um caso de teste forte
- →Ele verifica uma regra ou risco específico, em vez de tudo de uma vez.
- →O resultado esperado é mensurável e inequívoco.
- →Ele contém etapas suficientes para maior clareza, sem detalhes desnecessários.
- →Uma falha deixa claro o que deu errado.
Erros comuns
- →Escrever casos excessivamente longos que cobrem várias ideias diferentes ao mesmo tempo.
- →Usar resultados esperados vagos, como "funciona corretamente".
- →Falha ao separar as pré-condições das etapas.
- →Duplicar dezenas de casos quase idênticos onde uma lista de verificação ou parametrização funcionaria melhor.
Quando um caso é desnecessário
Nem toda verificação precisa de um caso de teste separado. Em testes rápidos smoke ou sanity, funcionalidades instáveis e sessões exploratórias, a documentação detalhada pode custar mais do que acrescenta. Um bom profissional de QA escolhe o formato deliberadamente.
Casos de login resolvidos com requisitos explícitos
Estes casos usam uma especificação fictícia de treinamento, não regras universais de login. A conta learner@example.test está ativa e tem uma senha válida conhecida. Uma senha errada ou conta desconhecida mostra a mesma mensagem, “Invalid credentials”, sem criar uma sessão. Campos vazios mostram erros de campo sem enviar uma requisição de login. A terceira senha errada consecutiva para uma conta conhecida a bloqueia por 5 minutos; um login bem-sucedido zera o contador. Uma conta bloqueada não pode fazer login nem com a senha correta.
Execute cada caso de forma independente. Restaure o contador de falhas, o estado de bloqueio e a sessão declarados antes de começar; caso contrário, a sequência dos testes anteriores altera o resultado esperado. Use somente credenciais sintéticas.
ID Estado inicial Entrada / ação Resultado esperado
L01 Ativa, 0 falhas, sem sessão Enviar conta conhecida + senha correta Sessão criada; perfil abre; contador é 0
L02 Ativa, 0 falhas, sem sessão Enviar conta conhecida + senha errada Credenciais inválidas; sem sessão; contador é 1
L03 Conta desconhecida, sem sessão Enviar unknown@example.test + qualquer senha Credenciais inválidas; sem sessão
L04 Sem sessão Enviar com ambos os campos vazios Dois erros de campo; nenhuma requisição de login
L05 Ativa, 2 falhas, sem sessão Enviar conta conhecida + senha errada Sem sessão; conta bloqueada por 5 minutos
L06 Bloqueada, antes da expiração, sem sessão Enviar conta conhecida + senha correta Sem sessão; bloqueio permaneceExpanda uma linha em um caso manual executável
Caso: L02 — rejeitar uma senha errada
Pré-condições: conta ativa, contador de falhas 0, sem sessão.
1. Abra a página de login.
2. Insira learner@example.test e uma senha deliberadamente incorreta.
3. Envie uma vez.
Interface esperada: “Invalid credentials”; o perfil não abre.
Estado esperado: sem sessão; o contador de falhas da conta conhecida passa a 1.
Evidência: resposta sanitizada e observação de estado disponível no ambiente de teste.O contador exige um mecanismo de observação acordado, como uma visão administrativa exclusiva de teste ou um ambiente de teste autorizado. Se ele não estiver disponível, marque essa asserção como não verificada, em vez de inferi-la a partir de uma mensagem. Acrescente casos de recuperação, expiração de bloqueio, concorrência e acessibilidade conforme os riscos reais do produto; as seis linhas são um conjunto inicial, não uma avaliação completa de autenticação.