Diretrizes:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Plano de Teste |
O plano de teste contém informações sobre a finalidade e as metas dos testes no projeto. Além disso, ele identifica as estratégias a serem usadas para implementar e executar os testes, além de identificar os recursos necessários. |
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.
Abaixo são apresentadas algumas diretrizes para identificar e comunicar requisitos, riscos, prioridades e estratégias de teste de uma maneira mais adequada.
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:
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.
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.
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:
Os requisitos de desempenho são descritos nas Especificações Suplementares. Examine esse material, prestando atenção especial a:
Para cada sentença da especificação, você deve gerar pelo menos um requisito de teste que reflita informações como as listadas acima.
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:
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.
As próximas seções descrevem como determinar a prioridade 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:
A avaliação do risco e o estabelecimento das prioridades de teste são realizados em três passos:
As diretrizes para cada um desses três passos são fornecidas abaixo:
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:
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:
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.
Abaixo são apresentados mais detalhes sobre a avaliação do risco dessas três perspectivas.
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:
Abaixo é apresentado um exemplo de matriz de justificativa para esses itens:
| Descrição | Fator de Diminuição de Riscos | Justificativa |
| Espaço em disco insuficiente durante a instalação | A | Ao instalar o software, o usuário forma a sua primeira impressão sobre o produto. Quaisquer resultados indesejados, como os apresentados abaixo, podem prejudicar o sistema do usuário e o software instalado e transmitir uma impressão negativa ao usuário:
|
| A conexão com a Internet é perdida durante uma pesquisa | B | A perda de conexão não causa nenhum dano aos dados nem ao banco de dados. Sabe-se que a perda de conexão pode transmitir uma impressão negativa ao usuário. |
| A conexão com a Internet é perdida durante uma compra | A | Quaisquer conexões ou transações perdidas que se convertam nos resultados listados abaixo são inaceitáveis, visto que aumentam as despesas gerais e reduzem os lucros:
|
| É inserido um valor inesperado | A | Quaisquer transações que se convertam nos resultados listados abaixo são inaceitáveis:
|
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:
Abaixo é apresentado um exemplo de matriz de justificativa para esses itens:
| Descrição | Fator de Diminuição de Riscos | Justificativa |
| Entradas do Registro e arquivos de aplicativos ausentes | A | Torna o aplicativo (e possivelmente o sistema) inutilizável. A instalação é a primeira visão que os usuários têm do aplicativo. Se a instalação falhar, por qualquer motivo, o usuário terá uma visão desfavorável do software. As possíveis causas dessa condição incluem:
Dessas causas, apenas a última não pode ser detectada e manipulada pelo processo de instalação. |
| Pedido parcial | A | Não é possível atender a pedidos parciais, o que resulta em perda de receita e de clientes.
As possíveis causas incluem:
|
| Banco de dados/dados corrompidos | A | Não se admite a corrupção de dados por nenhum motivo.
As possíveis causas incluem:
|
| Pedidos duplicados | A | Os pedidos duplicados aumentam as despesas gerais da empresa e diminuem os lucros em decorrência dos custos associados ao envio, ao manuseio e rearmazenamento.
As possíveis causas incluem:
|
| Dados imprecisos de um pedido | A | Qualquer pedido que não possa ser atendido ou que incida em despesas gerais adicionais não é aceitável.
As possíveis causas incluem:
|
| Número errado de registros refletidos no balanço | A | As decisões sobre negócios e as contas a receber dependem da precisão desses relatórios.
As possíveis causas incluem:
|
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:
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.
Existem correlações entre esses fatores e a probabilidade de falha, conforme identificado abaixo:
| Fator Externo | Probabilidade |
| Densidade e/ou taxa de detecção de falha |
A probabilidade de falha aumenta à medida que aumenta a densidade ou a taxa de detecção de falha. Os defeitos tendem a se juntar, portanto, à medida que a taxa de detecção ou o número de defeitos (densidade) aumenta em um caso de uso ou componente, também aumenta a probabilidade de se encontrar um outro defeito. A densidade e as taxas de detecção provenientes de releases anteriores também devem ser consideradas durante uma avaliação do risco usando esse fator, visto que densidades ou taxas de descoberta anteriores altas indicam uma alta probabilidade de falhas adicionais. |
| Taxa de mudança | A probabilidade de falha aumenta à medida que aumenta a taxa de mudança no caso de uso ou componente. Dessa forma, à medida que aumenta o número de mudanças, também aumenta a probabilidade de introdução de defeitos. A cada mudança feita no código, há risco de "injetar" outro defeito nele. |
| Complexidade | A probabilidade de falha aumenta à medida que aumenta a métrica de complexidade do caso de uso ou do componente. |
| Origem/Originador | A experiência e o conhecimento da origem e do originador do código podem aumentar ou diminuir a probabilidade de falha. Geralmente, o uso de componentes de terceiros diminui a probabilidade de falha. Entretanto, isso se aplicará apenas se o componente de terceiros tiver sido certificado (atender aos seus requisitos, por meio de testes formais ou da experiência). Geralmente, a probabilidade de falha diminui com o aumento do conhecimento e da habilidade do implementador. No entanto, fatores como o uso de novas ferramentas e de tecnologias ou o desempenho de vários papéis podem aumentar a probabilidade de falha, mesmo dos melhores membros da equipe. |
Por exemplo:
Abaixo é apresentado um exemplo de matriz de justificativa para esses itens:
| Descrição | Fator de Diminuição de Riscos | Justificativa |
| Instalação de novo software | A | Estamos escrevendo o nosso próprio utilitário de instalação.
Ele torna o aplicativo inutilizável. A instalação é a primeira visão que os usuários têm do aplicativo. Se a instalação falhar, por qualquer motivo, o usuário terá uma visão desfavorável do software. |
| Instalação de novo software | B | Estamos usando um utilitário de instalação que é um sucesso comercial.
Embora a falha da instalação torne o aplicativo inutilizável, o utilitário de instalação selecionado é de um fornecedor que conquistou a liderança do mercado com seu produto e está em atividade há mais de quatro anos. A nossa avaliação indica que o produto atende às nossas necessidades e que os clientes estão satisfeitos com o produto, com o fornecedor e com o nível de serviço e suporte. |
| Altas taxas de detecção de falhas/densidades de defeitos nos casos de uso 1, 10 e 12. | A | Devido às altas taxas de detecção de falhas e densidades de defeitos anteriores, os casos de uso 1, 10 e 12 são considerados de alto risco. |
| Solicitações de mudança nos casos de uso 14 e 19. | A | Um grande número de mudanças nesses casos de uso aumenta a probabilidade de injetar defeitos no código. |
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:
O indicador do perfil operacional selecionado deve basear-se na freqüência com que um caso de uso ou o componente é executado, incluindo:
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:
| Descrição | Fator de Perfil Operacional | Justificativa |
| Instalação de novo software | A | Executada uma vez (normalmente), mas por muitos usuários. No entanto, sem a instalação, o aplicativo ficará inutilizável. |
| Pedido de itens do catálogo | A | Este é o caso de uso mais comum executado pelos usuários. |
| Pesquisas de clientes sobre o pedido on-line | B | Poucos clientes perguntam sobre seus pedidos depois de fazê-los |
| Caixa de diálogo de seleção de itens | A | Esta caixa de diálogo é usada pelos clientes para fazer pedidos e pelos responsáveis pelo inventário para reabastecer o estoque. |
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:
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:
As estratégias para estabelecer uma prioridade de teste incluem:
Exemplos:
| Item | Risco | Perfil Operacional | Ator | Contrato | Prioridade |
| Instalação de novo software | A | A | B | A | A |
| Pedido de itens do catálogo | A | A | A | A | A |
| Pesquisas do cliente | B | B | B | B | B |
| Caixa de Diálogo de Seleção de Itens | B | A | B | B | A |
| Item | Risco | Perfil Operacional | Ator | Contrato | Prioridade |
| Instalação de novo software | A | A | B | A | A |
| Pedido de itens do catálogo | A | A | A | A | A |
| Pesquisas do cliente | B | B | B | B | B |
| Caixa de Diálogo de Seleção de Itens | B | A | B | B | B |
(Observação: na matriz abaixo, A = 5, M = 3 e B = 1. Um valor Ponderado Total maior que 30 indica um item de teste de prioridade Alta, valores entre 20 e 30, inclusive, indicam uma prioridade Média e valores menores que 20 indicam uma prioridade Baixa).
| Item | Risco (x 3) | Perfil Operacional (x 2) | Ator (x 1) | Contrato (x 3) | Valor Ponderado | Prioridade |
| Instalação de novo software | 5 (15) | 5 (10) | 1 (1) | 5 (15) | 41 | A (2) |
| Pedido de itens do catálogo | 5 (15) | 5 (10) | 5 (5) | 5 (15) | 45 | A (1) |
| Pesquisas do cliente | 1 (3) | 1 (2) | 1 (1) | 1 (3) | 9 | B (4) |
| Caixa de Diálogo de Seleção de Itens | 1 (3) | 5 (10) | 1 (1) | 1 (3) | 17 | B (3) |
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:
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."
Especifique claramente o estágio em que o teste será executado. Abaixo estão identificados os estágios em que testes comuns são executados:
|
|
Estágio de Teste | |||
| Tipo de Testes | Unidade | Integração | Sistema | Aceitação |
| Testes Funcionais
(Configuração, Função, Instalação, Segurança, Volume) |
X | X | X | X |
| Testes de Desempenho
(perfis de desempenho de componentes individuais) |
X | X | (X)
opcional ou quando os testes de desempenho do sistema revelarem defeitos |
|
| Testes de Desempenho
(Carga, Stress, Contenção) |
|
|
X | X |
| Confiabilidade
(Integridade, Estrutura) |
X | X | (X)
opcional ou quando outros testes detectarem defeitos |
|
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 PerformanceStudio (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 stress: 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
Os critérios de conclusão são definidos por dois motivos:
Uma declaração explícita dos critérios de conclusão deve conter os seguintes itens:
Exemplo 1
Exemplo 2
Exemplo 3
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:
Exemplos:
|
Rational Unified Process
|
