O que é um plano de teste?
Um plano de teste de software descreve o que vai acontecer, quanto tempo vai demorar, quem vai fazer isso, o que será feito e o que esperamos acontecer. Pense nisso como uma forma muito detalhada de realizar o teste de um software para que possamos ter certeza de que cobrimos todos os ângulos. O processo geral de teste de software também possui muitos outros procedimentos formais, mas o plano é por onde começamos.
O plano é muito importante, pois resume o processo de teste. O plano é dividido em partes gerenciáveis para que saibamos como lidar com cada aspecto desse processo. E é um registro de nossos objetivos, para que possamos olhar para trás e ver como nos saímos.
Um exemplo de plano de teste
O formato exato de um plano de teste varia de acordo com a necessidade, mas você pode apostar que existem alguns recursos que você encontrará na maioria dos planos. Aqui estão alguns desses recursos:
- Introdução
- Objetivos
- Escopo
- Estratégia
- Requisitos
- Riscos
- Cronograma
- Funções / Recursos
- Procedimentos
- Obrigações / não obrigatórias
- Marcos / Assinaturas
Introdução
A introdução foi escrita por último. É simplesmente um resumo do plano de teste para dar aos leitores uma ideia de todo o processo.
Objetivos
Como parece, esta seção declara os objetivos (ou metas) do plano. Qualquer avaliação do resultado do plano irá olhar para trás nesta seção para ver como o plano se saiu.
Escopo
Uma grande coisa no mundo do software é o ‘escopo’. Na verdade, significa apenas as principais expectativas que delimitam este plano, para que possamos começar a dividi-lo em etapas gerenciáveis e mensuráveis. Deixar de avaliar o escopo de um projeto pode ser desastroso porque você pode perder grandes problemas, como ter um plano que está indo longe demais para cumprir o cronograma ou ninguém saber ao certo onde ele termina. Saber onde parar é tão importante quanto saber por onde começar, e uma seção de osciloscópio permite avaliar como você está indo.
Estratégia
Este é o seu plano de batalha. A seção de estratégia é uma grande seção dedicada a delinear totalmente a abordagem geral. Assim como o escopo nos diz o quão grande o plano deve ser, a estratégia destaca o que esperamos que aconteça e o que estamos nos preparando para fazer.
Requisitos
Assim como ninguém se prepara para a batalha sem verificar quantas tropas possui, ninguém estabelece um plano de teste sem declarar o que será necessário e garantir que estejam disponíveis. Esses requisitos geralmente incluem equipamentos como computadores e dispositivos periféricos diversos e um local para abrigar essas coisas que seja favorável à execução do plano.
Riscos
Você pode não pensar nos riscos como um requisito, mas deveria. Os riscos são um requisito porque esta é a etapa em que você olha ao redor antes que o inesperado aconteça e forma seus planos de backup. Ao pensar nos riscos, você pode incluir requisitos nos quais talvez não tenha pensado. Planos de backup de emergência às vezes são tão bons quanto ter recursos. Se você pode identificar riscos agora com os quais não consegue imaginar lidar mais tarde, deve repensar sua estratégia.
Cronograma
Como você pode imaginar, a programação é muito importante. Pessoas, tempo e recursos precisam ser cuidadosamente contabilizados em um cronograma realista que nos ajude a estimar a capacidade de execução do plano. A programação também nos ajuda a avaliar nosso progresso e nos adaptar conforme necessário, para que não fiquemos para trás. A data de lançamento do software pode ser muito importante e a última coisa que queremos é atrasar os testes e perder o prazo de Natal.
Funções / Recursos
As funções descrevem o que as pessoas farão, assim como a programação nos diz quando elas farão. As pessoas geralmente são listadas como recursos, assim como qualquer outra necessidade, e esta seção é necessária para esclarecer suas funções e responsabilidades, de modo que nada seja acidentalmente omitido ou duplicado.
Procedimentos
Os procedimentos que serão seguidos estão listados nesta seção, para que tenhamos uma maneira formal de lidar com as ocorrências esperadas e inesperadas. Podem surgir problemas e as pessoas precisarão saber o que fazer e com quem entrar em contato. Pode ser necessário fazer mudanças que serão usadas em planos de teste futuros, portanto, as solicitações de mudança devem ser delineadas para que tenhamos um registro oficial do que funcionou e do que não funcionou.
Obrigações / não obrigatórias
Esta parte lista o que absolutamente deve ser testado, não importa o quê. Também lista o que não nos preocupa muito (mas gostaríamos de verificar se ainda temos tempo!). Geralmente, os recursos são listados aqui e, em seguida, codificados de acordo com sua prioridade para teste. Você simplesmente não pode testar tudo, mesmo se desejar.
Marcos / Assinaturas
Tem que haver uma maneira oficial de dizer ‘Esta parte está feita, vamos fazer a próxima parte’. Caso contrário – assim como uma falta de escopo realista – não há uma maneira tangível de saber quando passar para a próxima coisa e concluir o plano. Marcos indicam conquistas realmente significativas e todos respiram aliviados. Alguém importante assina essa parte e o plano avança para o próximo obstáculo.
Padrão IEEE 829
 |
Como você pode imaginar, também existe um padrão de formatação oficial para planos de teste, chamado IEEE 829. Você pode ver alguns dos detalhes nesta imagem.
Resumo da lição
Um plano de teste de software é exatamente o que parece: um documento bom e detalhado que descreve o processo de teste que pretendemos realizar em todos os seus detalhes cuidadosos. Analisamos rapidamente um modelo de plano de teste padrão e descobrimos algumas das coisas principais que precisamos incluir em um plano de teste, como objetivos, riscos e procedimentos. Agora você tem uma boa ideia do que está envolvido em um plano de teste e pode ver como é vital ter um plano de ação antes de definir esse plano de ação.