QA · Leitura de 7 min

O plano de testes: o documento que quase ninguém lê e todos precisam

Um plano de testes não é burocracia: é a resposta escrita ao que você vai testar, ao que não, ao critério que faz você parar e ao risco que aceita. Sem isso, você testa às cegas.

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.

O plano não é a lista de casos

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.

Figura 1 · o plano em uma página
Escopo · o que SIM e o que NÃO se testa Abordagem · níveis, tipos e automação Critérios · de entrada e de saída Riscos · o que assumimos e por quê Quem e quando · responsáveis e datas
Cinco blocos, uma folha. Se o seu modelo tem vinte seções e você preenche metade com "N/A", essas seções não protegem qualidade: protegem quem pede o formato. Apague o que você não decide.

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.

Figura 2 · a matriz que ordena o esforço
Impacto alto baixo Probabilidade baixa alta Vigiar Esforço máximo Mínimo ou nada Verificação rápida
O quadrante superior direito (grave e provável) leva quase todo o seu tempo. O inferior esquerdo quase nenhum, e isso também é uma decisão legítima que o plano deve declarar em voz alta.

É 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Aprenda mais sobre IA

Ver tudo Aprenda IA