Um plano de testes é um documento curto que responde a cinco perguntas antes de você começar a testar: o que você vai testar, o que vai deixar de fora de propósito, como vai testar, quando considera que terminou e que risco está disposto a aceitar. Essa é a definição completa. Todo o resto que já lhe mostraram com o nome de "plano de testes" (aqueles modelos de duzentas páginas com vinte seções que ninguém abre) é enchimento que atrapalha.
A confusão vem de acreditar que o plano é um trâmite que se entrega para um chefe assinar. Não é. O plano é a resposta escrita a uma decisão que você vai tomar de qualquer forma, queira ou não: onde colocar o esforço limitado que você tem. Se você não a escreve, toma-a mesmo assim, mas às cegas e sem que ninguém possa questioná-la.
Se você não consegue escrever em uma página o que não vai testar, é porque ainda não decidiu o que sim.
01 · o propósitoPara que serve de verdade um plano de testes
O padrão ISO/IEC/IEEE 29119, que é a referência internacional de processos de teste, define o plano como o documento que descreve o escopo, a abordagem, os recursos e o cronograma das atividades de teste. Soa a burocracia, mas cada palavra ali carrega um compromisso real. O escopo é uma fronteira: diz o que entra e o que fica de fora. A abordagem é uma aposta: diz com quais técnicas você vai atacar. Os recursos são um limite: dizem quanto tempo e quantas mãos você tem. O cronograma é uma promessa: diz quando.
O valor do plano não está no papel, está nas conversas que ele obriga você a ter antes de começar. Quando você escreve "não vamos testar o fluxo de pagamentos com cartões internacionais nesta entrega", alguém pode levantar a mão e dizer que isso é justamente o que mais importa. Essa objeção vale ouro, e só aparece se você escreveu a fronteira. Um plano que não provoca nenhuma discussão provavelmente não disse nada arriscado, e portanto não disse nada útil.
Confundem-se o tempo todo. O plano de testes decide a estratégia: quais áreas, com que prioridade, até onde. Os casos de teste são o detalhe tático: as entradas e os resultados esperados concretos. O plano é o mapa; os casos são os passos. Escrever duzentos casos sem um plano é caminhar rápido sem saber para onde.
02 · as peçasO que contém um plano que de fato se lê
Um plano útil cabe em uma página e tem poucas partes, mas nenhuma é opcional. A primeira é o escopo: uma lista curta do que se testa e, com a mesma importância, do que não. A segunda quase sempre é omitida e é a mais valiosa, porque torna explícito o risco que você está aceitando conscientemente.
A segunda peça é a abordagem: quais níveis e tipos de teste você vai usar e em que proporção. Aqui você decide se isto se automatiza ou se explora à mão, se pesa mais o funcional ou o não funcional, onde vai o músculo. A terceira peça são os critérios: o de entrada, que diz quando o sistema está pronto para começar a ser testado, e o de saída, que diz quando você pode parar com a consciência tranquila.
Os critérios de saída são a parte que mais gente pula, e por isso tantas equipes testam até acabar o tempo em vez de até cumprir uma condição. "Paramos quando passarem todos os testes críticos e não restarem defeitos bloqueantes abertos" é um critério. "Paramos na sexta" é uma rendição.
03 · o riscoComo o risco decide onde testar
A pergunta que ordena um plano inteiro é uma só: se isto falhar, quanto dói? Testar tudo com a mesma intensidade é impossível, porque o número de estados e caminhos de qualquer sistema real é enorme. O teste exaustivo é um mito, e um plano honesto começa aceitando isso. O que um bom plano faz é repartir o esforço segundo o risco, não segundo o que seja cômodo de testar.
O risco tem duas dimensões que convém separar: quão provável é que algo falhe e quão grave seria se falhar. Um erro de digitação em um rodapé é provável mas inofensivo. Um erro no cálculo de uma cobrança é menos frequente mas catastrófico. O plano coloca o músculo onde a probabilidade e o impacto se multiplicam alto, e deixa explícito, por escrito, o que decide não cobrir. Essa priorização baseada em risco é o que separa um plano profissional de uma lista de desejos.
É aqui que o plano deixa de ser papelada e se torna uma ferramenta de negociação. Quando um plano diz "com o tempo disponível cobrimos a fundo pagamentos e cadastro, e só fazemos verificação de fumaça do painel de relatórios", está dando a quem decide uma escolha clara: ou aceita esse risco, ou libera mais tempo. Sem plano, essa decisão se toma do mesmo jeito, mas por acidente e sem que ninguém a assine.
04 · a práticaComo escrever um sem morrer na tentativa
Comece pelo escopo em duas colunas: "sim testamos" e "não testamos". Preencha primeiro a da direita, a do que você deixa de fora, porque é a que de verdade define sua aposta. Siga com três ou quatro riscos ordenados por gravidade, e para cada um uma linha de como você vai atacá-lo. Feche com um critério de saída mensurável e com quem faz o quê. Se isso ocupou mais de uma página, sobra texto.
Um plano é um documento vivo, não uma lápide. O próprio ISTQB descreve o planejamento como uma atividade contínua: à medida que aparecem defeitos, mudam prioridades ou se move uma data, o plano se atualiza. Um plano que ficou congelado no primeiro dia e que ninguém voltou a olhar deixou de ser um plano e virou decoração. A utilidade está em revisá-lo quando a realidade contradiz o que você supôs.
E não o escreva para arquivá-lo: escreva-o para provocar a conversa certa antes que ela fique cara. O melhor plano de testes não é o mais completo nem o mais longo. É o que faz com que as decisões difíceis (o que sacrificamos, quanto risco aceitamos, quando paramos) sejam tomadas à luz do dia, por escrito e a tempo, em vez de serem descobertas no dia do incidente em produção.
Fontes
- ISO/IEC/IEEE 29119-3:2021. Software and systems engineering. Software testing. Part 3: Test documentation. International Organization for Standardization. Define a estrutura e o conteúdo do plano de testes e demais documentação de teste. iso.org/standard/79429.html.
- International Software Testing Qualifications Board (ISTQB). Certified Tester Foundation Level Syllabus, v4.0 (2023). Planejamento de teste como atividade contínua, critérios de entrada e saída, e priorização baseada em risco. istqb.org.
- ISO/IEC 25010:2023. Systems and software engineering. SQuaRE. Product quality model. International Organization for Standardization. Marco de características de qualidade que orienta quais qualidades cobrir na abordagem do plano. iso.org/standard/78176.html.
- Myers, G. J., Sandler, C. & Badgett, T. (2011). The Art of Software Testing, 3.ª ed. John Wiley & Sons. Tratamento clássico do planejamento e do teste exaustivo como impossível na prática.