O Que É um Caso de Teste?
Um caso de teste é um conjunto de condições e etapas usadas para verificar se uma funcionalidade ou função específica de um aplicativo de software funciona corretamente. Cada caso de teste define o que testar, como testar e qual deve ser o resultado esperado.
Pense nos casos de teste como os blocos de construção do seu processo de QA. Casos de teste bem escritos são repetíveis, sem ambiguidade e cobrem tanto os caminhos felizes quanto os casos de borda — para que qualquer testador possa usá-los e executá-los de forma consistente.
Este artigo fornece um modelo prático de caso de teste e depois apresenta exemplos do mundo real baseados nos cenários mais comuns de login e registro. Esses casos de teste cobrem caminhos felizes e casos de borda-chave — prontos para copiar na sua ferramenta de gerenciamento de testes.
Modelo de Caso de Teste
Abaixo está um modelo padrão de caso de teste que você pode copiar para a sua ferramenta de gerenciamento de testes, planilha ou documento.
Test Case ID: TC-[Module]-[Number]
Module: [e.g., Login, Registro]
Test Title: [Nome curto e descritivo]
Priority: [Critical / High / Medium / Low]
Preconditions: [O que deve ser verdade antes do teste]
Test Data: [Dados específicos a usar durante o teste]
Test Steps:
1. [Etapa 1]
2. [Etapa 2]
3. [Etapa 3]
Expected Result:
[O que deve acontecer quando as etapas forem executadas corretamente]
Actual Result:
[O que realmente aconteceu — preenchido durante a execução do teste]
Status: [Pass / Fail / Blocked / Not Executed]
Bug Reference: [BUG-XXX se aplicável]
Tester: [Nome]
Test Date: [AAAA-MM-DD]
Referência dos Campos do Caso de Teste
Antes de escrever casos de teste, entenda o que cada campo significa:
| Campo | Descrição | Exemplo |
|---|---|---|
| Test Case ID | Identificador único: TC-[Module]-[Number] |
TC-REG-001 |
| Module | A qual funcionalidade/módulo pertence | Registro, Login, Redefinição de Senha |
| Test Title | Descrição em uma linha do cenário | Registro bem-sucedido com email e senha válidos |
| Priority | Importância: Critical > High > Medium > Low | Critical = fluxo central quebrado; High = problema importante; Medium = caso de borda; Low = cosmético |
| Preconditions | Estado que deve ser verdade antes do teste | O usuário está na página de registro, o email não está registrado |
| Test Data | Valores específicos usados durante o teste, strings exatas | email = "<user@example.com>" |
| Test Steps | Ações numeradas, uma ação por etapa | 1. Navegar até a URL; 2. Digitar o valor; 3. Clicar no botão |
| Expected Result | O que deve acontecer quando executado corretamente | Conta criada, redirecionado para o dashboard |
| Actual Result | O que realmente aconteceu — preenchido durante a execução | Igual ao esperado / Erro: "Email já existe" |
| Status | Pass / Fail / Blocked / Not Executed | Preenchido durante a execução |
| Bug Reference | ID de rastreamento de bugs relacionado (se aplicável) | BUG-0042 |
| Notes | Informações adicionais: workaround, tickets relacionados | Reproduzível apenas no Firefox |
Exemplo Completo
Abaixo está um caso de teste completo mostrando como o modelo é preenchido:
Test Case ID: TC-REG-001
Module: User Registration
Test Title: Successful registration with valid email and password
Priority: Critical
Preconditions: User is on the registration page, no existing account with this email
Test Data: email = "newuser@example.com", password = "SecurePass123!", name = "John Doe"
Test Steps:
1. Navigate to https://app.example.com/register
2. Enter "John Doe" in the Full Name field
3. Enter "newuser@example.com" in the Email field
4. Enter "SecurePass123!" in the Password field
5. Enter "SecurePass123!" in the Confirm Password field
6. Check the "I agree to Terms of Service" checkbox
7. Click the "Create Account" button
Expected Result:
- Account is created successfully
- User is redirected to a "verify your email" page
- A confirmation email is sent to newuser@example.com within 30 seconds
- User can log in with the registered credentials after email verification
Tabela de Casos de Teste (Pronta para Copiar e Colar)
Copie esta tabela diretamente para o Excel / Google Sheets / TestRail. As 5 primeiras colunas são pré-preenchidas com dados de exemplo; as demais colunas são para você preencher durante a execução dos testes.
| ID | Module | Test Title | Priority | Type | Preconditions | Test Steps | Test Data | Expected Result | Actual Result | Pass/Fail | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|
| TC-REG-001 | Registration | Successful registration with valid email and password | Critical | Happy Path | User on registration page, email not registered | 1. Go to /register 2. Enter name, email, password 3. Agree to terms 4. Click Create | email="<newuser@example.com>", password="SecurePass123!" | Account created, redirected to verify page, confirmation email sent within 30s | |||
| TC-LOGIN-001 | Login | Successful login with correct email and password | Critical | Happy Path | Verified account <user@example.com> exists | 1. Go to /login 2. Enter email 3. Enter password 4. Click Sign In | email="<user@example.com>", password="CorrectPass123!" | Authenticated, redirected to dashboard, session token set |
Tabela de Modelo em Branco
Abaixo está o cabeçalho da tabela em branco. Copie-o e adicione linhas para os seus próprios casos de teste:
| ID | Module | Test Title | Priority | Type | Preconditions | Test Steps | Test Data | Expected Result | Actual Result | Pass/Fail | Notes |
|---|
Como Escrever Bons Casos de Teste: Melhores Práticas
1. Torne cada caso de teste independente
Um caso de teste deve verificar um comportamento específico. Se ele falhar, você deve saber exatamente o que está quebrado. Não combine vários cenários em um único caso de teste.
2. Seja específico com os dados de teste
"Digite um email válido" é vago. "Digite <user@example.com>" é preciso. Dados de teste específicos tornam os casos de teste reproduzíveis.
3. Cubra o caminho feliz E os casos de borda
O caminho feliz (login bem-sucedido com dados válidos) é importante, mas os casos de borda revelam bugs reais:
- Campos vazios
- Formatos inválidos
- Valores de limite
- Tokens expirados
- Sessões simultâneas
4. Escreva as precondições
As precondições configuram o ambiente de teste. Sem elas, o testador pode começar do estado errado e obter um aprovação/reprovação falso.
5. Use etapas claras e numeradas
Cada etapa deve ser uma única ação. "Preencha o formulário e envie" é vago demais. Divida-o em entradas individuais de campos.
6. Inclua o resultado esperado em detalhes
"O login tem sucesso" não é suficiente. Especifique o que o usuário vê, para onde é redirecionado, quais emails são enviados e o que acontece no banco de dados.
Como o BugCapturer Ajuda na Execução de Casos de Teste
Ao executar casos de teste, os testadores precisam documentar os resultados rapidamente. O BugCapturer, uma extensão gratuita do Chrome para relatórios de bugs e feedback visual, torna essa parte sem fricção:
- Capturas de tela anotadas: Quando um caso de teste falha, capture o estado exato da página com setas e texto destacando o problema — sem precisar descrevê-lo em palavras.
- Gravação de tela: Para cenários complexos (por exemplo, um fluxo de login de várias etapas com problemas de timing), grave um vídeo WebM curto de toda a execução do teste.
- Metadados técnicos automáticos: URL, navegador, SO, resolução de tela e viewport são capturados automaticamente — fundamentais para reproduzir bugs específicos de um ambiente.
- Dados de diagnóstico: Erros de console e requisições de rede com falha (status HTTP ≥ 400) são capturados juntamente com a evidência visual. As URLs de rede são automaticamente ocultadas quanto a parâmetros sensíveis.
- Exportação para Excel/TSV: Copie com um clique uma linha estruturada de relatório de bugs para a área de transferência. Cole diretamente na sua ferramenta de gerenciamento de testes ou na planilha da equipe.
Isso significa que os testadores gastam menos tempo escrevendo relatórios de bugs e mais tempo executando casos de teste.
Download: Modelo de Caso de Teste
Copie o modelo e os exemplos acima para o formato de sua preferência:
- TestRail / Zephyr / Xray — crie casos de teste com os campos padrão
- Excel / Google Sheets — use como uma planilha com colunas para cada campo
- Notion / Confluence — crie um banco de dados com uma entrada por caso de teste
- Markdown — mantenha no seu repositório para controle de versão
O modelo e os exemplos deste artigo estão prontos para uso. Personalize os cenários de login/registro para o seu aplicativo específico, adicione os seus próprios módulos e construa uma suíte de testes completa que a sua equipe de QA possa executar com confiança.