Um cenário de teste diz "usuário não consegue fazer login com senha incorreta." Um caso de teste especifica o email exato, a senha errada a ser digitada, cada passo de clique e o texto esperado da mensagem de erro. Também define que o contador de tentativas falhas deve incrementar em 1.

A versão simples

Cenário de teste: uma descrição de alto nível do que verificar. Uma frase ou uma declaração breve. Caso de teste: uma especificação detalhada de como verificar: passos exatos, dados de teste, resultados esperados.

O cenário é a pergunta. O caso de teste é o procedimento completo para respondê-la.

Cenários de teste

Um cenário de teste descreve um comportamento de usuário ou condição de sistema a testar, sem especificar os passos exatos. É escrito do ponto de vista do usuário e foca no "o quê," não no "como."

Exemplos para uma feature de login:
  • Usuário consegue fazer login com credenciais válidas
  • Usuário não consegue fazer login com senha incorreta
  • Usuário não consegue fazer login com email não cadastrado
  • Conta é bloqueada após 5 tentativas de login falhas
  • Usuário consegue fazer login pelo browser mobile
  • Sessão expira após 30 minutos de inatividade
  • Usuário consegue fazer login com Google OAuth

Cada um desses é um cenário. Observe que não dizem:

  • Qual browser usar
  • Qual email específico digitar
  • Exatamente onde clicar
  • O que a mensagem de erro esperada diz

Cenários são úteis para planejar cobertura: garantir que você não perdeu nenhuma jornada importante do usuário. São rápidos de escrever e fáceis de revisar com stakeholders de negócio que não se importam com detalhes de implementação.

Casos de teste

Um caso de teste é uma especificação completa e reproduzível. Qualquer pessoa com o caso de teste e acesso ao sistema deve conseguir executá-lo exatamente e obter o mesmo resultado.

Exemplo de caso de teste para "Usuário não consegue fazer login com senha incorreta":

| Campo | Conteúdo |

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

| ID do Caso de Teste | TC-LOGIN-003 |

| Título | Login falha com senha incorreta |

| Pré-condições | Conta de usuário existe: qa_test@example.com (cadastrada, não bloqueada) |

| Dados de Teste | Email: qa_test@example.com / Senha: SenhaErrada123! |

| Passos | 1. Ir para /login 2. Digitar email qa_test@example.com 3. Digitar senha SenhaErrada123! 4. Clicar em "Entrar" |

| Resultado Esperado | Mensagem de erro "Email ou senha incorretos" está visível. Usuário permanece na página de login. |

| Pós-condições | Contador de tentativas de login falhas aumenta em 1 |

Esse nível de detalhe significa:

  • Um tester júnior consegue executar sem adivinhar
  • O teste pode ser reproduzido exatamente se falhar
  • Você pode comparar resultados ao longo do tempo (regressão)
  • Pode ser automatizado sem ambiguidade

Por que os dois existem

Cenários sem casos de teste = planejamento de cobertura sem consistência de execução. Você sabe o quê testar mas a execução varia entre testers. Um tester usa um email válido no teste de "senha incorreta", outro usa um email inexistente: resultados diferentes, bugs diferentes encontrados. Casos de teste sem cenários = você pode se perder nos passos e perder de vista a cobertura. Pode ter 50 casos de teste detalhados e ainda assim perder fluxos inteiros de usuário.

Na prática, a maioria dos times os usa em sequência:

1. Escrever cenários primeiro → revisar com PMs e devs → confirmar cobertura

2. Expandir cenários prioritários em casos de teste completos → executar sistematicamente

Quando usar cada um

Use cenários de teste quando

No início do planejamento. Antes de a feature ser construída, você pode esboçar cenários para alinhar com o time sobre o que deve ser testado. Ainda não precisa saber URLs exatas ou rótulos de botões. Para testes exploratórios. Cenários funcionam como charters leves para sessões exploratórias. "Explorar login com vários inputs inválidos" é direcionamento suficiente. Para revisões com stakeholders. Stakeholders de negócio e product managers conseguem revisar uma lista de cenários e dizer "sim, também precisamos testar X" sem se perder em detalhes passo a passo. Para mapeamento de cobertura. Uma lista de cenários dá uma visão visual rápida do que está coberto e do que está faltando.

Use casos de teste quando

Para testes de regressão. Testes que você roda repetidamente ao longo de releases precisam ser consistentes. Casos de teste garantem que a mesma coisa seja testada da mesma forma sempre. Para integrar novos testers. Um novo membro do time pode pegar um caso de teste e executá-lo corretamente no primeiro dia. Para conformidade e auditoria. Indústrias reguladas (bancos, medicina, aeroespacial) frequentemente exigem evidência exata do que foi testado e o que passou. Cenários sozinhos não são suficientes. Ao automatizar. Automação converte casos de teste em código. Se o seu caso de teste é vago, sua automação será vaga.

Times diferentes, palavras diferentes

Fique ciente de que a terminologia varia:

  • Alguns times chamam o que chamamos de "cenários" de ideias de teste ou charters de teste
  • Alguns times usam "caso de teste" para significar qualquer teste, seja detalhado ou não
  • Alguns times Agile escrevem critérios de aceite (em user stories) que servem ao mesmo propósito que os cenários
  • O formato BDD/Gherkin (Given/When/Then) faz a ponte: é estruturado como um caso de teste mas legível como um cenário

O que importa mais do que o rótulo é o propósito:

  • Planejando cobertura? Use o formato mais leve (cenário/ideia)
  • Executando de forma consistente? Use o formato detalhado (caso de teste/especificação)

Um exemplo prático: feature de checkout

Passo 1: escrever cenários
  • Usuário consegue concluir o checkout com cartão de crédito válido
  • Usuário não consegue fazer checkout com cartão expirado
  • Usuário não consegue fazer checkout com CVV inválido
  • Total do pedido inclui o imposto correto para a região do usuário
  • Usuário recebe confirmação por email após checkout bem-sucedido
  • Itens fora de estoque não podem ser comprados
  • Formulário de checkout valida campos obrigatórios
Passo 2: priorizar

Marque os cenários de maior risco (processamento de pagamento, validação de estoque) como "escrever casos de teste detalhados." Marque cenários de menor risco como "exploratório: testar conforme o tempo permitir."

Passo 3: escrever casos de teste para os cenários prioritários

Para "Usuário não consegue fazer checkout com cartão expirado," escreva:

  • Pré-condições (usuário logado, itens no carrinho, números de cartão de teste disponíveis)
  • Dados exatos de teste (número do cartão, mês e ano de expiração, CVV)
  • Passo a passo (navegar para o checkout → preencher entrega → preencher dados do cartão → submeter)
  • Resultado esperado (texto da mensagem de erro, pagamento não cobrado, carrinho preservado)

Resumo

| | Cenário de Teste | Caso de Teste |

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

| Nível de detalhe | Alto nível | Passo a passo |

| Foca em | O que testar | Como testar |

| Escrito por | QA, PM, time | Engenheiro de QA |

| Usado para | Planejamento, cobertura | Execução, regressão |

| Velocidade de escrita | Rápido (minutos) | Mais devagar (detalhado) |

| Público | Time todo | Testers, automação |

Comece com cenários para garantir a cobertura certa. Escreva casos de teste para o que você vai testar repetidamente, automatizar ou precisar provar que funcionou. Pule casos de teste para áreas onde testes exploratórios são suficientes.

Nenhum formato é inerentemente superior: a escolha certa depende do risco, do processo do time e do que o teste deve alcançar.

→ Veja também: Como Escrever um Caso de Teste: Formato, Exemplos e Erros Comuns | Testes Exploratórios: A Habilidade que a IA Não Consegue Substituir | Testes Baseados em Risco: Priorizando o que Testar Quando Não é Possível Testar Tudo