Glossário · Fundamentos de testes
Plano de teste
Em inglês: Test plan
Também chamado de: plano de testes, planos de teste, planejamento de testes, test planning
Definição
Documento que define escopo, abordagem, recursos, cronograma, ambientes, riscos e critérios de entrada e saída para testar um release ou projeto.
Um plano de teste (test plan) descreve como os testes serão feitos para um release, projeto ou funcionalidade específicos: o que está dentro e fora do escopo, quais tipos de teste se aplicam, quem faz o quê, onde roda, quando acontece e como o time vai saber que terminou. É o acordo entre QA, desenvolvimento e produto sobre os testes, registrado por escrito antes de a execução começar. O padrão IEEE 829 (hoje substituído pela ISO/IEC/IEEE 29119-3) é o template clássico.
O que um plano de teste útil contém
- Escopo: as funcionalidades no escopo e, tão importante quanto, as que estão explicitamente fora dele.
- Abordagem: níveis e tipos de teste (unitário, API, UI, performance, segurança, acessibilidade) e o que é automatizado versus manual.
- Ambientes e dados: quais ambientes, como a massa de dados é criada ou mascarada, sandboxes de terceiros.
- Critérios de entrada: o que precisa ser verdade antes de os testes começarem, como “build implantado em staging e smoke tests verdes”.
- Critérios de saída: o que significa “pronto”, como “nenhum defeito crítico ou grave em aberto, todos os cenários P1 aprovados, suíte de regressão verde”.
- Riscos e mitigações: por exemplo, “a sandbox de pagamentos é instável, então vamos usar um stub nos testes funcionais e rodar uma verificação end-to-end diária contra a sandbox real”.
- Papéis, cronograma e entregáveis: quem testa o quê, datas-chave e quais relatórios são produzidos.
Plano de teste vs estratégia de teste
Uma estratégia de teste é a abordagem de alto nível e mais duradoura para um produto ou organização: os princípios de teste, níveis, ferramentas e padrões. Um plano de teste aplica essa estratégia a um release ou projeto, com escopo, datas e pessoas concretos. Muitos times ágeis mantêm uma página de estratégia enxuta e um plano curto por release ou épico.
Erros comuns
- Escrever um documento de 40 páginas que ninguém lê. Em times ágeis, um plano de uma página mantido atualizado vale mais do que um exaustivo que já está desatualizado na segunda sprint.
- Critérios de saída vagos. “Testes concluídos” não é mensurável. Declare as condições.
- Nenhuma seção de fora do escopo. Exclusões não declaradas viram discussão depois do release.