Diretriz: Plano de Teste

Visão Geral

O objetivo do plano de teste é comunicar a intenção das tarefas 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.

Fora da definição de projeto, um plano de teste que identifique o teste geral pretendido para o projeto deve ser criado, denominado "Plano de Teste Principal". Como cada iteração é planejada, um "Plano de Iteração de Teste" mais preciso é criado (ou vários planos de teste, organizados por tipo de teste), contendo apenas os dados (requisitos para o teste, estratégias de teste, recursos, etc.) pertinentes à iteração. De forma alternativa, essas informações podem estar inclusas 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.

Identificando Requisitos para o 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 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 para 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 para Teste 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. Revise estes materiais, prestando atenção especial a instruções que incluem:

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 para 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.

Revise esses produtos de trabalho e preste atenção especial a instruções que incluem o seguinte:

instruções de confiabilidade ou resistência a defeitos e erros de tempo de execução (como fugas de memória)
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 instrução nos produtos de trabalho 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.

Avaliar Riscos 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. Essa etapa é feita por várias razões, incluindo:

assegurar que os esforços de teste tenham como foco os requisitos de teste mais apropriados
assegurar que os requisitos de teste mais críticos, significativos ou com maior risco sejam tratados o mais breve possível
assegurar que qualquer dependência, como seqüência ou dados, seja testada

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

Avaliar Risco
Determinar o Perfil Operacional
Estabelecer Prioridade de Teste

As diretrizes para cada um desses três passos são fornecidas abaixo:

Avaliar Risco

Estabelecer a prioridade do teste começa com a avaliação do risco. Os casos de uso ou componentes que apresentam o maior risco em decorrência de defeitos ou que apresentam uma alta probabilidade de defeitos devem estar entre os primeiros casos de uso 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 conseqüência de um caso de uso especificado (requisito, etc.) em falha
Causa - inicia com um resultado indesejável causado pela falha de um caso de uso e examina possíveis causas
Probabilidade - a probabilidade de um caso de uso com falha.

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 assegurar que ele constitua realmente um risco baixo.

Abaixo são apresentados mais detalhes sobre a avaliação do risco dessas três perspectivas.

Efeito

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 consulta?"
"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 digitasse um valor inesperado?"

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: o software é instalado parcialmente (alguns arquivos, algumas entradas do registro), o que deixa o software instalado em uma condição instável a instalação é interrompida, deixando o sistema em um estado instável
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: banco de dados corrompido pedido parcial perda de dados ou pedido múltiplos pedidos (duplicados)
É inserido um valor inesperado	A	Quaisquer transações que se convertam nos resultados listados abaixo são inaceitáveis: banco de dados corrompido dados imprecisos

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 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?"

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: o processo de instalação não instalou todos os arquivos e não atualizou o Registro corretamente o processo de instalação foi interrompido devido à intervenção do usuário (ele pressionou o botão Cancelar ou Sair) o processo de instalação foi interrompido devido à intervenção do software/hardware (espaço em disco insuficiente, configuração não suportada etc.) o processo de instalação foi interrompido devido a condições desconhecidas o usuário excluiu arquivos/entradas do Registro 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: Perda da conexão com a Internet devido a uma ação do usuário (ele desconectou o modem, desligou o PC etc.) Perda da conexão com a Internet devido ao protocolo IP Perda da conexão com a Internet devido a uma ação do funcionário (ele desconectou o modem, desligou os servidores etc.)
Banco de dados/dados corrompidos	A	Não se admite a corrupção de dados por nenhum motivo. As possíveis causas incluem: Uma transação que grava no banco de dados não foi concluída/confirmada devido à intervenção do usuário Uma transação que grava no banco de dados não foi concluída/confirmada devido à perda da conexão com a Internet O usuário inseriu dados inválidos na transação Utilitários/métodos de acesso ao banco de dados O banco de dados não foi preenchido corretamente (ao ser instanciado inicialmente)
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: A transação que grava o pedido no banco de dados foi duplicada devido à intervenção do usuário (o usuário inseriu o pedido duas vezes porque não teve confirmação da entrada) A transação que grava o pedido no banco de dados foi duplicada devido a uma intervenção que não foi do usuário (processo de recuperação da perda de conexão com a Internet, restauração do banco de dados)
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: A transação de pedido não foi concluída/confirmada devido à intervenção do usuário A transação de pedido não foi concluída/confirmada devido à perda de conexão com a Internet O usuário inseriu dados inválidos
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: Critérios de seleção/pesquisa incorretos Instrução SQL incorreta Dados corrompidos no banco de dados Dados incorretos no banco de dados

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:

Taxas de defeito
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.

Existem correlações entre esses fatores e a probabilidade de falha, conforme identificado abaixo:

Fator Externo	Probabilidade
Taxa de descoberta de defeitos	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. Toda vez que uma alteração é feita no código, há o 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 um defeito. 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:

Instalação do novo software
"Historicamente, temos localizado vários defeitos nos componentes utilizados 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."

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.

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 freqüência, muitas vezes por período ou por muitos atores ou casos de uso.
M - usado com freqüência, várias vezes por período ou por vários atores ou casos de uso.
B - usado com pouca freqüência ou usado por poucos atores ou casos de uso.

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

o número de vezes que UM agente (ou caso de uso) executa o caso de uso (ou componente) em um determinado período de tempo
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 da carga de trabalho (Consulte Produto de Trabalho: Documento de Análise da Carga de Trabalho) podem ser utilizadas nessa avaliaçã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

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.

Estabelecer a Prioridade de 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:

Utilizar o valor mais alto do fator avaliado (risco, perfil operacional etc.) para cada item como a 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

Prioridade quando o valor avaliado mais alto é usado para determinar a prioridade:

Item	Risco	Perfil Operacional	Agente	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

Prioridade quando o valor mais alto avaliado para um fator (Risco) é usado para determinar a prioridade:

Item	Risco	Perfil Operacional	Agente	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

Prioridade quando um valor de ponderação é usado para calcular a prioridade:

(Nota: na matriz a seguir, 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)	Agente (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)

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 seus objetivos
estágio em que o teste será implementado
técnica
medidas e critérios utilizados para avaliar os resultados e a conclusão do teste
quaisquer considerações especiais que afetam 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 tem como foco a execução dos casos de uso a seguir implementados no destino do teste, a partir da interface com o usuário."

"Teste de Desempenho. O teste de desempenho do sistema tem como foco medir o tempo de resposta dos casos de uso 2, 4 e 8 a 10. Para esses testes, será utilizada uma carga de trabalho de um agente, que executa esses casos de uso sem qualquer outra carga de trabalho no sistema em teste."

"Teste de Configuração. O teste de configuração será implementado para identificar e avaliar o comportamento do destino do teste em três configurações diferentes, comparando as características de desempenho com a configuração de avaliação de desempenho."

Estágio de Teste

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	Alertas de 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

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 agente 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 agente 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 acentuada: 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 tarefa 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 resolvidos, de acordo com o que foi estabelecido previamente, e nenhum novo defeito foi descoberto

Exemplo 2

Todos os casos de teste de prioridade alta foram executados.
Todos os defeitos identificados foram solucionados de comum acordo.
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.