Um plano de teste explica o que será testado, porquê, como, por quem e sob que condições. Seu valor vem da compreensão compartilhada da abordagem e dos limites, e não da extensão do documento.
Quando um plano de teste é útil
- →A funcionalidade é grande, arriscada ou abrange equipes.
- →Escopo, prioridades, ambientes, papéis e critérios de prontidão precisam de acordo explícito.
- →As expectativas externas incluem auditorias, conformidade, regulamentação ou relatórios formais.
- →Sem um plano acordado, a equipe pode interpretar a profundidade e os limites do teste de maneira diferente.
O que um bom plano inclui
- →Objetivos de teste e principais riscos.
- →Escopo incluído e excluído.
- →Tipos e níveis de teste aplicáveis.
- →Ambientes, dados de teste e dependências.
- →Funções, responsabilidades, prazos e critérios de conclusão.
O que evitar
- →Modelos genéricos desconectados do produto.
- →Excesso de informações que ninguém usa.
- →Um documento estático escrito uma vez e nunca atualizado.
- →Substituir a reflexão real sobre riscos e estratégia por burocracia.
Orientação prática
Um bom plano responde a questões reais: o que é crítico, onde estão os riscos, o que fica fora dos testes, o que falta para a qualidade e quais evidências apoiarão o lançamento. Se não ajuda nas decisões, é trabalhoso ou abstrato demais.
Exemplo preenchido: uma pequena versão do formulário de pagamento
Tudo neste plano é uma suposição fictícia de treinamento. Não é um relato sobre um banco, cliente ou versão publicada. A aplicação aceita tokens sintéticos de pagamento e chama um stub local do provedor que retorna approved, declined ou timeout. Não há dados reais de cartões, contas ou dinheiro. Os valores são centavos inteiros em uma moeda de demonstração explicitamente configurada.
ID do plano: PAY-DEMO-1; versão: 1; papel responsável: profissional de QA
Objetivo: validar o formulário de pagamento e evitar pagamentos bem-sucedidos duplicados.
Objeto de teste: um build de demonstração congelado; registrar o commit e a configuração reais antes da execução.
No escopo: envio, validação, resultados do provedor, repetição de requisição, repetição de callback, atualização da página de resultado, teclado e layout de 375 px.
Fora do escopo: provedor real, liquidação real, reembolsos, assinaturas, 3-D Secure, outras moedas, certificação de carga/segurança.
Ambiente: aplicação local descartável + stub do provedor + banco de teste preparado.
Dados: cliente/pedido sintético novo por caso; limpar o diário do stub entre casos.
Observação: IDs de requisição, diário de pagamentos do stub e registros de pedidos somente leitura.
Pessoas: um profissional de QA; desenvolvedor disponível para correções; responsável pelo produto decide o risco residual aceito.
Estimativa, não compromisso: dois dias úteis de 6 horas de QA cada; 2 horas de apoio do desenvolvedor e 1 hora de revisão do responsável.
Entregáveis: mapeamento requisito/caso, log de execução, evidências sanitizadas, defeitos e recomendação de lançamento.Escopo baseado em risco com resultados observáveis
Os casos C01–C08, C11 e C12 são de alto risco neste exemplo: pagamentos duplicados, valor errado, falso sucesso ou erros de repetição podem corromper o estado financeiro. C09–C10 são verificações de usabilidade e também pertencem ao escopo. As expectativas a seguir são requisitos da demonstração, não um comportamento universal de APIs de pagamento.
ID Cenário Esperado
C01 token approved Um pedido confirmado de 1999 centavos; um pagamento aceito
C02 token declined Mensagem de recusa; nenhum pedido pago ou pagamento bem-sucedido
C03 token timeout Pendente/desconhecido exibido; nenhum segundo pagamento automático
C04 mesma chave, mesmo payload duas vezes Mesmo resultado registrado; um pagamento e um pedido
C05 mesma chave, valor alterado Conflito informado; nenhum novo pagamento ou pedido
C06 token de pagamento ausente Erro de campo; nenhuma requisição de pagamento
C07 servidor recebe valor zero Rejeitado pela API; nenhum pagamento ou pedido
C08 callback approved duplicado Uma transição para pago; registro de pagamentos tem um sucesso
C09 apenas teclado Todos os controles acessíveis; envio e erros operáveis sem mouse
C10 viewport de 375 px Sem rolagem horizontal; total e controle de envio visíveis
C11 atualizar página de resultado Pedido existente exibido; pagamento não é reenviado
C12 inspecionar transação de 1999 centavos Interface, requisição e pedido salvo coincidem em valor e moedaCritérios de entrada, suspensão e saída
Entrada: todos os 12 resultados esperados revisados; identificador do build registrado; modos approved/declined/timeout do stub verificados; cliente de teste criado; diário de pagamentos legível; teste smoke do ambiente aprovado. Se algum item de entrada falhar, registre o bloqueio, em vez de classificar o build como totalmente testado.
Suspenda quando o diário estiver indisponível, o ambiente de teste não puder ser reiniciado ou os pagamentos duplicados observados ameaçarem a validade dos casos seguintes. Preserve as evidências. Retome após corrigir a causa, aprovar o teste smoke do ambiente e reiniciar e reexecutar os casos afetados.
Saída para uma recomendação: todos os 12 casos executados com evidências; os 10 casos de alto risco aprovados; C09 e C10 aprovados ou com exceção documentada por um responsável identificado; zero defeitos abertos que causem sucesso duplicado, valor errado ou status de pagamento falso; cada defeito corrigido de alto risco retestado e verificações de regressão afetadas aprovadas. Relate explicitamente qualquer funcionalidade excluída. Um prazo sozinho não satisfaz esses critérios.
Exemplo de cronograma: dia 1 — revisão de requisitos 1h, ambiente/dados 1h, preparação de casos 2h, execução 2h. Dia 2 — execução restante 2h, correções e retestes 2h, regressão afetada 1h, resumo 1h. Se o comportamento do provedor mudar ou o build for substituído, reestime e reexecute as verificações afetadas; não preserve silenciosamente os status antigos de aprovação.
Modelo de plano copiável
Plano / versão / responsável:
Mudança e objetivo de negócio:
Objeto de teste / build / configuração:
Requisitos e principais riscos:
No escopo / fora do escopo:
Ambiente / dados sintéticos / procedimento de reinicialização:
Mecanismos de observação e evidências:
IDs dos casos mapeados para riscos e resultados esperados:
Papéis / capacidade / estimativa / dependências:
Critérios de entrada:
Critérios de suspensão / retomada:
Critérios de saída e responsável pela decisão:
Riscos residuais / exceções / próxima data de revisão:
Link do relatório de execução:Este documento especifica trabalho a fazer; não afirma que os doze casos passaram em uma aplicação real de pagamento. Durante a execução, acrescente resultado real, status, evidências e links de defeitos a cada caso. Envie ao responsável pela decisão de lançamento tanto a cobertura quanto o risco restante, não apenas uma porcentagem de aprovação.
Continuar aprendendo
Relacione um plano de lançamento à estratégia de teste
Organizar testes de lançamento