Use este modelo
Uma documentação de testes sólida é a base de qualquer prática de engenharia de qualidade. Com a Trupeer, pode poupar horas na criação de documentação de testes começando com modelos de documentação de testes gratuitos, personalizando-os com as suas orientações de marca e transformando planos de testes em walkthroughs em vídeo que alinham engenharia, produto e QA.
O que são modelos gratuitos de documentação de testes?
Os modelos gratuitos de documentação de testes são estruturas reutilizáveis para os documentos que um esforço de testes produz: a estratégia, o plano, os casos de teste, os dados, os resultados e os relatórios de defeitos.
A maioria das pesquisas por isso são, na verdade, pesquisas por um único documento. Os casos de teste são aquilo em que os testers passam o tempo a escrever, e um modelo de caso de teste é uma tabela com passos, o que não é difícil.
Os modelos não são o problema. Cada modelo de caso de teste publicado tem as mesmas colunas: identificador, título, pré-condições, passos, resultado esperado, resultado real, estado. Essa estrutura está correta e mantém-se estável há décadas.
O que está errado na maioria dos conjuntos de testes é o equilíbrio do esforço dentro dessa estrutura, e isso produz casos de teste que podem passar enquanto o sistema está avariado.
A forma segue o uso. Um modelo de casos de teste Excel para download gratuito é o formato de trabalho mais comum e adapta-se bem à tabela de casos. Um ficheiro Word com um modelo de caso de teste adapta-se a planos de testes e estratégias, que são texto corrido. Um exemplo de documento de teste em PDF é o que é anexado a um registo de release como evidência.
Os documentos num conjunto de testes
Seis documentos, cada um respondendo a uma pergunta diferente, e vale a pena saber quais é que precisa mesmo antes de adotar qualquer coisa.
Estratégia de testes. Como esta organização testa, em geral. Escreve-se uma vez, revê-se raramente, e aplica-se a projetos.
Plano de testes. O que será testado nesta release ou projeto, em que ambientes, por quem, com quais critérios de entrada e saída e com que calendário.
Casos de teste. As verificações individuais. Passos e, crucialmente, resultados esperados.
Scripts de testes. O equivalente automatizado, em que um caso foi codificado em vez de ser executado por uma pessoa.
Dados de testes. Que dados os casos usam, que é documentação por si só e que é frequentemente a parte menos controlada de todo o conjunto.
Resultados de testes e relatórios de defeitos. O que aconteceu e o que foi reportado. É isto que um exemplo de PDF de documento de caso de teste costuma acabar por ser quando encontra um publicado, já que os resultados são a parte que as organizações retêm.
Qualquer pack de modelos de documentação de testes deve cobrir os seis, e a maioria cobre dois. A maioria das organizações tem o terceiro e o sexto e improvisa o resto. Isso é suportável. O que não é suportável é o terceiro ser escrito mal, porque tudo o que vem a seguir depende dele.
Como personalizar este modelo na Trupeer
Passo 1: Abrir a secção de Modelos
Vá à secção de Modelos no menu de navegação 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.
Dentro do 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.
A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o pretende.
Com modelos de documentação de testes pode:
Poupar horas na escrita: Ignore a página em branco com estruturas usadas por equipas de QA experientes.
Melhorar a cobertura dos testes: Secções integradas garantem que nada importante fica por cobrir.
Manter-se alinhado com a marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.
Uniformizar entre produtos: Use os mesmos modelos para cada release e equipa.
Manter-se pronto para auditorias: Alinhado com a IEEE 829, ISO 29119 e normas semelhantes.
Atingir equipas globais: Traduza a documentação de testes para 65+ idiomas com um clique.
O resultado esperado é o caso de teste
Leia qualquer conjunto de testes e veja onde estão as palavras.
Os passos serão detalhados. Abra a aplicação. Navegue até ao ecrã de pagamentos. Selecione a transação. Clique em Reembolsar. Introduza o valor. Confirme. Sete instruções precisas, cada uma sem ambiguidades.
Depois, veja o resultado esperado. Vai dizer algo como: o reembolso foi processado com sucesso.
Essa linha é o teste inteiro. Tudo o que está acima é preparação. E é a linha que recebeu menos reflexão, porque escrever passos precisos é fácil e definir o que significa “correto” é difícil.
A consequência é que um tester segue sete instruções exatas, vê algo que parece sucesso e marca “passou”. Não fizeram nada de errado. O documento perguntou se o reembolso foi processado com sucesso, viram uma mensagem de sucesso e foi.
O que o documento nunca perguntou foi se foi criado exatamente um reembolso, se o razão foi movido exatamente pelo valor certo, ou se qualquer coisa a jusante recebeu uma duplicação.
Um caso de teste cujo resultado esperado pode ser satisfeito por uma leitura otimista da interface é um caso de teste que vai passar sempre que o tester estiver com pressa, o que é a maior parte do tempo perto de uma release.
Escrever um resultado esperado que pode falhar
Três propriedades, e são fáceis de verificar num conjunto existente.
Nomeia um estado, não uma impressão. Não “o registo é guardado corretamente”, mas “o registo aparece na lista com o estado Ativo e um timestamp de modificação dentro do último minuto”.
É verificável fora daquilo que executou a ação. Esta é a propriedade que apanha os defeitos caros. Se a ação aconteceu na interface do utilizador, o resultado esperado mais forte é um verificado noutro local: na base de dados, num relatório, no sistema a jusante, num extrato. As interfaces são boas a reportar sucesso e más a reportar o que aconteceu realmente por baixo.
Poderia falhar sem o sistema parecer estar avariado. Se a única forma de o teste falhar for um erro visível, o teste só deteta erros que se anunciam. Uma falha silenciosa é aquilo que os casos de teste existem para apanhar e aquilo que resultados esperados vagos falham de forma consistente.
Uma auditoria prática, que demora uma tarde num conjunto de algumas centenas. Leia apenas os resultados esperados, ignorando os passos. Conte quantos poderiam ser satisfeitos apenas observando o ecrã e quantos usam palavras como corretamente, com sucesso, conforme esperado ou sem erro, que não são resultados de todo. Na maioria dos conjuntos, ambas as contagens são elevadas.
O que um modelo de caso de teste tem de conter
Nove campos. O modelo não é o problema e a orientação contra dois destes campos é.
Campo | O que faz |
|---|---|
Identificador | Estável, nunca reutilizado, para que os casos possam ser referenciados em relatórios de defeitos e discussões de cobertura. |
Título | O que está a ser testado, numa frase que alguém poderia pesquisar. |
Prioridade | Porque ninguém corre o conjunto completo e, se não escolher, quem estiver sob pressão vai escolher. |
Pré-condições | Estado, dados e acesso necessários antes do primeiro passo. |
Passos | Uma ação por cada. A parte fácil. |
Resultado esperado | O que tem de ser verdade, onde verificar e formulado de modo a poder falhar. O teste inteiro. |
Resultado real | O que foi observado, preenchido durante a execução, não um visto. |
Estado | Passou, falhou, bloqueado, não executado. Bloqueado e não executado são diferentes e juntá-los esconde lacunas de cobertura. |
Evidência | Screenshot, saída de consulta, referência. Qualquer coisa que mostre o resultado real em vez de o afirmar. |
A distinção entre bloqueado e não executado importa mais do que parece. Um conjunto que reporta noventa por cento de passagens pode ter executado sessenta por cento dos seus casos, e a diferença é invisível se tudo o que não passou for registado da mesma forma.
Modelos gratuitos de documentação de testes: a estrutura para copiar
Preenchidos com um exemplo real em vez de placeholders. O sistema é uma plataforma de processamento de pagamentos.
Copie daqui.
Plano de testes, em resumo. Âmbito: processamento de reembolsos para a release 4.9. Inclui: reembolsos totais, reembolsos parciais, reembolsos contra transações liquidadas e não liquidadas. Fora do âmbito: chargebacks, que permanecem inalterados. Ambientes: staging com volumes de dados semelhantes aos de produção. Critérios de entrada: build implementada, smoke test aprovado, dados de teste carregados. Critérios de saída: todos os casos de prioridade um passaram, não há defeitos abertos de prioridade um ou dois, reconciliação do razão limpa em toda a execução.
Caso de teste.
Identificador: TC-118. Título: Reembolso total contra uma transação liquidada cria exatamente uma entrada de reembolso.
Prioridade: Um.
Pré-condições: Existe uma conta de comerciante M-4471 com uma transação liquidada T-88210 de 240.00. Saldo do razão para M-4471 registado antes de começar. O tester tem permissões para reembolsar.
Passos.
Abra o ecrã de pagamentos e procure T-88210.
Selecione a transação e escolha Reembolsar.
Introduza 240.00 e confirme.
Resultado esperado. Quatro condições, todas as quais têm de se verificar.
Existe um registo de reembolso contra T-88210, e apenas um. Verificado na tabela de reembolsos, não na interface.
O saldo do razão do comerciante para M-4471 diminuiu exatamente 240.00 face ao valor inicial registado. Verificado no relatório do razão.
O extrato do comerciante para o período mostra uma única linha de reembolso de 240.00.
O estado da transação mostra Reembolsado na interface.
Nota: a verificação na interface é a última e é a mais fraca das quatro. Está incluída porque os utilizadores a veem, não porque valida qualquer coisa.
Resultado real: registado na execução, com os valores do razão observados em vez de assumidos.
Estado: pass, fail, blocked ou not run.
Evidência: saída de consulta da tabela de reembolsos e uma cópia da linha do relatório do razão.
Relatório de defeito, se falhar. Identificador do caso, o que era esperado, o que foi observado, ambiente, build, dados usados, passos para reproduzir, severidade. O campo de dados usados é o que mais frequentemente é omitido e o que mais frequentemente impede a reprodução.
Copie para aqui.
Exemplo de documentação de testes: trezentas e trinta e oito passagens
Brayford Payments processa pagamentos com cartão para pequenos comerciantes e emprega cerca de duzentas pessoas. Lançou um fluxo de reembolso revisto.
O módulo de pagamentos tinha trezentos e quarenta casos de teste. O teste de aceitação do utilizador executou o conjunto completo. Trezentas e trinta e oito passagens. Dois falharam, foram corrigidos e foram re-testados.
Em produção, reembolsos acima de um certo valor foram aplicados duas vezes sob uma condição específica de temporização. Funcionou durante nove dias antes de alguém notar, produzindo cerca de catorze centenas de reembolsos duplicados no valor de quatrocentos e doze mil libras. Recuperar dinheiro já pago aos comerciantes foi lento e complicado, e cerca de sessenta por cento voltou.
O caso TC-118 cobria reembolsos. Tinha sete passos detalhados e um resultado esperado que dizia: o reembolso é processado com sucesso.
O tester seguiu os sete passos, viu uma mensagem de confirmação e um estado de Reembolsado, e registou uma passagem. Foi uma aplicação correta do documento que tinha à frente.
Ninguém olhou para o razão. Nada no caso lhes pedia isso. Um reembolso único e um reembolso duplo parecem idênticos no ecrã de confirmação, e é exatamente por isso que a verificação precisava de acontecer noutro local.
A auditoria posterior leu todos os trezentos e quarenta resultados esperados, ignorando os passos.
Duzentas e onze passagens podiam ser satisfeitas observando apenas a interface do utilizador. Quarenta e sete não continham qualquer afirmação verificável, usando frases como funciona como esperado, comporta-se corretamente ou termina sem erro.
A solução foi três semanas de reescrita, não de novos testes. Cada resultado esperado tinha de nomear um estado, dizer onde era verificado e ser capaz de falhar sem um erro visível. Quando a verificação natural estava fora da interface, era aí que ia. Alguns casos foram fundidos e o conjunto ficou reduzido a duzentas e noventa.
Duas releases depois, os defeitos encontrados durante o teste de aceitação do utilizador passaram de uma média de quatro por release para dezanove.
Esse número a subir é o resultado. Os defeitos em produção nos seis meses seguintes passaram de onze para dois.
O conjunto não era demasiado pequeno. Estava a fazer trezentas e quarenta perguntas que o sistema podia responder de forma otimista.
Como escrever casos de teste em seis passos
Escreva o resultado esperado antes dos passos. Inverte a ordem habitual e obriga-o a decidir o que significa “correto” antes de descrever como lá chegar. Os passos escritos depois são mais curtos e mais relevantes.
Diga onde o resultado é verificado. Interface, base de dados, relatório, sistema a jusante. Nomear o local é o que torna um resultado verificável por outra pessoa.
Pergunte como isto poderia passar estando errado. Se conseguir responder, o resultado esperado precisa de outra condição.
Depois escreva os passos, uma ação por cada. São a parte fácil e devem demorar o mínimo de tempo.
Registe as pré-condições incluindo dados. A maioria das falhas de reprodução de um defeito resulta de dados diferentes, e não de passos diferentes.
Priorize com honestidade. Ninguém executa o conjunto completo antes de uma release. Decidir com antecedência quais os casos que importam é melhor do que decidir às nove da noite no dia anterior.
O passo um é o método completo. Os passos dois e três são aquilo que apanha os defeitos que chegam à produção.
Casos de teste versus cenários de teste
Os dois são usados de forma intercambiável e a diferença é o nível.
Um cenário de teste é o que testar, descrito a um nível que qualquer pessoa consiga compreender. Verifique que os reembolsos funcionam corretamente para transações liquidadas. É uma declaração de cobertura.
Um caso de teste é como testá-lo, com dados específicos, passos específicos e um resultado esperado específico. Um cenário costuma gerar vários casos.
A disciplina útil é escrever cenários primeiro, acordar a cobertura com base neles com pessoas que compreendem o negócio e, depois, escrever casos por baixo. Fazer ao contrário produz um conjunto que cobre aquilo em que a pessoa que o escreveu pensou.
Um cenário que produz apenas um caso é, normalmente, um cenário que não foi pensado corretamente. Os reembolsos para transações liquidadas devem gerar casos para o valor total, um valor parcial, um valor superior ao original, uma segunda tentativa de reembolso na mesma transação e um reembolso numa transação que já tinha sido reembolsada. Quatro desses cinco são onde os defeitos vivem.
Estratégia de testes, plano de testes e plano de QA
Três documentos acima dos casos de teste, e as distinções têm peso prático.
Uma estratégia de testes é organizacional e de longa duração. Como testamos, que tipos de testes usamos, quais são os nossos padrões. Aplica-se a projetos e é revista raramente.
Um plano de testes é específico para uma release ou projeto. Âmbito, ambientes, critérios de entrada e saída, calendário, recursos, riscos. Um modelo de plano de testes Excel para download gratuito vai dar-lhe normalmente um calendário e uma matriz, e as secções em texto corrido pertencem a um documento.
Um plano de QA é mais abrangente do que ambos, porque a garantia de qualidade inclui tudo o que é feito para prevenir defeitos em vez de os encontrar: revisão de requisitos, definição de “feito”, padrões de revisão de código, paridade de ambientes. O modelo de plano de QA cobre essa distinção, e isso importa aqui porque um documento intitulado plano de QA que contém apenas fases de teste passou silenciosamente a ser um plano de testes.
O teste prático é a temporização. As atividades que acontecem antes de o trabalho estar feito são garantia. As atividades que acontecem depois são controlo, e os testes são controlo.
O que os modelos gratuitos de documentação de testes não conseguem corrigir
Requisitos que ninguém acordou. Um caso de teste valida o comportamento face a uma expectativa, e quando a expectativa nunca foi definida, os testers escrevem casos com base na sua própria suposição.
Um conjunto demasiado grande para executar. Todas as organizações chegam ao ponto em que o conjunto completo de regressão não cabe na janela. Priorizar deliberadamente vence a priorização sob pressão, e nenhum modelo de casos de teste Excel para download gratuito faz isso por si.
Um resultado esperado vago. Nenhum modelo de caso de teste: o download gratuito e nenhum layout simples de modelo de caso de teste Excel vai escrevê-lo por si, e é o único campo que decide se o caso funciona.
Dados de teste que não representam a produção. O defeito da Brayford exigia uma condição específica de temporização e um volume de dados realista. Nenhum existia no ambiente de teste, e nenhum modelo aborda isso.
Testers sem autoridade para bloquear. Critérios de saída que podem ser dispensados por quem quiser avançar para enviar não são critérios.
Mostre o teste em vez de o descrever
Dois problemas nesta área são o mesmo problema e ambos são sobre evidência.
A evidência de teste é normalmente um visto numa coluna de estado. Alguém executou o caso e diz que passou. Se mais tarde surgir um defeito nessa área, não há forma de estabelecer o que foi realmente observado, por isso a questão de saber se o caso foi executado corretamente não pode ser respondida e normalmente transforma-se num debate.
O segundo problema é que um novo tester a entrar numa equipa aprende o que significa verificar corretamente ao observar alguém, e se ninguém tiver tempo, aprende isso nos documentos, que é de onde vem a leitura otimista.
A Trupeer AI aborda ambos. Registar uma execução de teste produz um walkthrough escrito com screenshots já capturados e colocados, juntamente com o vídeo, na sua própria marca. O que foi realmente observado em cada passo é capturado em vez de ser afirmado, que é a evidência de que um registo de release precisa e o material com que um novo tester aprende.
Registe. Dê marca. Traduza. Faça Trupeer.
Seguem-se dois pontos. Registar um tester experiente a executar um caso complexo mostra as verificações que faz fora da interface, que é exatamente o hábito que os casos escritos falham em transmitir. E quando os testes são feitos entre locais ou por uma equipa subcontratada, o mesmo registo define o mesmo padrão de verificação em vez de o deixar à interpretação.
O material fica na sua base de conhecimento e funciona também como formação para novos testers. Se a release pode ou não avançar é uma questão à parte, abordada no modelo de requisitos de release. 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 um modelo de casos de teste Excel para download gratuito?
O Excel é o formato de trabalho padrão para casos de teste e adapta-se bem, porque um conjunto é uma tabela que filtra por módulo, prioridade e estado. Um modelo de casos de teste Excel para download gratuito vai dar-lhe as colunas padrão e é, de facto, um bom ponto de partida.
Vale a pena fazer duas adições. Uma coluna para registar onde o resultado esperado é verificado, ou seja, interface, base de dados, relatório ou sistema a jusante. E valores de estado separados para bloqueado e não executado, já que juntá-los esconde quanto do conjunto foi realmente executado.
Existe uma versão simples do modelo de caso de teste Excel?
Sim, e o simples é normalmente o certo. Um layout simples de modelo de caso de teste Excel com identificador, título, prioridade, pré-condições, passos, resultado esperado, resultado real e estado cobre quase tudo.
Resista à tentação de adicionar colunas. Os modelos de casos de teste acumulam campos que parecem úteis na fase de design e acabam por ficar em branco na prática, e um conjunto com oito colunas preenchidas é mais útil do que um com vinte, das quais doze estão vazias.
Existe uma versão do modelo de caso de teste Word?
O Word adapta-se melhor aos documentos envolventes do que aos casos. Um ficheiro Word com um modelo de caso de teste funciona para um plano de testes, uma estratégia de testes ou um relatório de resumo, todos eles em texto corrido.
Para os casos em si, um documento não é um bom encaixe. Não o pode filtrar, não o pode ordenar por prioridade e atualizar o estado em duzentos casos numa tabela Word durante uma execução de teste é suficientemente lento para as pessoas deixarem de o fazer com rigor.
Existe um modelo de caso de teste: download gratuito que valha a pena usar?
As colunas mantêm-se estáveis há décadas, por isso um modelo de caso de teste: download gratuito poupa-lhe muito pouco e cada versão publicada é, em grande medida, a mesma.
Avalie qualquer um deles com base numa questão. A coluna de resultado esperado tem alguma orientação associada ou é apenas uma célula em branco? A célula em branco é onde a maioria dos conjuntos de testes falha, e nenhum modelo resolve isso, mas um modelo que pede onde o resultado é verificado vai melhorar o que é escrito nesse campo.
Existe um modelo de plano de testes Excel para download gratuito?
O Excel adapta-se ao calendário, à matriz de cobertura e ao plano de recursos dentro de um plano de testes. Um modelo de plano de testes Excel para download gratuito vai normalmente dar-lhe isso.
A metade narrativa pertence a um documento: âmbito, critérios de entrada e saída, ambientes, pressupostos e riscos. Esses são lidos e negociados, e negociar em células de uma folha de cálculo corre mal. Mantenha ambos e faça referência um ao outro.
Onde posso encontrar um exemplo de PDF de documento de teste?
Os registos de procurement do setor público, projetos universitários e alguns organismos de normas publicam documentação real de testes, e um exemplo de PDF de documento de teste de uma dessas fontes é mais instrutivo do que um modelo comercial porque foi produzido sob restrições reais.
Leia um exemplo de PDF de documento de caso de teste pelos seus resultados esperados, e não pela sua estrutura. A estrutura pode ser copiada de qualquer lugar. Como uma equipa real formulou o que significa “correto” e se as suas verificações estavam fora da interface é a parte que vale a pena aprender.
Onde posso encontrar um exemplo de PDF de documento de caso de teste?
Aplicam-se as mesmas fontes e as indústrias reguladas são as mais ricas, já que a evidência de teste tem de sobreviver a auditorias e tende a ser escrita de forma mais precisa como resultado.
Ao ler um exemplo de PDF de documento de caso de teste, veja se a coluna de resultado real contém observações ou vistos. Os vistos dizem-lhe que o conjunto foi executado. As observações dizem-lhe o que foi visto e apenas a segunda é evidência.
Existe um conjunto de modelos de documentação de testes de software?
Sim, e o conjunto é composto por seis documentos: estratégia, plano, casos, scripts, dados e resultados com relatórios de defeitos. Um pack de modelos de documentação de testes de software vai normalmente cobrir o plano e os casos e deixar o resto.
Os dados de teste são o que mais frequentemente falta e o que mais frequentemente impede que um defeito seja reproduzido. Documentar contra que dados o conjunto é executado e como é atualizado vale tanto como mais cinquenta casos de teste.
