Os novos testadores costumam ouvir esses dois termos usados ​​como se significassem a mesma coisa. Eles não. A diferença entre um caso de teste e um cenário de teste está principalmente no nível de detalhe, e entendê-lo ajuda você a decidir quanto escrever antes de iniciar o teste.

Este guia explica cada um deles e, em seguida, funciona por meio de um único recurso de redefinição de senha, desde requisitos até cenários e casos de teste completos. O recurso e suas regras são um exemplo inventado. A terminologia também varia um pouco entre equipes e ferramentas, então chegue a um acordo sobre o que essas palavras significam em sua própria equipe.

A resposta curta

Um cenário de teste descreve uma situação a ser verificada, como “verificar se um usuário pode redefinir uma senha esquecida”. Geralmente é uma linha e deixa os detalhes para o testador.

Um caso de teste explica precisamente como verificar uma condição dentro dessa situação: pré-condições, etapas, dados de teste e o resultado esperado. Dois testadores seguindo-o devem chegar ao mesmo veredicto.

Pense em planejar uma viagem. O cenário é “viagem de Pune a Delhi”. O caso de teste é o itinerário completo, com número do voo, horário de saída e o que fazer em cada etapa.

Caso de teste versus cenário de teste lado a lado

O que é um cenário de teste?

Um cenário de teste é uma breve descrição de algo que um usuário pode fazer ou de uma situação que o sistema deve lidar. Ele se concentra no que é importante de fora e geralmente vem direto de um requisito ou história de usuário.

Os cenários são valiosos porque são rápidos. Você pode listar trinta no tempo que leva para escrever três casos detalhados, o que os torna uma ótima maneira de revisar a cobertura com o proprietário do produto: “já pensamos em tudo?” Um leitor não técnico pode acompanhar uma lista de cenários sem problemas.

O que é um caso de teste?

Um caso de teste é um conjunto de condições e etapas específicas usadas para determinar se algo funciona. Um caso de teste típico contém:

• Um ID exclusivo e um título claro
• Pré-condições, ou seja, o que deve ser verdadeiro antes de você começar
• Etapas numeradas
• dados de teste específicos
• Um resultado esperado
• O resultado real e o status, preenchidos durante a execução

Os casos de teste brilham quando a consistência é importante. Um novo membro da equipe pode executá-los, os resultados podem ser comparados entre as versões e você tem um registro do que foi verificado. Aprofundamos nosso guia sobre como escrever casos de teste.

Um recurso, do início ao fim

Etapa 1: o requisito

Os usuários que esquecerem a senha podem solicitar um link de redefinição por e-mail. O link funciona uma vez e expira após 30 minutos. Uma nova senha deve ter pelo menos 8 caracteres.

Etapa 2: os cenários de teste

Veja TS-02. O requisito nunca diz o que deveria acontecer com um email desconhecido, e escrever o cenário expôs essa lacuna. A página deve revelar que o endereço não está cadastrado? Por segurança, normalmente não deveria, pois isso permite que os invasores descubram contas válidas. Encontrar essas questões antecipadamente é um dos maiores benefícios de escrever cenários.

Etapa 3: os casos de teste

Agora expandimos apenas o TS-05 para casos de teste. Um cenário torna-se vários:

Esses valores não foram aleatórios. TC-051 e TC-052 ficam em ambos os lados do limite, usando análise de valor limite, e os outros vêm de particionamento de equivalência.

Um modelo de caso de teste

Aqui está o TC-052 escrito na íntegra. Copie este layout se sua equipe ainda não tiver um padrão:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Observe que o resultado esperado verifica mais do que a mensagem de erro. Também confirma que a senha antiga ainda funciona e que o link permanece utilizável. Os casos de teste fracos geralmente param no que está visível na tela.

Onde eles se encaixam no quadro geral

Tradicionalmente, cenários e casos são escritos durante a fase de design de teste do ciclo de vida de teste de software.

Quando usar cada

Os cenários são frequentemente suficientes quando:

• A equipe é pequena, experiente e conhece bem o produto.
• O tempo é curto ou os requisitos mudam com frequência.
• O recurso é de baixo risco.
• Você deseja revisar a cobertura rapidamente com as partes interessadas.
• Você está orientando testes exploratórios.

Casos de teste detalhados valem o esforço quando:

• Uma falha seria dispendiosa, como acontece com pagamentos, segurança ou dados de saúde.
• Os reguladores ou auditores precisam de provas do que foi testado.
• Testadores novos ou terceirizados devem executar os testes.
• Os resultados devem ser repetidos exatamente, como em um conjunto de regressão.
• As etapas se tornarão testes automatizados.

A maioria das equipes maduras usa ambos. Eles listam cenários para tudo e escrevem casos completos apenas para os riscos mais elevados. Não há necessidade de documentar todas as etapas de uma página de configurações de baixo risco da mesma forma que uma transferência bancária.

Cenários, casos e automação

Um caso de teste bem escrito é mapeado quase diretamente para um teste automatizado. As pré-condições tornam-se configurações, as etapas tornam-se ações e o resultado esperado torna-se uma afirmação. Estruturas de desenvolvimento orientadas a comportamento usam até a palavra “Cenário” para suas especificações executáveis:

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

O que é confuso é que o que o BDD chama de cenário está muito mais próximo de um caso de teste, porque possui dados e resultados específicos. Esse é um bom lembrete para concordar com os termos. Para automatizar essas verificações, consulte nosso tutorial do Playwright ou tutorial do pytest.

O que os torna bons

Erros comuns

• Escrever apenas caminhos felizes. A maioria dos bugs está nas condições de erro, então inclua o que deve falhar.
• Usar resultados esperados vagos. “Deve funcionar corretamente” permite que qualquer testador decida qualquer coisa.
• Documentar tudo na íntegra. Milhares de casos que ninguém mantém são piores do que um pequeno conjunto útil.
• Pular cenários. Ir direto para os casos pode deixar áreas inteiras esquecidas.
• Deixar os casos obsoletos. Quando o produto muda, os casos antigos enganam as pessoas. Revise-os regularmente.
• Anexar etapas a detalhes frágeis. “Clique no botão azul na parte superior” rompe com qualquer redesenho.

Considerações finais

Os cenários oferecem amplitude e os casos de teste proporcionam profundidade. Comece com cenários para seu próximo recurso e revise-os com um desenvolvedor e um proprietário do produto. Em seguida, expanda apenas os arriscados para casos completos. Você encontrará lacunas mais cedo e gastará seu tempo escrevendo onde for importante.

Perguntas frequentes

Continue aprendendo