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:

| Tipo | Abordagem | Responsável |

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

| Smoke testing | Manual, antes da regressão | Time de QA |

| Testes funcionais | Casos de teste manuais | Time de QA |

| Testes de API | Automatizado com Playwright | QA automation |

| Regressão E2E | Automatizado com Playwright | QA automation |

| Performance | Load test com k6 | DevOps |

| Exploratório | Sessão de 2 horas por sprint | Time de QA |

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

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

| Escrita dos casos de teste | Dia 1 do sprint | Dia 3 | QA |

| Testes manuais | Dia 4 do sprint | Dia 7 | QA |

| Regressão pós-correção | Dia 8 do sprint | Dia 9 | QA |

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

| Pessoa | Papel |

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

| Ana Silva | QA Lead — plano geral, aprovação final |

| Bruno Costa | QA Engineer — escrita de casos de teste, testes manuais |

| Carol Wu | QA Automation — scripts Playwright |

| David Kim | Desenvolvedor — correção de bugs, dúvidas técnicas |

| Eva Martins | Product Manager — requisitos, critérios de aceitação |

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