Um caso de teste que diz "verificar se o login funciona" não serve para nada. O tester não consegue executar porque "funciona" não está definido, e o dev não consegue automatizar porque não há nada concreto para validar. Um bom caso de teste é um contrato com três coisas fixadas: as precondições exatas, os passos exatos e um resultado esperado específico e observável.

O que um caso de teste não é

Um caso de teste não é uma lista de cliques. "Ir para a página de login. Inserir username. Inserir senha. Clicar em submit. Verificar a página." Isso diz o que fazer, mas não o que verificar, qual é o comportamento esperado, ou o que "correto" significa.

Um caso de teste é um contrato: dadas essas condições e essas ações, este resultado específico deve ocorrer.

Os componentes de um caso de teste

Todo caso de teste precisa desses campos. A ferramenta ou template não importa (TestRail, Zephyr, Notion, planilha), mas esses elementos devem estar presentes em algum lugar.

ID do caso de teste: Um identificador único. TC-001, AUTH-005, ITEMS-032, o que o time usar. Permite referenciação em bug reports e matrizes de rastreabilidade. Título: Uma frase descrevendo o que está sendo testado. Mesmas regras dos títulos de bug report: específico, sem palavras vagas. Precondições: O que deve ser verdadeiro antes do teste começar. Status da conta de usuário, dados que precisam existir, estado do sistema, ambiente. Passos do teste: As ações exatas a executar, numeradas, em ordem. Cada passo é uma ação. Dados de teste: Os inputs específicos usados. Não "inserir um e-mail válido", mas "inserir admin@becomeqa.com." Resultado esperado: O que deve acontecer após o último passo. Específico, observável, verificável. Prioridade: O quão crítico é esse caso de teste. Alta (bloqueia o release se falhar), Média (importante, mas tem workaround), Baixa (nice to have). Status: Passou, Falhou, Bloqueado, Não Executado.

Um caso de teste mínimo

ID: AUTH-001
Título: Usuário consegue fazer login com credenciais válidas

Precondições:
- Conta admin@becomeqa.com existe com senha testpass123
- Usuário não está logado

Passos:
1. Navegar para https://lab.becomeqa.com
2. Clicar no botão "Login" na navegação
3. Inserir "admin@becomeqa.com" no campo Username
4. Inserir "testpass123" no campo Password
5. Clicar em "Submit"

Resultado esperado:
- Modal fecha
- Página do dashboard é exibida
- Heading "My Travel Items" está visível
- Navegação mostra o nome ou avatar do usuário logado

Prioridade: Alta

Esse caso de teste está completo. Um novo engenheiro de QA consegue executá-lo sem fazer perguntas. Um dev consegue escrever um teste automatizado a partir dele diretamente.

Como escrever casos de teste para a feature de login

O login tem mais casos de teste do que o happy path. Uma feature de login completa exige no mínimo:

Happy path:
  • Credenciais válidas → login bem-sucedido
Caminhos negativos:
  • Senha incorreta → mensagem de erro, sem redirect
  • Username inexistente → mensagem de erro (atenção: não revelar se o e-mail existe)
  • Username vazio → erro de validação
  • Senha vazia → erro de validação
  • Ambos vazios → erro de validação
Casos de limite:
  • E-mail com comprimento máximo
  • Senha com comprimento máximo
  • Senha com caracteres especiais (!@#$%^&*)
Casos de segurança:
  • SQL injection no campo de username → a aplicação não deve quebrar
  • Injeção de script () → deve ser escapado, não executado
Casos de UX:
  • Campo de senha deve mascarar os caracteres
  • Pressionar Enter no campo de senha deve submeter o formulário
  • Link "Esqueci a senha" deve estar presente e funcional

São 12+ casos de teste para uma feature. Decidir quantos escrever é uma questão de julgamento baseada em risco. O login de uma empresa de pagamentos precisa de todos eles; uma ferramenta interna de admin usada por 5 pessoas precisa de menos.

Técnicas de design de casos de teste

Equivalence partitioning

Em vez de testar cada idade possível de 0 a 120, divida o espaço de entrada em grupos que devem se comportar de forma idêntica. Teste um valor de cada grupo.

Para um campo de idade que aceita 18–65:

  • Partição válida: qualquer valor entre 18 e 65 (teste um: 35)
  • Inválido abaixo: qualquer valor abaixo de 18 (teste um: 15)
  • Inválido acima: qualquer valor acima de 65 (teste um: 70)
  • Tipo inválido: input não numérico (teste um: "vinte")

Quatro casos de teste em vez de 120.

Boundary value analysis

Bugs se concentram nos limites. Teste as bordas de cada partição.

Para o mesmo campo de idade de 18–65:

  • 17: logo abaixo do limite inferior (inválido)
  • 18: limite inferior (válido)
  • 65: limite superior (válido)
  • 66: logo acima do limite superior (inválido)

Combinado com equivalence partitioning: 4 valores bem escolhidos cobrem toda a faixa.

Decision table testing

Quando múltiplas condições se combinam para produzir resultados diferentes, uma tabela de decisão mapeia todas as combinações:

| Logado | Tem assinatura ativa | Exibe conteúdo premium |

|--------|---------------------|----------------------|

| Não | qualquer | Não |

| Sim | Não | Não |

| Sim | Sim | Sim |

Escreva um caso de teste por linha. Tabelas de decisão são excelentes para regras de negócio com múltiplas condições.

Escrevendo casos de teste a partir de uma user story

User story: "Como usuário, posso adicionar um item de viagem com um nome de destino e um status."

Isso é um ponto de partida, não uma especificação completa. Antes de escrever os casos de teste, pergunte: quais são os status válidos? O destino é obrigatório? Qual é o comprimento máximo? O que acontece se o formulário for enviado vazio?

Obtenha as respostas primeiro, depois escreva os casos de teste. Casos de teste escritos a partir de requisitos ambíguos geralmente estão errados. Não por incompetência do tester, mas porque o requisito não especificou o comportamento.

ID: ITEMS-001
Título: Usuário consegue criar um novo item de viagem com dados válidos

Precondições:
- Usuário está logado como admin@becomeqa.com
- Dashboard está exibido com a tabela de itens

Passos:
1. Clicar no botão "Add Item"
2. Inserir "Tokyo" no campo Destination
3. Selecionar "Planned" no dropdown Status
4. Clicar em "Save"

Resultado esperado:
- Modal fecha
- Nova linha "Tokyo" com status "Planned" aparece na tabela de itens
- Confirmação de sucesso é exibida (toast ou mensagem)

Prioridade: Alta

ID: ITEMS-002
Título: Formulário de adicionar item exibe erro de validação quando o destino está vazio

Precondições:
- Usuário está logado como admin@becomeqa.com
- Modal de adicionar item está aberto

Passos:
1. Deixar o campo Destination vazio
2. Selecionar "Planned" no dropdown Status
3. Clicar em "Save"

Resultado esperado:
- Formulário não é submetido
- Erro de validação "Destination is required" aparece abaixo do campo Destination
- Modal permanece aberto

Prioridade: Alta

O que faz um caso de teste bom ou ruim

Bom:
  • Específico o suficiente para ser reproduzido sem fazer perguntas
  • Resultado esperado é observável e verificável (não "a página funciona corretamente")
  • Precondições são completas
  • Um resultado esperado por caso de teste
  • Passos são sequenciais e sem ambiguidade
Ruim:
  • "Verificar se o login funciona" (o que "funciona" significa?)
  • Precondições faltando (o teste vai falhar porque os dados não existem)
  • Passos combinados em um só ("preencher o formulário e submeter"), muito vago
  • Múltiplos resultados esperados em um único caso de teste (se um falha, você não sabe qual condição falhou)
Um caso de teste deve ser executável por alguém que nunca viu a feature antes. Se você se pega adicionando contexto mental ao reler os passos, o caso de teste não está específico o suficiente.

Quando escrever casos de teste e quando testar exploratorialmente

Escreva casos de teste para: cenários de regressão que serão re-executados repetidamente, features de alto risco ou complexas. Também qualquer coisa que precise de aprovação de um product owner ou stakeholder, e fluxos que serão automatizados.

Teste exploratorialmente para: novas features antes de escrever casos de teste (aprenda a feature primeiro), edge cases descobertos durante o teste (siga o fio). Também para qualquer coisa com tempo limitado onde escrever os scripts levaria mais tempo do que executá-los.

As duas abordagens têm seu lugar. Os melhores engenheiros de QA sabem quando usar cada uma.

FAQ

Quantos casos de teste são suficientes para uma feature?

O suficiente para ter confiança de que a feature funciona corretamente nos caminhos principais, nos edge cases e nas condições de erro. Não há número fixo. Um formulário simples com dois campos precisa de menos do que um fluxo de checkout complexo com múltiplas etapas.

Devo escrever casos de teste antes ou depois do desenvolvimento?

Antes, ou durante. Escrever casos de teste a partir dos requisitos antes do desenvolvimento serve a dois propósitos. Força a clarificação de requisitos ambíguos e produz uma checklist de testes pronta quando o desenvolvimento termina. Essa é a abordagem shift-left.

Meus casos de teste continuam falhando porque os requisitos mudaram. O que faço?

Atualize os casos de teste conforme os requisitos mudam. Casos de teste que refletem requisitos desatualizados são piores do que inúteis. Eles geram falsa confiança. Trate casos de teste como documentação viva, não como artefatos imutáveis.

Preciso escrever casos de teste para testes automatizados?

Testes automatizados são uma forma de casos de teste executáveis. Se o seu teste automatizado está bem escrito e legível, ele é o caso de teste. Você não precisa de um documento manual separado duplicando o que o código já diz.

→ Veja também: A Anatomia de um Bug Report que os Desenvolvedores Realmente Corrigem | Testes Baseados em Risco: Priorizando o que Testar Quando Não é Possível Testar Tudo | Caso de Teste vs Cenário de Teste: Diferença e Quando Usar Cada Um | Técnicas de Design de Casos de Teste: EP, BVA, Tabelas de Decisão, Transição de Estados | Como Escrever um Plano de Teste: Modelo e Exemplos Reais