Como Escrever um Plano de Teste: Modelo e Exemplos Reais

Um plano de testes sem seção de fora do escopo é um documento que diz "sim" para tudo por padrão. Cada stakeholder assume que sua feature está coberta, e o time nunca chega a um ponto de encerramento definido. Um plano de uma página que as pessoas realmente leem e consultam durante os testes vale mais do que um documento de 20 páginas arquivado antes do sprint começar.

O que um plano de testes é (e o que não é)

É:

• Um documento que define o escopo, a abordagem e os recursos para testar uma feature ou release
• Comunicação entre QA, devs e stakeholders
• Uma referência durante os testes para que todos saibam o que estava previsto

Não é:

• Uma lista de casos de teste (esse é outro documento)
• Uma garantia de que nenhum bug vai para produção
• Algo que precisa de 40 páginas

Um plano de testes de uma página para uma feature pequena é completamente adequado. O objetivo é clareza, não extensão.

As seções principais

1. Feature ou sistema sob teste

O que exatamente estamos testando? Seja específico.

Vago:

Testando o processo de checkout

Específico:

Testando o fluxo de checkout para usuários registrados: carrinho → endereço de entrega → pagamento (Stripe) → confirmação do pedido. Exclui checkout de visitante (testado separadamente) e reembolsos (ainda não implementado).

2. Objetivos

O que queremos alcançar com esse esforço de testes?

Exemplo:

• Verificar que usuários registrados conseguem concluir compras de produtos físicos
• Garantir que o processamento de pagamento se integra corretamente com o Stripe em cenários de sucesso e recusa
• Confirmar que e-mails de confirmação de pedido são enviados em até 2 minutos após a compra
• Validar que o estoque é decrementado corretamente após a compra

3. Escopo

No escopo:

• Registro e login de usuário
• Adicionar itens ao carrinho
• Aplicar códigos de desconto
• Checkout com cartão de crédito
• Página de confirmação do pedido
• E-mail de confirmação do pedido

Fora do escopo:

• Integração com PayPal (Fase 2)
• Checkout de visitante (feature separada)
• Devoluções e reembolsos
• App mobile (plano de testes separado)

Essa é a seção mais importante de escrever com cuidado. Scope creep em testes é tão real quanto em desenvolvimento.

4. Abordagem de testes

Como os testes serão realizados?

Exemplo:

5. Ambiente de testes

Onde os testes vão acontecer?

Ambiente: Staging (https://staging.meuapp.com)
Dados: Banco de staging novo com dados de teste inseridos
Navegador: Chrome (principal), Firefox (regressão)
Mobile: iOS Safari via BrowserStack (smoke apenas)

Credenciais de API: chaves de modo de teste do Stripe
Cartão de teste Stripe: 4242 4242 4242 4242
Cartão recusado: 4000 0000 0000 0002

6. Dados de teste

Quais dados precisam existir antes dos testes começarem?

Usuários:

• 3 usuários registrados com perfis diferentes (admin, membro, visualizador)
• 1 usuário com método de pagamento salvo
• 1 usuário com método de pagamento expirado
• Edge case: usuário com nome muito longo (para teste de truncamento de formulário)

Produtos:

• Produto padrão (em estoque)
• Produto sem estoque
• Produto com código de desconto aplicado
• Produto digital (sem frete necessário)

Códigos de desconto:

• SAVE10 — 10% de desconto, ativo
• SAVE50 — 50% de desconto, ativo
• EXPIRED99 — expirado, não deve ser aplicado

7. Avaliação de risco

Quais são as áreas de maior risco? O que pode dar errado?

Maior risco = mais cobertura de testes necessária.

8. Critérios de entrada e saída

Critérios de entrada (os testes podem começar quando):

• Todas as features no escopo estão deployadas no staging
• Smoke tests passam
• Dados de teste estão configurados
• Documentação de API está atualizada

Critérios de saída (os testes estão concluídos quando):

• Todos os casos de teste de alta prioridade passam
• Nenhum bug P1 ou P2 em aberto
• Testes de performance passam (< 2s de carregamento de página)
• Suite de regressão passa

9. Cronograma de testes

10. Gestão de defeitos

Como os bugs serão rastreados?

Ferramenta: Jira
Projeto: CHECKOUT
Labels de prioridade: P1 (blocker), P2 (major), P3 (minor), P4 (cosmético)

P1 blockers: Parar os testes, corrigir imediatamente
P2 major: Corrigir antes do release
P3 minor: Corrigir no próximo sprint se possível
P4 cosmético: Adicionar ao backlog

Template de bug report:
- Ambiente
- Passos para reproduzir (numerados)
- Resultado esperado
- Resultado real
- Screenshot/vídeo
- Navegador/sistema operacional

11. Papéis e responsabilidades

Um mini plano de testes completo

Veja como um plano de testes real fica para uma feature pequena: edição de perfil de usuário.

Plano de Testes: Edição de Perfil de Usuário
Versão 1.0 | Autor: Time de QA | Data: 2026-01-15

Feature: Usuários podem editar seu nome de exibição e avatar na página de perfil.

Escopo:

• Inclui: mudança de nome, upload de avatar (JPEG/PNG, máx. 5MB), validação de nome
• Exclui: mudança de e-mail (requer verificação, plano separado), mudança de senha

Abordagem:

• Testes funcionais manuais do happy path e edge cases
• Testes de API no endpoint PUT /api/users/{id}
• Regressão automatizada para fluxos críticos

Ambiente: Staging com contas de teste pré-configuradas

Dados necessários:

• Conta de usuário com avatar existente
• Conta de usuário sem avatar
• Imagens de teste: JPEG válido (2MB), PNG válido (4MB), imagem grande demais (10MB), formato inválido (PDF)

Riscos:

• Limite de tamanho de arquivo aplicado apenas no client-side: é preciso testar também no servidor
• Armazenamento de avatar (S3): testar o que acontece quando o upload falha

Critérios de saída: Todos os bugs P1/P2 fechados, nome e avatar atualizam corretamente para todos os casos de teste, suite de regressão verde.

Só isso. Um bom plano de testes cabe em uma página.

Erros comuns

Muito vago: "Vamos testar a feature de login." Como? Em todos os navegadores? Para todos os perfis de usuário? Só API? Só UI?

Muito longo: Um documento de 20 páginas que ninguém lê não serve para nada. Se os stakeholders não vão ler, não está comunicando nada.

Sem seção de escopo: Sem itens explícitos fora do escopo, cada stakeholder assume que o que importa para ele está coberto.

Sem avaliação de risco: Você vai gastar tempo igual em áreas de baixo e alto risco em vez de priorizar.

Sem critérios de saída: Como você sabe quando terminou? "Quando o tempo acabar" não é critério de saída.

Resumo

Um plano de testes cobre:

1. O que está sendo testado (e o que não está)
2. Como será testado (manual, automatizado, exploratório)
3. Onde os testes acontecem (ambientes)
4. Quais dados são necessários
5. Quais riscos existem e como mitigá-los
6. Quando os testes começam e terminam (critérios de entrada e saída)
7. Quem é responsável pelo quê

Mantenha curto e específico. Um plano de uma página que todos leem vale infinitamente mais do que um documento de 20 páginas guardado em uma pasta.

→ Veja também: Testes Baseados em Risco: Priorizando o que Testar Quando Não é Possível Testar Tudo | Como Escrever um Caso de Teste: Formato, Exemplos e Erros Comuns | Técnicas de Design de Casos de Teste: EP, BVA, Tabelas de Decisão, Transição de Estados