O Que É um Plano de Teste?
Um plano de teste é um documento detalhado que descreve a estratégia de teste, os objetivos, os recursos, o cronograma e o escopo de um esforço de teste. É o modelo para toda a fase de QA — respondendo quem testa o quê, como, quando e como é o "pronto".
Pense em um plano de teste como um contrato entre a equipe de QA, os desenvolvedores e os stakeholders. Ele define expectativas, define responsabilidades e fornece um roteiro para a execução dos testes. Seja testando um site pequeno ou um grande aplicativo empresarial, um bom plano de teste mantém todos alinhados.
Este artigo fornece um modelo de plano de teste gratuito, pronto para copiar e colar, com um exemplo do mundo real, para que você possa criar o seu próprio plano de teste em minutos.
Modelo de Plano de Teste (Pronto para Copiar e Colar)
Abaixo está um modelo abrangente de plano de teste. Copie-o para seu documento, planilha ou ferramenta de gerenciamento de projetos e personalize-o para o seu projeto.
Test Plan
=========
### 1. Introdução
1.1 Objetivo
[Breve descrição de por que este plano de teste existe]
1.2 Escopo
[O que está sendo testado — inclua funcionalidades, módulos, sistemas]
1.3 Fora do Escopo
[O que NÃO está sendo testado — seja explícito]
1.4 Referências
[Links para documentos de requisitos, especificações de design, histórias de usuário]
### 2. Objetivos de Teste
[O que você deseja alcançar com os testes. Exemplos:]
- Verificar se todos os fluxos de trabalho de negócio críticos funcionam corretamente
- Garantir a compatibilidade entre navegadores (Chrome, Firefox, Safari, Edge)
- Validar a integridade dos dados em todas as operações de CRUD
- Alcançar uma taxa de aprovação de casos de teste de 95%+ antes da aprovação final
### 3. Estratégia de Teste
3.1 Níveis de Teste
[ ] Teste Unitário
[ ] Teste de Integração (SIT)
[ ] Teste de Sistema
[ ] Teste de Aceitação do Usuário (UAT)
3.2 Tipos de Teste
[ ] Teste Funcional
[ ] Teste de Regressão
[ ] Teste de Desempenho
[ ] Teste de Segurança
[ ] Teste de Usabilidade
[ ] Teste de Acessibilidade
3.3 Ambiente de Teste
- URL de staging: [https://staging.example.com]
- Banco de dados: [PostgreSQL 15, réplica de staging]
- Navegadores-alvo: [Chrome 125+, Firefox 125+, Safari 17+, Edge 125+]
- Dispositivos móveis-alvo: [iOS 17+, Android 14+]
- Ferramentas de teste: [BugCapturer, Lighthouse, axe DevTools]
### 4. Entregáveis de Teste
[ ] Documento do Plano de Teste (este documento)
[ ] Especificações de Casos de Teste
[ ] Dados de Teste (contas fictícias, conteúdo de exemplo)
[ ] Relatórios de Bugs (registrados durante a execução)
[ ] Relatório de Execução de Teste (resumo de aprovação/reprovação)
[ ] Documento de Aprovação do UAT
### 5. Cronograma de Teste
| Fase | Data de Início | Data de Término | Duração |
|-------|---------------|-----------------|---------|
| Planejamento de Teste | [Data] | [Data] | [X dias] |
| Preparação de Casos de Teste | [Data] | [Data] | [X dias] |
| Execução de Teste (Rodada 1) | [Data] | [Data] | [X dias] |
| Correção de Bugs | [Data] | [Data] | [X dias] |
| Execução de Teste (Rodada 2) | [Data] | [Data] | [X dias] |
| UAT | [Data] | [Data] | [X dias] |
| Aprovação Final | [Data] | [Data] | [X dias] |
### 6. Funções e Responsabilidades
| Função | Nome | Responsabilidades |
|------|------|-----------------|
| Gerente de Teste | [Nome] | Planejar, coordenar, relatar |
| Engenheiro de QA | [Nome] | Escrever casos de teste, executar testes, registrar bugs |
| Desenvolvedor | [Nome] | Corrigir bugs, apoiar o troubleshooting |
| Product Owner | [Nome] | Definir critérios de aceitação, aprovação do UAT |
| Participantes do UAT | [Nomes] | Executar cenários de UAT |
### 7. Resumo de Casos de Teste
| Módulo | Total de Casos de Teste | % de Automação | Prioridade |
|--------|------------------------|----------------|------------|
| Registro de Usuário | [XX] | [X%] | Alta |
| Login / Autenticação | [XX] | [X%] | Alta |
| Checkout | [XX] | [X%] | Crítica |
| Busca | [XX] | [X%] | Média |
| Painel de Administração | [XX] | [X%] | Baixa |
### 8. Processo de Rastreamento de Bugs
1. O testador encontra um bug
2. O testador registra o relatório de bugs com:
- Captura de tela ou gravação de tela (anotada)
- Etapas para reproduzir
- Detalhes do ambiente (URL, navegador, SO)
- Resultado esperado x o resultado real
3. O Gerente de Teste faz a triagem e atribui a prioridade
4. O desenvolvedor corrige o bug
5. O testador verifica a correção
6. O bug é encerrado
Ferramenta recomendada: BugCapturer para relatórios de bugs com um clique
com metadados capturados automaticamente e capturas de tela anotadas.
### 9. Critérios de Entrada e Saída
9.1 Critérios de Entrada (o que deve ser verdade antes de os testes começarem)
[ ] Todas as funcionalidades críticas estão desenvolvidas
[ ] O ambiente de staging está estável
[ ] Os dados de teste estão preparados
[ ] Os casos de teste são revisados e aprovados
9.2 Critérios de Saída (o que deve ser verdade antes de os testes terminarem)
[ ] Todos os bugs críticos e de alta prioridade estão corrigidos
[ ] 95% dos casos de teste aprovados
[ ] O UAT é aprovado pelos stakeholders
[ ] As metas de desempenho são alcançadas
### 10. Riscos e Mitigação
| Risco | Impacto | Probabilidade | Mitigação |
|------|---------|---------------|------------|
| Ambiente de staging instável | Alto | Média | Tenha um plano de rollback, ambiente de backup |
| Alterações em APIs de terceiros | Médio | Média | Simule serviços externos cedo |
| Disponibilidade limitada de participantes do UAT | Alto | Baixa | Recrute testadores reservas, estenda a janela de UAT |
| Expansão de escopo | Médio | Alta | Congele os requisitos antes de os testes começarem |
### 11. Aprovações
| Função | Nome | Assinatura | Data |
|------|------|-----------|------|
| Gerente de Teste | [Nome] | | |
| Gerente de Projeto | [Nome] | | |
| Product Owner | [Nome] | | |
Exemplo de Plano de Teste
Aqui está um exemplo de plano de teste preenchido para o lançamento de um site de e-commerce:
Projeto: Lançamento da AcmeShop.com v2.0 Gerente de Teste: Alex Wang Cronograma: 4 semanas (2 semanas de execução + 1 semana de correção de bugs + 1 semana de UAT)
Escopo:
- Registro de usuário, login e redefinição de senha
- Navegação de produtos, busca e filtragem
- Carrinho de compras e checkout
- Histórico de pedidos e rastreamento
- Gerenciamento de pedidos pelo admin
- Integração com gateway de pagamento (Stripe)
Fora do Escopo:
- Sistema de gerenciamento de inventário de terceiros (fornecedor separado)
- Validação de migração de dados da versão legada v1.0
- Testes de carga além de 1.000 usuários simultâneos
Resumo de Casos de Teste:
- Total: 245 casos de teste (85 automatizados, 160 manuais)
- Módulos: Autenticação (32), Produtos (48), Carrinho (55), Checkout (70), Admin (40)
- Taxa de aprovação esperada: 95% antes do UAT, 98% antes do lançamento
Principais Riscos:
- O sandbox da API do Stripe tem comportamento diferente do de produção — mitigado adicionando casos de teste extras para casos de borda
- Os participantes do UAT são membros da equipe de vendas com disponibilidade limitada — recrutados 10 participantes, visando 5 ativos
Rastreamento de Bugs:
- Usando o BugCapturer para todos os relatórios de bugs
- Bugs críticos: corrigir em até 4 horas, retestes imediatos
- Bugs altos: corrigir em até 24 horas, reteste no mesmo dia
- Bugs médios: corrigir antes do lançamento
- Bugs baixos: backlog para o pós-lançamento
Exemplo de Plano de Teste: Principais Seções Explicadas
Objetivos de Teste
Esta é a seção mais importante. Ela responde "por que estamos testando?". Bons objetivos são específicos e mensuráveis:- ❌ "Testar o site minuciosamente"
- ✅ "Verificar se todos os 20 fluxos de checkout são concluídos sem erros em Chrome, Firefox, Safari e Edge"
Critérios de Entrada e Saída
Os critérios de entrada evitam esforço desperdiçado (não comece a testar uma build quebrada). Os critérios de saída evitam aprovações prematuras (não diga que o teste terminou quando ainda há bugs críticos em aberto).Processo de Rastreamento de Bugs
Um processo claro de rastreamento de bugs é essencial para uma fase de execução de testes tranquila. Quanto mais rápido os bugs são relatados, mais rápido são corrigidos. Usar uma ferramenta como o BugCapturer durante a execução dos testes acelera o ciclo de feedback:- Anotação de captura de tela — os testadores podem destacar problemas diretamente na página com setas, retângulos e texto
- Metadados técnicos automáticos — URL, navegador, SO, resolução de tela e viewport são capturados automaticamente
- Gravação de tela — grave um vídeo WebM curto do bug e depois corte e extraia os quadros-chave
- Coleta de dados de diagnóstico — erros de console e requisições de rede com falha são capturados juntamente com a evidência visual
- Exportação para Excel/TSV — copie com um clique uma linha estruturada de relatório de bugs para a área de transferência para acompanhamento em equipe
Como Criar um Plano de Teste
Etapa 1: Entenda o projeto
Leia os requisitos, converse com os stakeholders e entenda o que está sendo construído. Um plano de teste é tão bom quanto a sua compreensão do projeto.Etapa 2: Defina o escopo
Seja explícito sobre o que está dentro e fora do escopo. Escopo vago é a causa nº 1 de disputas sobre o plano de teste.Etapa 3: Escolha a sua estratégia
Decida quais níveis e tipos de teste se aplicam ao seu projeto. Um pequeno site de marketing precisa de testes diferentes do que um aplicativo bancário.Etapa 4: Estime recursos e cronograma
Use dados históricos de projetos anteriores. Se você não tem dados históricos, adicione 30% de reserva às suas estimativas.Etapa 5: Escreva o plano
Use o modelo acima. Comece com o modelo e depois personalize-o. Não escreva do zero.Etapa 6: Obtenha as aprovações
Um plano de teste que ninguém aprovou é um plano de teste que ninguém segue. Obtenha a aprovação por escrito do gerente de projeto e do product owner.Download: Modelo de Plano de Teste
O modelo acima funciona em qualquer formato:
- Google Docs / Word — use a estrutura de seções como um documento formal
- Confluence / Notion — crie uma página de plano de teste com sub-páginas para cada seção
- Excel / Google Sheets — use como uma planilha com guias para cada fase
- Markdown — mantenha no seu repositório para controle de versão
Escolha o formato que a sua equipe usa. O formato importa menos do que o conteúdo — um bom plano de teste em um documento simples é melhor do que um plano de teste ruim em uma ferramenta sofisticada.