Quantos projetos você conhece que entregaram “no prazo” mas precisaram de meses de correções pós-entrega? Esse padrão quase sempre tem a mesma origem: o teste foi tratado como uma etapa final, comprimida quando o prazo apertou, em vez de planejado desde o início como parte integral do trabalho. O Planejamento de Testes e Inspeções existe para reverter esse comportamento.
O PMBOK Guide, Eighth Edition posiciona o Planejamento de Testes e Inspeções — Test and inspection planning — como uma ferramenta e técnica do processo de planejamento de escopo: a decisão de como testar deve acontecer quando o escopo é definido, não quando a entrega está quase pronta.
Cadastre-se para navegar sem anúncios e participar do Project Together →
Neste guia você vai encontrar:
- O que é Planejamento de Testes e Inspeções e como o PMBOK 8 o define
- Tipos de teste por setor e tipo de projeto
- Como integrar o planejamento de testes ao gerenciamento de escopo
- Critérios de aceitação: a base do planejamento de testes
- Em qual processo do PMBOK 8 é utilizado
- Passo a passo para criar um plano de testes eficaz
- Testes em projetos ágeis: o conceito de Definition of Done
O que é Planejamento de Testes e Inspeções no PMBOK 8?
O PMBOK Guide, Eighth Edition define:
“Test and inspection planning. During the planning phase, the project manager and the project team determine how to test or inspect the product, deliverable, or service to meet the stakeholders’ needs and expectations, as well as how to meet the goal for the product’s performance and reliability. The tests and inspections are industry dependent and can include, for example, alpha and beta tests in software projects, strength tests in construction projects, inspection in manufacturing, and field tests and nondestructive tests in engineering.”
— PMBOK Guide, Eighth Edition, Section 5
Três pontos críticos nessa definição:
- “Durante a fase de planejamento” — não na execução, não antes da entrega. No planejamento.
- “Como testar” — o planejamento define os métodos de teste, não apenas a existência de um “período de testes”
- “Dependente do setor” — o que é um teste adequado varia radicalmente: testes alfa/beta em TI, ensaios de resistência em construção, inspeções não-destrutivas em engenharia
Tipos de teste por setor e tipo de projeto
| Setor / Tipo de projeto | Tipos de teste típicos |
|---|---|
| TI / Software | Teste unitário, teste de integração, teste de sistema, UAT (User Acceptance Testing), teste de regressão, teste de performance, teste de segurança, teste alfa (interno) e beta (usuários reais) |
| Construção civil | Ensaio de resistência à compressão (concreto), teste de carga de fundações, inspeção de soldas, teste de estanqueidade, inspeção de conformidade com normas (ABNT) |
| Manufatura | Inspeção de incoming (matéria-prima), controle estatístico de processo (CEP), inspeção de produto acabado, teste de vida útil, certificação de conformidade |
| Farmacêutico / Regulatório | Validação de processo, qualificação de equipamentos (IQ/OQ/PQ), estabilidade de produto, ensaios clínicos fases I-III, GMP compliance |
| Projetos de serviço | Piloto de serviço, teste com usuário (usability testing), revisão por pares, inspeção de qualidade de processo |
Critérios de aceitação: a base do planejamento de testes
Não é possível planejar um teste sem saber o que constitui “aprovado”. Os critérios de aceitação são a ponte entre o escopo do produto e o planejamento de testes:
- Critérios funcionais: “O sistema deve processar 1.000 transações por segundo sem degradação de performance”
- Critérios de qualidade: “A taxa de defeitos na linha de produção deve ser inferior a 0,1%”
- Critérios de conformidade: “O produto deve atender à norma ISO 9001 e às exigências da ANVISA”
- Critérios de usabilidade: “95% dos usuários em teste devem completar a tarefa principal sem assistência”
Princípio fundamental: critérios de aceitação vagos geram testes vagos e conflitos de aceitação. “O sistema deve ser rápido” é inaceitável como critério — “o sistema deve responder em menos de 2 segundos para 95% das requisições” é testável.
Em qual processo do PMBOK 8 é utilizado?
- 2.2.2.1 — Planejar o gerenciamento do escopo — o planejamento de testes e inspeções é definido durante o planejamento do escopo, garantindo que os requisitos de qualidade e aceitação sejam incorporados ao plano do projeto desde o início, não tratados como atividade separada ao final.
Como integrar o planejamento de testes ao gerenciamento de escopo
O erro mais comum: tratar testes como uma fase separada ao final do projeto. A integração correta:
- Para cada entrega identificada na EAP, defina como ela será testada ou inspecionada — isso faz parte da definição do escopo, não de uma fase posterior
- Os critérios de aceitação devem ser documentados na Declaração do Escopo ou nas Histórias de Usuário (em projetos ágeis) — antes que o trabalho comece
- O plano de gerenciamento de qualidade deve referenciar o planejamento de testes — os dois artefatos são complementares
- O esforço de teste deve ser estimado e incluído no cronograma e orçamento — como qualquer outra atividade do projeto
Passo a passo: criar um plano de testes eficaz
- Identifique todas as entregas que precisam de teste ou inspeção — use a EAP como ponto de partida
- Para cada entrega, defina os critérios de aceitação específicos e mensuráveis — com o cliente ou Product Owner
- Selecione os tipos de teste adequados — baseado no setor, tipo de entrega e perfil de risco
- Defina quem testa — equipe interna, QA independente, cliente, organismo certificador externo?
- Defina quando o teste acontece — ao final de cada sprint, ao final de cada fase, ou continuamente (TDD)?
- Estime o esforço e inclua no cronograma e orçamento — testes sem recursos planejados não acontecem
- Defina o processo de tratamento de defeitos — o que acontece quando um item falha no teste? Re-teste, solicitação de mudança, aceite com restrição?
Planejamento de testes em projetos ágeis: Definition of Done
Em projetos ágeis, o planejamento de testes se manifesta no Definition of Done (DoD) — o conjunto de critérios que devem ser atendidos para que uma história de usuário seja considerada “concluída”. O DoD tipicamente inclui:
Cadastre-se para navegar sem anúncios e participar do Project Together →
- Código revisado (peer review)
- Testes unitários escritos e passando (cobertura mínima definida pelo time)
- Testes de integração passando
- Documentação atualizada
- Aceite do Product Owner
- Deploy em ambiente de staging
O DoD é o “planejamento de testes” do agilismo — definido uma vez para todo o projeto (ou sprint) e aplicado a cada história de usuário. Sem um DoD claro, a velocidade declarada da equipe ágil não reflete qualidade real entregue.
Ferramentas e técnicas relacionadas
- Inspeção — a execução das inspeções que foram planejadas nesta etapa
- Listas de verificação — ferramenta de apoio à execução dos testes e inspeções planejados
- Análise de produto — entender o produto para definir o que e como testar
- Medições do Controle de Qualidade — a saída dos testes planejados aqui
QUIZ
Quer testar o que aprendeu neste artigo?
Uma pergunta de múltipla escolha + uma reflexão prática. Ganhe pontos no Project Together!
