Um bom plano de testes é o que impede que os bugs cheguem à produção. Com a Trupeer, pode poupar horas na planificação de testes começando com um modelo de plano de testes gratuito, personalizando-o com as suas orientações de marca e transformando os planos de testes em walkthroughs em vídeo que alinham engenharia, produto e QA.

O que é um modelo de plano de testes gratuito?

Um modelo de plano de testes gratuito é uma estrutura reutilizável para o documento que indica o que será testado numa determinada versão ou projeto, em que ambientes, por quem, com que calendário e como vai saber que os testes estão concluídos.

A lista de secções é padrão e não suscita controvérsia. Âmbito, abordagem, ambientes, recursos, calendário, critérios de entrada, critérios de saída, riscos, entregáveis. Todos os modelos publicados têm isto e mantém-se amplamente estável desde que as tradições da ISO e da IEEE o estabeleceram há décadas.

O modelo não é onde os planos de testes falham. Falham num momento específico: meses depois de o plano ter sido aprovado, e a falha tem sempre a mesma forma.

O formato segue o uso. Um ficheiro Word de modelo de plano de testes gratuito serve o próprio plano, que é um texto que é revisto e acordado, e para uma versão pequena, um layout simples em Word de um ou dois páginas é suficiente. Uma versão Excel de modelo de plano de testes gratuito serve o calendário, a matriz de cobertura e o dimensionamento de recursos. Um modelo de plano de testes gratuito em PDF é a cópia aprovada anexada ao registo da versão, e um exemplo de PDF de um documento de plano de testes de uma fonte publicada é a melhor forma de ver como se faz corretamente.

Os planos de testes são lidos uma vez e discutidos mais tarde

Um plano de testes é escrito semanas antes de os testes começarem, quando ninguém está sob pressão. É revisto com calma, acordado e arquivado.

Depois é lido novamente numa única ocasião: no dia em que alguém quer avançar com o envio e os testes não estão concluídos.

Nesse momento, toda a gente na sala está envolvida. A data foi comunicada. Os clientes estão à espera. O marketing agendou algo. A equipa de engenharia tem trabalhado para isto há semanas e gostaria que já tivesse terminado. E alguém abre o plano de testes, lê os critérios de saída e descobre que não resolve nada.

Todos os defeitos de alta prioridade resolvidos. A suite de regressão passou. O parecer de UAT foi obtido.

Cada um destes soa firme e nenhum deles se sustenta sob pressão, por razões abordadas na secção seguinte. Assim, a decisão é tomada do modo como sempre teria de ser tomada: por quem é mais sénior e mais envolvido, e o plano de testes fornece um documento para apontar, em vez de ser uma restrição.

O valor de escrever um plano de testes com antecedência é que as decisões tomadas com calma são melhores do que as decisões tomadas às nove da noite numa quinta-feira. Esse valor só se concretiza se as decisões tiverem sido realmente tomadas e, na maioria dos planos, apenas foram descritas.

Como personalizar este modelo na Trupeer

Passo 1: Abrir a secção de Modelos

Vá à secção de Modelos no menu principal.

Passo 2: Selecionar e abrir um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expandir a visualização do modelo

Se necessário, expanda a visualização do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Editar o modelo

Clique em Editar para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guardar o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Guardar para guardar o modelo atualizado como seu.

Passo 6: Pré-visualizar e afinar o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

No ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o pretende.

Com um modelo de plano de testes, pode:

• Poupar horas na escrita: Ignore a página em branco com uma estrutura criada para o QA.

• Melhorar a cobertura dos testes: As secções integradas garantem que nada de crítico fica por testar.

• Manter-se alinhado com a marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.

• Uniformizar entre versões: Use o mesmo modelo de plano de testes para todos os produtos e versões.

• Manter-se pronto para auditorias: Alinhado com a IEEE 829, ISO 29119 e normas semelhantes.

• Atingir equipas globais: Traduza planos de testes para 65+ idiomas com um clique.

Escreva primeiro os critérios de saída e indique quem pode dispensá-los

Duas alterações, ambas baratas, e é isso que constitui o argumento inteiro desta página.

Escreva os critérios de saída antes de qualquer outra coisa no plano. Antes do âmbito, antes da abordagem, antes do calendário. Inverte a ordem habitual e coloca a pergunta mais difícil à frente, quando é uma discussão e não uma negociação. O resto do plano existe para satisfazer os critérios de saída, por isso, decidi-los primeiro também tende a produzir um plano mais curto.

Indique quem pode dispensar cada um. Não a equipa. Uma pessoa, por função, e especificamente não a pessoa cuja função é fazer o envio.

A autoridade para dispensar é a alteração que faz o trabalho. Os critérios de saída quase nunca são substituídos formalmente, porque não existe um mecanismo para os substituir; por isso, são reinterpretados. Um defeito é reclassificado. Um critério é lido com maior flexibilidade. Alguém assina algo que não verificou.

A reinterpretação é invisível e não deixa registo. Uma dispensa é visível, exige uma pessoa identificada para colocar o seu nome e produz algo que pode consultar depois. Essa diferença altera o comportamento antes de alterar qualquer outra coisa, porque reclassificar um defeito numa reunião é fácil e assinar uma dispensa não é.

Adicione mais um campo: quando um critério é dispensado, registe que ação compensatória está a ser tomada. Enviar para dez por cento dos clientes primeiro, ou com um rollback preparado, ou com o suporte informado. Uma dispensa sem compensação é apenas uma decisão de aceitar o risco, que por vezes está correta e, pelo menos, deve ser declarada como tal.

Tornar os critérios de saída exequíveis

Três propriedades e a maioria dos critérios publicados não tem nenhuma delas.

Um número. Não “suite de regressão passou”, mas “suite de regressão: cem por cento dos casos de prioridade um executados, noventa e cinco por cento passaram, zero falhas de prioridade um em aberto”. “Passou” e “executado” são coisas diferentes, e um plano que não os distingue vai reportar noventa por cento “passou” numa suite que foi executada apenas a sessenta por cento.

Um verificador que não é a pessoa sob pressão. A classificação de severidade é o ponto fraco em todos os processos de testes, porque as pessoas que classificam os defeitos são frequentemente as mesmas que querem fazer o envio. Indicar quem atribui a severidade e garantir que é alguém fora da linha de entrega remove a rota mais fácil para contornar um critério.

Uma autoridade de dispensa identificada. Como acima, e deve ser uma pessoa diferente do responsável pela versão.

Uma auditoria útil num plano existente. Leia os critérios de saída e pergunte, para cada um, o que alguém teria de fazer para contorná-los sem mentir. Se a resposta estiver disponível em menos de dez segundos, o critério precisa de um número e de um verificador.

O que um modelo de plano de testes tem de conter

Dez componentes, com critérios de saída primeiro.

As linhas de ambientes e dados de teste merecem mais espaço do que os modelos lhes dão. Muitos dos defeitos que chegam à produção não foram ignorados por casos de teste fracos. Eram inalcançáveis, porque o ambiente de testes tinha mil registos quando a produção tem quatro milhões, ou porque a condição de timing que os desencadeia não pode ocorrer numa única máquina.

Modelo de plano de testes gratuito: a estrutura para copiar

Preenchido com um exemplo real em vez de placeholders. O sistema é software de ponto de venda para mercearias.

Copie daqui.

Critérios de saída. Escrito primeiro, com números, verificadores e autoridade para dispensar.

As dispensas são registadas por escrito com a ação compensatória, antes da versão, e não depois.

Critérios de entrada. Versão instalada no staging. Teste de smoke aprovado. Dados de teste carregados e atualizados. Sem defeitos de prioridade um em aberto do ciclo anterior.

Âmbito. Inclui: transações de caixa, reembolsos, reconciliação do fim do dia, modo offline e o novo motor de promoções. Fora do âmbito: o conjunto de relatórios do back office, que não muda nesta versão; certificação de hardware para novos periféricos, que segue separadamente; e integrações com fornecedores terceiros de fidelização, que são cobertas pelos testes do respetivo fornecedor e são aceites com base nisso, o que é um risco registado abaixo.

Abordagem. Regressão automatizada para os caminhos existentes de caixa e reembolso. Testes exploratórios manuais no motor de promoções, que é novo. Testes de desempenho no pico simulado. O modo offline é testado desligando fisicamente, e não por simulação.

Ambientes. Staging, com uma base de dados restaurada a partir de um snapshot de produção de um grande conjunto de lojas. Quatro caixas físicas de duas gerações de hardware. Nota: o staging tem um único servidor de aplicação, enquanto a produção tem seis, pelo que o comportamento de balanceamento de carga não é representado e este é um risco declarado.

Dados de teste. Snapshot de produção, anonimizado, atualizado semanalmente. Inclui pelo menos uma loja com mais de cinquenta mil transações históricas, uma vez que defeitos relacionados com volume surgiram antes.

Calendário e janela. Três semanas. Execução estimada: onze dias de esforço para dois testers, o que corresponde a catorze dias úteis face a uma janela de quinze dias. Um dia de contingência, que é reduzido e é registado como risco.

Recursos. Dois testers, a tempo inteiro. Um engenheiro de desempenho durante três dias. Responsável de negócio durante dois dias de UAT. Se qualquer um dos testers for chamado para suporte, a janela não se mantém e o critério dois é o primeiro a ficar em risco.

Riscos. Um único servidor de aplicação no staging. Um dia de contingência no calendário. Integração de fidelização de terceiro não testada por nós. O responsável de negócio é novo no cargo.

Entregáveis. Resultados de testes executados com evidência, relatórios de defeitos, um relatório de resumo de testes e o registo de dispensa assinado, se existir.

Copie daqui.

Exemplo de plano de testes: três defeitos de alta prioridade que se tornaram dois

A Danecroft Retail Systems fornece software de ponto de venda para mercearias e emprega cerca de cento e oitenta pessoas. Lançou uma versão principal para um conjunto de trezentas e quarenta lojas.

O plano de testes era normal. Os seus critérios de saída eram: todos os defeitos de alta prioridade resolvidos, a suite de regressão passou, a aprovação de UAT foi obtida.

No dia da decisão de versão, havia três defeitos de alta prioridade em aberto. A suite de regressão foi executada a noventa e um por cento e o plano não distinguia executado de passado. O UAT tinha sido assinado por um responsável de produto que estava no cargo há cinco semanas.

O gestor de versão levou o assunto ao CTO. O CTO perguntou se os três defeitos eram realmente de alta prioridade.

Dois foram reclassificados para média durante essa reunião. O terceiro foi aceite com base no facto de existir uma solução alternativa.

Ninguém tinha mentido e ninguém tinha substituído nada. O plano não tinha uma definição de alta prioridade, não dizia quem atribui a severidade, não tinha um limite para a execução da regressão e não indicava uma autoridade de dispensa identificada. Não havia nada para substituir, por isso não havia nada para registar.

Um dos dois defeitos reclassificados causou congelamentos de caixas sob uma condição específica de promoções. Apareceu no pico de vendas num sábado em todo o conjunto. O retalhista estimou vendas perdidas em cerca de oitocentos e noventa mil libras, aplicou uma penalização contratual e a Danecroft creditou vários meses de taxas.

A revisão identificou três fragilidades específicas, todas nos critérios de saída e nenhuma nos testes.

A severidade foi atribuída pelas pessoas sob pressão para fazer o envio. “Passou” e “executado” foram usados de forma intercambiável, pelo que noventa e um por cento soou como uma taxa de aprovação. E a aprovação não nomeava nenhum indivíduo nem especificava nada sobre o que estavam a confirmar que tinham feito.

A reescrita deu a cada critério um número, indicou um verificador fora da linha de entrega, indicou uma autoridade de dispensa que não era o gestor de versão e exigiu dispensas por escrito com uma ação compensatória.

Nas seis versões seguintes, foram emitidas duas dispensas. Ambas foram registadas, ambas incluíram uma ação compensatória e nenhum defeito foi reclassificado durante uma reunião de decisão de versão.

Os testes tinham sido adequados. O plano não tinha fornecido nenhum mecanismo para os testes terem impacto.

Como escrever um plano de testes em seis passos

1. Escreva primeiro os critérios de saída, com números, antes de qualquer outra coisa no documento.

2. Indique um verificador para cada um, e certifique-se de que não é alguém cujos objetivos incluem a data de envio.

3. Indique uma autoridade de dispensa para cada um, incluindo os critérios que não podem ser dispensados de forma alguma. Ter pelo menos um que não pode ser dispensado é o que torna os outros significativos.

4. Escreva o âmbito, incluindo o que está fora, e diga por que cada exclusão é aceitável.

5. Descreva o ambiente com honestidade, especialmente onde difere da produção de formas que possam ocultar defeitos.

6. Faça a aritmética do calendário e registe a contingência, para que, quando a janela se comprimir, a conversa seja sobre quais critérios estão em risco e não sobre se os testes estão quase concluídos.

O terceiro passo é o que muda os resultados. Um plano em que tudo pode ser dispensado pela pessoa que faz o envio é uma descrição de intenções.

Âmbito e o que não está a testar

A secção “fora do âmbito” é a segunda parte mais valiosa de um plano de testes e, na maioria dos casos, fica com uma única linha.

Três categorias devem estar lá e são diferentes.

Excluído deliberadamente porque está inalterado. Razoável e vale a pena declarar com a razão, porque “inalterado” é uma suposição que, por vezes, acaba por estar errada.

Excluído porque outra pessoa o testa. Componentes de terceiros, integrações com fornecedores, certificação de hardware. Indique quem o está a testar e que evidência está a aceitar. É aqui que o risco é transferido em silêncio.

Excluído porque não pode ser testado aqui. Comportamento de balanceamento de carga, redes reais de pagamentos, volumes de dados de produção, concorrência genuína. Estas são as honestas e devem aparecer na secção de riscos, bem como na secção de âmbito, porque identificam os defeitos que o seu processo não consegue detetar.

A terceira categoria é a que prevê incidentes em produção. Uma equipa que consegue listar o que os seus testes não conseguem alcançar é uma equipa que sabe onde procurar quando algo corre mal.

Plano de testes, estratégia de testes ou caso de teste?

Três níveis e a confusão entre eles é suficientemente comum para valer a pena dizer de forma clara.

Uma estratégia de testes é organizacional. Como esta empresa testa, que tipos de testes utiliza, que normas se aplicam. Escrito uma vez, aplica-se a projetos.

Um plano de testes é específico para uma versão ou projeto. Esta página.

Um caso de teste é uma verificação, com passos e um resultado esperado. A página de modelos de documentação de testes aborda isso, incluindo por que razão o resultado esperado é onde a maioria das suites de testes falha.

Acima de tudo está o plano de QA, que cobre tudo o que é feito para prevenir defeitos em vez de os detetar: revisão de requisitos, definição de “feito” (definition of done), normas de revisão de código. O modelo de plano de QA cobre essa distinção. Se o seu plano de QA contiver apenas testes, escreveu um plano de testes com um título mais abrangente.

Se a versão pode ser enviada ou não é uma questão mais ampla do que saber se os testes estão concluídos, uma vez que documentação, prontidão do suporte e configuração de faturação também funcionam como “portões”. O modelo de requisitos de versão cobre isso.

Variantes de plano de testes

A estrutura mantém-se e a ênfase muda.

Planos de testes ágeis ou por sprint. Normalmente muito mais curtos, muitas vezes uma única página, e frequentemente incorporados na definição de “feito”. O argumento dos critérios de saída aplica-se sem alterações e importa mais, porque a decisão se repete a cada sprint.

Planos de teste de aceitação do utilizador. O critério de saída é uma pessoa a assinar algo, por isso indique o que está a confirmar que fez pessoalmente. Uma assinatura num documento que ninguém leu é o controlo mais fraco no uso comum.

Planos de testes de desempenho e carga. Os limites são naturalmente numéricos, o que torna estes os planos mais fáceis de escrever com critérios exequíveis. A dificuldade passa a ser se o ambiente consegue gerar uma carga representativa.

Ambientes regulamentados e validados. Em contextos farmacêuticos, de dispositivos médicos e semelhantes, existem requisitos definidos para documentação de testes, rastreabilidade e aprovação, e o plano faz parte de um pacote de evidência que pode ser inspecionado anos mais tarde. Construa de acordo com a norma aplicável com contributos qualificados, uma vez que nada nesta página substitui isso.

Sistemas de hardware e integrados. Os planos de testes têm de cobrir configurações físicas e condições ambientais, e a secção de ambientes costuma tornar-se a parte mais longa do documento.

O que um modelo de plano de testes gratuito não consegue resolver

Uma data que não pode mudar. Se a versão vai avançar independentemente, o plano documenta o que foi ignorado em vez de o impedir. Por vezes, é uma decisão legítima do negócio e deve ser declarada, em vez de ser disfarçada como um critério “passou”.

Um ambiente que não consegue revelar o defeito. Nenhum download gratuito de modelo de plano de testes gratuito lhe vai dar volumes de dados de produção ou concorrência real.

Severidade atribuída pela parte interessada. A forma mais comum de contornar os critérios de saída e é uma escolha de governação, não uma questão de documentação.

Uma janela que nunca foi realista. Fazer a aritmética no plano, pelo menos, torna a falta visível enquanto ainda há tempo para mudar algo.

Mostre que os testes aconteceram

Os critérios de saída dependem de evidência e, na maioria das organizações, a evidência é uma coluna de estado.

A suite de regressão foi executada. Alguém marcou os casos. Se cada caso foi executado como estava escrito e o que foi observado de facto, não fica registado em lado nenhum, o que significa que um critério que diz “cem por cento executado” assenta numa afirmação e não num registo. Após um incidente, é essa afirmação que é examinada e, normalmente, não pode ser comprovada de um modo ou de outro.

A Trupeer AI produz o registo como subproduto. Registar uma execução de testes gera um walkthrough escrito com screenshots já capturados e colocados, juntamente com o vídeo, na sua própria marca. O que foi observado em cada passo existe, em vez de ser apenas afirmado, e é isso que um verificador precisa para assinar um critério com honestidade.

Registe. Dê marca. Traduza. Trupeer.

Há dois pontos a seguir. Quando os testes são feitos por uma equipa externa ou offshore, a evidência do que foi realmente feito vale mais do que um relatório de estado, e uma gravação é a forma mais barata de o obter. E uma gravação de um tester experiente a trabalhar um cenário complexo é como um novo tester aprende como é que verificar corretamente deve ser, que é um hábito que nenhum caso escrito transmite.

O material fica na sua base de conhecimento e serve também como formação. A consistência entre os seus documentos é uma questão de definir o kit de marca uma vez e a configuração é coberta no guia de configuração do modelo de documento.

Perguntas Frequentes

Existe uma versão Word gratuita do modelo de plano de testes?

O Word serve o próprio plano, porque a maior parte dele é um texto que é revisto e acordado e, além disso, normalmente precisa de aprovação. Um ficheiro Word de modelo de plano de testes é o formato de trabalho certo.

Coloque a tabela de critérios de saída na primeira página. Todos os modelos os colocam perto do fim, que é onde são lidos por último durante a elaboração e onde recebem menos atenção, e são a única parte do documento que alguma vez será usada sob pressão.

Existe uma versão Word simples do modelo de plano de testes?

Sim, e para uma versão pequena ou um único sprint, um ficheiro Word simples de modelo de plano de testes com uma ou duas páginas é totalmente adequado.

Corte as secções de abordagem e recursos antes de cortar os critérios de saída. Um plano de uma página com critérios numéricos, um verificador identificado e uma autoridade de dispensa vale mais do que um plano de quinze páginas sem eles.

Existe uma versão Excel gratuita do modelo de plano de testes?

O Excel serve as partes do plano de testes que são tabelares: o calendário, a matriz de cobertura, a alocação de recursos e a própria tabela de critérios de saída. Um ficheiro Excel de modelo de plano de testes trata disso bem.

As secções de âmbito, abordagem e riscos são texto e pertencem a um documento. Dividir um plano por dois ficheiros é aceitável desde que um faça referência ao outro e apenas um deles seja a versão aprovada.

Existe um PDF gratuito do modelo de plano de testes?

O PDF é a cópia aprovada anexada ao registo da versão. Exporte um PDF gratuito de modelo de plano de testes uma vez acordado, com a versão e a data, e mantenha-o junto dos resultados e de qualquer registo de dispensa.

Esse conjunto é o que é analisado se algo correr mal mais tarde, e o registo de dispensa é a parte que as pessoas gostariam de ter. Um plano sem registo do que foi dispensado deixa toda a gente a reconstruir uma reunião a partir da memória.

Onde posso encontrar um exemplo em PDF de um documento de plano de testes?

As universidades, as compras do setor público e as indústrias regulamentadas publicam exemplos reais e um exemplo em PDF de um documento de plano de testes dessas fontes é mais útil do que um modelo comercial, porque foi escrito com restrições reais e muitas vezes foi revisto por alguém com autoridade.

Leia os critérios de saída e a secção fora do âmbito. Estas duas mostram se o plano é um controlo ou uma formalidade e são as secções que mais diferem entre organizações que enviam com fiabilidade e aquelas que não o fazem.

Existe um download gratuito do modelo de plano de testes que valha a pena usar?

A lista de secções mantém-se estável há décadas, por isso um download gratuito de modelo de plano de testes poupa-lhe pouco e cada versão oferece, mais ou menos, a mesma estrutura.

Avalie qualquer um deles com uma pergunta. Os critérios de saída têm espaço para um limite, um verificador e uma autoridade de dispensa? Nenhum tem. Adicionar essas três colunas demora dois minutos e é a diferença entre um plano que decide algo e um plano que descreve uma intenção.

O que os critérios de saída devem dizer, na prática?

Números, verificadores e autoridade de dispensa. Não “suite de regressão passou”, mas “cem por cento dos casos de prioridade um executados e aprovados, verificado pelo líder de QA, não dispensável”.

O teste é se alguém consegue satisfazer o critério sem fazer o trabalho e sem mentir. Se um defeito puder ser reclassificado, uma percentagem pode ser lida como taxa de aprovação, ou uma assinatura pode ser dada por alguém que não verificou nada, então o critério tem uma rota para contornar isso e precisa de outra cláusula.

Quem deve escrever o plano de testes?

Quem lidera os testes, com os critérios de saída acordados por alguém que não é responsável pela data de envio. Essa separação é o ponto e é por isso que os planos escritos inteiramente dentro de uma equipa de entrega tendem a ter critérios “flexíveis”.

Peça ao responsável de negócio para ler especificamente os critérios de saída, uma vez que um deles normalmente depende da assinatura e eles devem saber com antecedência o que vão confirmar que fizeram pessoalmente.