O que é um plano de testes? A página que diz o que não vai testar

Um plano de testes é um documento curto que diz o que vai ser testado, o que não vai, por quem, em que ambientes, e o que tem de ser verdade antes de alguém começar ou parar. Escreve-se antes dos testes, e o seu valor principal está no segundo ponto dessa lista.

Enumerar o que se tenciona verificar está ao alcance de qualquer um. Escrever o que se deixa de fora de propósito é a parte que evita a conversa três semanas depois, aquela em que alguém assumiu que uma coisa estava coberta porque ninguém disse que não estava.

O que entra nele

Seis secções carregam quase todo o valor, e cada uma pode ocupar poucas linhas.

• Âmbito. O que esta ronda de testes cobre: que funcionalidades, que versões, que plataformas.
• Fora de âmbito. O que deliberadamente não cobre, e porquê. A secção mais útil e a que mais vezes falta.
• Abordagem. Manual, automatizada, ou a divisão entre as duas, e a que nível.
• Ambientes e dados. Onde corre e contra o quê, que é o que decide o que pode ser encontrado. Um plano que diz “staging” sem dizer que build e que dados não está a dizer grande coisa.
• Critérios de entrada e de saída. O que tem de ser verdade antes de os testes começarem, e o que tem de ser verdade antes de se dizer que acabaram.
• Riscos. O que pode impedir este plano de funcionar, nomeado enquanto dizê-lo é barato.

Alguns planos acrescentam papéis, um calendário e um processo de defeitos. Isso importa mais quantas mais pessoas estiverem envolvidas, e importa muito pouco quando são dois.

É nos critérios de saída que acontecem as discussões

“Terminado” não é óbvio, e um plano que não o define produz uma entrega discutida no próprio dia em vez de acordada de antemão.

Fraco

Todos os erros importantes corrigidos e os testes concluídos

Melhor

Todos os casos da suite de checkout passam, não há defeitos abertos de severidade 1 ou 2, e os três defeitos conhecidos de severidade 3 estão registados com soluções alternativas nas notas de versão

O segundo pode ser verificado por alguém que não estava na sala. O primeiro é um estado de espírito.

O mesmo vale para os critérios de entrada: combinar que os testes começam quando a build passa o seu teste de fumo poupa a quem testa uma tarde a provar de quarenta maneiras que uma build partida está partida.

Que tamanho deve ter

Mais curto do que pensa, e proporcional ao número de pessoas que têm de concordar.

Duas pessoas a testar uma funcionalidade que ambas percebem precisam de um parágrafo, e escrever mais é teatro. Uma entrega regulada com um auditor externo precisa do documento formal, porque alguém de fora da equipa tem de conseguir ler o que foi decidido. A maior parte do trabalho fica entre os dois, e uma página costuma ser a medida certa.

O teste a aplicar: o comportamento de alguém mudaria se esta secção não existisse? Se não, apague-a. Um plano que ninguém lê é pior do que não haver plano, porque cria a convicção de que os testes foram planeados.

Onde fica entre os outros documentos

Um plano está um nível acima das verificações propriamente ditas.

• O plano diz que o fluxo de checkout será testado à mão em Chrome e Safari, e que o telemóvel fica fora de âmbito nesta ronda.
• Os casos de teste dizem exatamente o que fazer e o que deve acontecer.
• A suite de regressão diz o que volta a ser verificado porque antes funcionava.
• Os critérios de aceitação dizem o que a funcionalidade tinha de fazer à partida, e foram escritos antes de tudo o resto.

Confundir o plano com os casos é o erro habitual: um documento que enumera duzentos passos não é um plano, é uma suite com capa.

O processo de defeitos faz parte dele

Uma linha que a maioria dos planos salta, e custa mais do que parece. Diga como um defeito é reportado, para onde vai, e quem decide se trava a entrega.

Sem isso, os achados chegam em três conversas de chat e uma folha de cálculo, quem os junta passa o último dia da ronda a perseguir detalhes, e alguma coisa real perde-se no ruído. Indique o destino e a forma do que lá entra, e ligue para o guia em vez de o repetir: o nosso guia de relatórios de erro existe para ser aquilo a que se liga.

Se quem testa são pessoas cuja profissão não é software, a forma conta mais, não menos. Peça-lhes o que aconteceu e o que esperavam, e deixe a ferramenta carregar a parte técnica.

A versão curta

Uma página: o que está coberto, o que não está, como, onde, o que tem de ser verdade para começar e para parar, e o que pode correr mal. Escrito antes dos testes, acordado pelas pessoas que afeta, e curto o suficiente para que o leiam. A secção que toda a gente salta, a de fora de âmbito, é a que evita a discussão.