Plano de teste de software

A finalidade do plano de teste é comunicar o propósito das atividades de teste. É fundamental criar esse documento o mais cedo possível. Gerar esse artefato logo em uma das primeiras iterações da fase de Elaboração não seria de forma alguma prematuro. Convém desenvolver um plano de teste iterativamente, adicionando seções à medida que as informações forem disponibilizadas.

É necessário tomar cuidado para comunicar claramente o escopo do teste, os requisitos de teste, as estratégias de teste e os recursos necessários. Essas informações identificam a finalidade e as fronteiras do esforço de teste, o que será testado, como isso será testado e os recursos necessários para o teste. A exposição explícita dessas informações agilizará a revisão, os comentários e a aprovação do esforço de teste.

No início do projeto, é necessário criar um plano de teste que identifique todos os testes desejados do projeto, denominado o "Plano de Teste Principal". À medida que se planeja cada iteração, cria-se um "Plano de Teste de Iteração" (ou vários planos de teste, organizados por tipo de teste), que contém apenas os dados (requisitos de teste, estratégias de teste, recursos etc.) pertinentes à iteração. Essas informações também poderão ser incluídas no Plano de Iteração, se isso não dificultar muito o gerenciamento ou o uso do plano de iteração.

Ocorrência

Um Plano de Teste inicial, geralmente conhecido como "Mestre", pode ser criado durante a fase de Iniciação. Essa instância do Plano de Teste oferece uma visão geral do esforço de teste realizado durante o projeto, e uma previsão de quando haverá necessidade de recursos, como também do momento em que importantes aspectos de qualidade e risco serão observados.

À medida que cada iteração é planejada, um ou mais Planos de Teste de "Iteração" específicos são criados fornecendo informações específicas à iteração.

Responsabilidade

O papel Gerente de Testes é o principal responsável por este artefato. As responsabilidades são divididas em duas áreas principais:

     - o principal conjunto de responsabilidades aborda as seguintes questões de gerenciamento para garantir que o Plano de Teste:

          - reflita a Missão de Avaliação do esforço de teste em determinada programação;

          - seja motivado por aspectos considerados úteis e frutíferos para a avaliação de determinada programação;

          - represente uma abordagem possível para avaliação;

          - seja aceito pelos envolvidos;

          - tenha suas mudanças controladas e comunicadas aos papéis relacionados;

          - seja seguido pelos membros da equipe de teste;

     - o conjunto secundário de responsabilidades abrange questões de definição para garantir que o Plano de Teste:

          - identifique os Itens de Teste-alvo adequados de determinada programação;

          - reflita uma abordagem adequada e possível para a avaliação;

          - considere a amplitude e o detalhamento dos riscos de qualidade;

          - identifique precisamente os recursos humanos e os recursos de hardware e software necessários. 

Adaptação

Em certas culturas de teste, os Planos de Teste são considerados informais, artefatos casuais, enquanto em outras, eles são altamente formalizados e, com frequência, precisam de autorização externa. Portanto, o formato e o conteúdo dos Planos de Teste devem variar para atender às necessidades específicas de uma organização ou de um projeto. Comece por considerar o template do Plano de Teste incluído com o RUP e adicione, modifique ou remova os elementos do formato caso seja necessário.

Como uma alternativa à documentação formal, você talvez prefira apenas registrar os elementos do Plano de Teste da iteração como anotações informais de planejamento, possivelmente mantidas em um site da Web na intranet ou no quadro branco prontamente visível e acessível à equipe de teste.

Recomenda-se criar Planos de Teste menores que abordem o escopo de uma única iteração. Esses Planos de Teste devem conter as informações relacionadas aos Motivadores de Teste (por exemplo, um subconjunto de requisitos, riscos), às idéias, às estratégias, aos recursos e outros elementos específicos e relevantes a determinada iteração.

Opcionalmente um Plano de Teste "Mestre" pode ser criado no início do projeto para esboçar o esforço de teste planejado para o curso do projeto, e também para definir os requisitos de recursos e outras questões logísticas. Esse Plano de Teste Mestre também permite limitar a repetição de elementos comuns a todos os Planos de Teste como, por exemplo, os recursos humanos e também de hardware e software, procedimentos de gerenciamento e outros. Recomenda-se não documentar informações de teste detalhadas e específicas no Plano de Teste.

Identificação dos requisitos de teste

Os requisitos de teste identificam o que será testado. Eles são o objetivo específico de um teste. Há algumas regras gerais que se aplicam à geração de requisitos de teste:

     - o requisito de teste deve ser um comportamento mensurável e observável. Se não for possível observar nem medir o requisito de teste, ele não poderá ser avaliado para determinar se foi atendido;

     - não há um relacionamento um-para-um entre cada caso de uso ou requisito suplementar de um sistema e um requisito de teste. Geralmente, os casos de uso têm mais de um requisito de teste, enquanto alguns requisitos suplementares geram um ou mais requisitos de teste e outros não geram nenhum (como requisitos de marketing ou de embalagem).

Os requisitos de teste podem ser derivados de várias fontes, inclusive casos de uso, modelos de caso de uso, especificações suplementares, requisitos de design, casos de negócios, entrevistas com usuários finais e o documento da arquitetura de software. Todas essas fontes devem ser examinadas a fim de coletar as informações utilizadas para identificar os requisitos de teste. 

Requisitos de Testes Funcionais

Os requisitos de teste funcional, como diz o nome, são derivados de descrições dos comportamentos funcionais do objetivo do teste. Cada caso de uso deve gerar pelo menos um requisito de teste. Uma lista mais detalhada dos requisitos de teste incluiria pelo menos um requisito de teste para cada um dos fluxos de eventos de cada caso de uso. 

Requisitos de Testes de Desempenho

Os requisitos de teste de desempenho são derivados dos comportamentos especificados do desempenho do objetivo do teste. Geralmente, o desempenho é especificado como uma medida do tempo de resposta e/ou uso de recursos, medidos sob várias condições, considerando:

     - diferentes cargas de trabalho e/ou condições do sistema;

     - diferentes casos de uso;

     - diferentes configurações.

Os requisitos de desempenho são descritos nas Especificações Suplementares. Examine esse material, prestando atenção especial a:

     - sentenças de tempo, como tempo de resposta ou perfis de tempo;

     - sentenças que indiquem que vários eventos ou casos de uso devem ocorrer em um período de tempo estabelecido;

     - sentenças que comparam o comportamento de um item com o de outro;

     - sentenças que comparam o comportamento do aplicativo em uma configuração com o seu comportamento em outra configuração;

     - confiabilidade operacional (tempo médio de tolerância à falha ou TMTF) ao longo de um período de tempo;

     - configurações ou restrições.

Para cada sentença da especificação, você deve gerar pelo menos um requisito de teste que reflita informações como as listadas acima. 

Requisitos de Testes de Confiabilidade 

Os requisitos de teste de confiabilidade são derivados de várias fontes, geralmente descritas nas Especificações Suplementares, no Guia de Interface do Usuário, no Guia de Design e no Guia de Programação.

Examine esses artefatos e preste atenção especial a:

     - sentenças sobre confiabilidade ou resistência a falhas e erros em tempo de execução (como, por exemplo, "memory leaks");

     - sentenças que indiquem a integridade e a estrutura do código (conformidade com linguagem e sintaxe);

     - sentenças sobre o uso de recursos.

Pelo menos um requisito de teste deve ser derivado de cada sentença de artefatos que reflita as informações listadas acima.

Para o êxito do teste, o esforço de teste deve equilibrar fatores como riscos e restrições de recursos. Para fazer isso, o esforço de teste deve ser priorizado de forma que os componentes ou os casos de uso mais importantes, mais significativos ou que apresentem mais riscos sejam testados em primeiro lugar. Para priorizar o esforço de teste, uma avaliação dos riscos e do perfil operacional é executada e usada como base para o estabelecimento da prioridade de teste.

Avaliar o Risco e Estabelecer Prioridades de Teste 

Identificar os requisitos de teste é apenas uma parte da identificação do que será testado. Também é necessário priorizar o que será testado e em que ordem. Esse passo é realizado por diversos motivos, dentre eles:

     - garantir que os esforços de teste concentrem-se nos requisitos de teste mais adequados;

     - garantir que os requisitos de teste mais críticos, mais importantes ou que apresentem os maiores riscos sejam abordados o mais breve possível;

     - garantir que quaisquer dependências (sequência, dados etc.) sejam consideradas no teste.

A avaliação do risco e o estabelecimento das prioridades de teste são realizados em três passos:

     - Avaliar o Risco;

     - Determinar o Perfil Operacional;

     - Estabelecer a Prioridade do Teste. 

Avaliar o Risco

Estabelecer a prioridade do teste começa com a avaliação do risco. Os casos de uso ou os componentes que apresentam o maior risco em decorrência de falhas ou que apresentam uma alta probabilidade de falha devem estar entre os primeiros casos de uso a serem testados.

Comece identificando e descrevendo os indicadores de magnitude do risco que serão usados como, por exemplo:

     A - risco alto, não tolerável. Séria exposição externa. A empresa sofrerá grandes perdas financeiras, punições ou perda irrecuperável de reputação;

     M - risco médio, tolerável, mas desaconselhável. Exposição externa mínima. A empresa poderá sofrer perdas financeiras, mas suas punições e perda de reputação serão limitadas;

     B - risco baixo, tolerável. Pouca ou nenhuma exposição externa. A empresa terá pouca ou nenhuma perda financeira ou punição. A reputação da empresa não será afetada.

Após identificar os indicadores de magnitude do risco, liste cada caso de uso ou componente no objetivo do teste. Para cada caso de uso ou componente listado, identifique um indicador de magnitude do risco e justifique (com uma breve explicação) o valor selecionado.

O risco pode ser avaliado de três perspectivas:

     - efeito - o impacto ou a consequência da falha de um caso de uso (requisito etc.) especificado;

     - causa - um resultado indesejado decorrente da falha de um caso de uso;

     - probabilidade - a probabilidade de um caso de uso falhar.

Selecione uma perspectiva, identifique um indicador de magnitude do risco e justifique sua seleção. Não é necessário identificar um indicador para cada perspectiva de risco. No entanto, se um indicador baixo for identificado, convém tentar avaliar o item de uma perspectiva de risco diferente, para garantir que ele constitua realmente um risco baixo.

Para avaliar o risco pelo Efeito, identifique um evento, uma condição ou uma ação e tente determinar o seu impacto. Faça a seguinte pergunta:

     "O que aconteceria se ___________?"

Por exemplo:

     "O que aconteceria se o sistema ficasse sem espaço em disco durante a instalação do novo software?"

     "O que aconteceria se a conexão com a Internet fosse perdida durante uma transação de pesquisa?"

     "O que aconteceria se a conexão com a Internet fosse perdida durante uma transação de compra?"

     "O que aconteceria se o usuário inserisse um valor inesperado?"

Causa

Avaliar o risco pela Causa é o oposto de avaliá-lo pelo Efeito. Comece definindo uma condição ou um evento indesejado e identifique o conjunto de eventos que poderiam ter permitido a existência da condição. Faça uma pergunta como esta:

     "Como é possível ___________ acontecer?

Por exemplo:

     "Como é possível que apenas alguns dos arquivos estejam no sistema e que nem todas as entradas tenham sido feitas no Registro?"

     "Como é possível que uma transação não esteja refletida corretamente no banco de dados central?

     "Como é possível que o extrato do ciclo de cobrança reflita apenas alguns dos registros do banco de dados que atendem aos critérios desejados?"

Probabilidade

Avaliar o risco pela Probabilidade significa determinar a probabilidade de falha de um caso de uso (ou de um componente que esteja implementando um caso de uso). Geralmente, a probabilidade se baseia em fatores externos como, por exemplo:

     - densidade e/ou taxa(s) de falhas;

     - taxa de mudança;

     - complexidade;

     - Origem/Originador.

Observe que, quando essa perspectiva de risco é usada, os indicadores de magnitude do risco estão relacionados à probabilidade de uma falha e não ao efeito ou ao impacto da falha sobre a organização, como acontece na avaliação do risco pelo Efeito ou pela Causa.

Por exemplo:

     Instalação do novo software.
     "Historicamente, temos encontrado vários defeitos nos componentes usados para implementar os casos de uso 1, 10 e 12, e os nossos clientes solicitaram diversas mudanças nos casos de uso 14 e 19."

Determinar o Perfil Operacional

O próximo passo na avaliação do risco e no estabelecimento de uma prioridade de teste é determinar o perfil operacional do objetivo do teste.

Comece identificando e descrevendo os indicadores de magnitude do perfil operacional que serão usados como, por exemplo:

     A - usado com bastante frequência, muitas vezes por período ou por muitos atores ou casos de uso;

     M - usado com frequência, várias vezes por período ou por vários atores ou casos de uso;
     B - usado com pouca frequência ou usado por poucos atores ou casos de uso.

O indicador do perfil operacional selecionado deve basear-se na frequência com que um caso de uso ou o componente é executado, incluindo:

     - o número de vezes que UM ator (ou caso de uso) executa o caso de uso (ou componente) em um determinado período de tempo, ou

     - o número de ATORES (ou casos de uso) que executam o caso de uso (ou componente).

Geralmente, quanto mais utilizado for um caso de uso ou componente, mais alto será o indicador do perfil operacional.

Após identificar os indicadores de magnitude do perfil operacional a serem usados, liste cada caso de uso ou componente no objetivo do teste. Determine um indicador de perfil operacional para cada item da lista e dê uma justificativa para o valor do indicador. As informações do documento de análise de carga de trabalho (consulte Artefato: Documento de Análise de Carga de Trabalho) podem ser usadas nessa avaliação.

Exemplos:

     - instalação de novo software;

     - pedido de itens de um catálogo on-line;

     - perguntas dos clientes sobre o pedido on-line depois de feito o pedido;

     - caixa de diálogo de seleção de itens.

Estabelecer a Prioridade do Teste

O último passo na avaliação do risco e no estabelecimento de uma prioridade de teste é estabelecer essa prioridade.

Comece identificando e descrevendo os indicadores de magnitude da prioridade de teste que serão usados como, por exemplo:

     A - deve ser testado;

     M - deverá ser testado somente depois que todos os itens A forem testados;

     B - poderá ser testado, mas somente após todos os itens A e M.

Após identificar os indicadores de magnitude da prioridade de teste a serem usados, liste cada caso de uso ou componente no objetivo do teste. Determine um indicador de prioridade de teste para cada item da lista e dê uma justificativa. Abaixo são apresentadas algumas diretrizes para determinar um indicador de prioridade de teste.

Considere o seguinte ao determinar os indicadores de prioridade de teste para cada item:

     - o valor do indicador de magnitude do risco identificado anteriormente;

     - o valor da magnitude do perfil operacional identificado anteriormente;

     - as descrições dos atores (os atores são experientes?, os atores são tolerantes a soluções alternativas? etc.);

     - obrigações contratuais (o objetivo do teste será aceitável se um caso de uso ou componente não for entregue?).

As estratégias para estabelecer uma prioridade de teste incluem:

     - usar o fator avaliado (risco, perfil operacional etc.) com valor mais alto para cada item como prioridade geral;

     - identificar um fator avaliado (risco, perfil operacional ou outro) como o mais significativo e usar o valor desse fator como prioridade;

     - usar uma combinação dos fatores avaliados para identificar a prioridade;

     - usar um esquema de ponderação em que fatores individuais são ponderados e os respectivos valores e prioridade são calculados com base na ponderação.

Exemplos:

     - instalação de novo software;

     - pedido de itens de um catálogo on-line;

     - pesquisas de clientes sobre o pedido on-line depois de feito o pedido;

     - caixa de Diálogo de Seleção de Itens.

Estratégia de Teste

A Estratégia de Teste descreve os objetivos e a abordagem geral de um esforço de teste específico.

Uma estratégia de teste adequada deve conter os seguintes itens:

     - tipo de teste a ser implementado e seu objetivo;

     - estágio em que o teste será implementado;

     - técnica;

     - medições e critérios usados para avaliar os resultados e a conclusão do teste;

     - quaisquer considerações especiais que afetem o esforço de teste descrito na estratégia de teste.

Tipo de Teste e Objetivo 

Especifique claramente o tipo de teste que está sendo implementado e o objetivo do teste. A especificação explícita dessas informações reduz a confusão e minimiza os equívocos (especialmente porque alguns testes podem parecer muito semelhantes). O objetivo deve especificar explicitamente o motivo pelo qual o teste está sendo executado.

Exemplos:

     "Teste Funcional. O teste funcional concentra-se em executar os casos de uso a seguir, implementados no objetivo do teste, a partir da interface de usuário."

     "Teste de Desempenho. O teste de desempenho do sistema concentra-se em medir o tempo de resposta dos casos de uso 2, 4 e 8 a 10. Para esses testes, será usada a carga de trabalho de um ator, que executa esses casos de uso sem qualquer outra carga de trabalho sobre o sistema em teste."

     "Teste de Configuração. O teste de configuração é implementado para identificar e avaliar o comportamento do objetivo do teste em três configurações diferentes, comparando as características de desempenho com a nossa configuração de referência."

Estágio de Teste

Especifique claramente o estágio em que o teste será executado.

Técnica 

A técnica deve descrever como o teste será implementado e executado. Inclua o que será testado, as principais ações a serem executadas durante a execução do teste e os métodos usados para avaliar os resultados.

Exemplo:

     - Teste Funcional:

          - para o fluxo de eventos de cada caso de uso, será identificado um conjunto representativo de transações, cada um representando as ações executadas pelo ator durante a execução do caso de uso;

          - pelo menos dois casos de teste serão desenvolvidos para cada transação: um para refletir a condição positiva e um para refletir a condição negativa (inaceitável);

          - na primeira iteração, os casos de uso 1 a 4 e 12 serão testados da seguinte maneira:

               - Caso de Uso 1:

                    - o Caso de Uso 1 começa com o ator já conectado ao aplicativo e na janela principal e termina quando o usuário especifica SALVAR;

                    - cada caso de teste será implementado e executado usando o Rational Robot;

                    - a verificação e a avaliação da execução de cada caso de teste serão realizadas por meio dos seguintes métodos:

                         - execução de scripts de teste (cada script de teste foi executado com êxito e da maneira desejada?);

                         - os métodos de verificação de Objetos de Dados ou de Existência de Janela (implementados nos scripts de teste) serão usados para verificar se as janelas principais são exibidas e se os dados especificados são capturados/exibidos pelo objetivo de teste durante a execução do teste;

                         - o banco de dados do objetivo do teste (usando o Microsoft Access) será examinado antes e depois do teste para verificar se os dados refletem com precisão as mudanças executadas durante o teste;

     - Teste de Desempenho:

          - para cada caso de uso, um conjunto representativo de transações, conforme identificadas no documento de análise de carga de trabalho, será implementado e executado usando o Rational Suite Performance Studio (scripts vu) e o Rational Robot (scripts GUI);

          - os scripts de teste e as agendas de execução de teste refletirão pelo menos três cargas de trabalho, dentre elas:

               - carga de trabalho sob estresse: 750 usuários (15% gerentes, 50% vendas, 35% marketing);

               - carga de trabalho máxima: 350 usuários (10% gerentes, 60% vendas, 30% marketing);

               - carga de trabalho nominal: 150 usuários (2% gerentes, 75% vendas, 23% marketing);

          - os scripts de teste usados para executar cada transação incluirão os temporizadores adequados para capturar tempos de resposta, como o tempo de transação total (conforme definido no documento de análise de carga de trabalho), e os tempos de processo ou de atividade das transações principais;

          - os scripts de teste executarão as cargas de trabalho durante uma hora (a menos que seja especificado o contrário no documento de análise de carga de trabalho);

          - a verificação e a avaliação de cada execução de teste (de uma carga de trabalho) incluirão:

               - a execução do teste será monitorada com histogramas de estado (para verificar se as cargas de trabalho e o teste estão sendo executados conforme o esperado e desejado);

               - execução de scripts de teste (cada script de teste foi executado com êxito e da maneira desejada?);

               - captura e avaliação dos tempos de resposta identificados através dos seguintes relatórios:

                    - Percentual de Desempenho;

                    - Tempo de Resposta. 

Critérios de Conclusão

Os critérios de conclusão são definidos por dois motivos:

     - identificar a qualidade aceitável do produto;

     - identificar quando o esforço de teste foi implementado com êxito.

Uma declaração explícita dos critérios de conclusão deve conter os seguintes itens:

     - função, comportamento ou condição que está sendo avaliada;

     - método de medição;

     - critérios ou nível de conformidade com a medição.

Exemplo 1:

     - todos os casos de teste planejados foram executados;

     - todos os defeitos identificados foram abordados de acordo com o que foi estabelecido previamente;

     - todos os casos de teste planejados foram executados novamente e todos os defeitos conhecidos foram abordados de acordo com o que foi estabelecido previamente, e não foram descobertos outros defeitos.

Exemplo 2:

     - todos os casos de teste de prioridade alta foram executados;

     - todos os defeitos identificados foram abordados de acordo com o que foi estabelecido previamente;

     - todos os defeitos de Gravidade 1 ou 2 foram solucionados (status = corrigido ou adiado);

     - todos os casos de teste de prioridade alta foram executados novamente e todos os defeitos conhecidos foram solucionados de comum acordo, e não foram descobertos outros defeitos.

Exemplo 3:

     - todos os casos de teste planejados foram executados;

     - todos os defeitos identificados foram solucionados de comum acordo;

     - todos os defeitos de Gravidade 1 ou 2 foram solucionados (status = verificado ou adiado);

     - todos os casos de teste de prioridade alta foram executados novamente e todos os defeitos conhecidos foram solucionados de comum acordo, e não foram descobertos outros defeitos.

Considerações Especiais

Esta seção deve identificar quaisquer influências ou dependências que possam afetar ou influenciar o esforço de teste descrito na estratégia de teste. As influências podem incluir:

     - recursos humanos (como disponibilidade ou necessidade de recursos não relacionados a teste para dar suporte ao teste ou participar dele);

     - restrições (como limitações ou disponibilidade de equipamento ou a necessidade/falta de equipamento especial);

     - requisitos especiais, como agenda de teste ou acesso a sistemas.

Exemplos:

     - os bancos de dados de teste exigirão o suporte de um designer/administrador de banco de dados para criar, atualizar e renovar os dados de teste;

     - o teste de desempenho do sistema usará os servidores da rede existente (que suporta tráfego não relacionado a teste). O teste deverá ser agendado para um horário após o expediente, para que não haja tráfego na rede que não esteja relacionado ao teste;

     - o objetivo do teste deve sincronizar o sistema legado (ou simular a sincronização) para que o teste funcional completo seja implementado e executado.