Explicação

Nada possui mais influência sobre a capacidade das equipes de projeto em assegurar a satisfação do investidor com o software do que a disponibilidade de uma especificação clara de quais são as expectativas dos investidores. Com ou sem um bom conjunto suficiente de especificações de requisitos, os casos de teste são um artefato que ajudam a refletir as expectativas dos investidores, permitindo que essas expectativas sejam verificadas e validadas.

Quando um conjunto útil de requisitos está disponível, a equipe de teste precisa planejar testes que validarão apropriadamente esses requisitos. Observe que a validação do software em relação aos requisitos pode ser feita de modo diferente dependendo do tipo de requisito. Por exemplo, a execução do software para validar seus requisitos funcionais e de desempenho pode ser feita por um testador utilizando técnicas de teste automatizado, enquanto a verificação de um requisito de configuração, como o encerramento do sistema de computador host, pode precisar ser feita utilizando técnicas de teste manual.

Como talvez você não consiga verificar todos os requisitos, nem seja responsável por isso, é importante manter o foco nos requisitos mais apropriados ou críticos para o escopo do esforço de trabalho atual. Os requisitos escolhidos para verificação representarão um equilíbrio entre o custo, o risco e a necessidade de verificá-los e, geralmente, serão limitados pelo escopo da iteração atual.

Embora os requisitos sejam uma origem importante para derivação dos testes, eles não são a única origem de informações. Na verdade, em muitos casos eles serão insuficientes para fornecer uma base completa para desenvolvimento dos testes. Também é necessário considerar os Casos de Teste que baseiam-se nas origens de informações, como riscos, restrições, tecnologias, controles de mudanças (defeitos), falhas e outros.
Consulte Conceito: Idéias de Teste para obter informações adicionais sobre como apresentar idéias a partir das quais os testes podem ser derivados.

A identificação de casos de teste é útil por várias razões.

• Os casos de teste podem ser utilizados como a base para projetar e implementar os testes reais. O tempo gasto na consideração do caso de teste ajuda a entender melhor os requisitos de design e de implementação e possivelmente economizará tempo em tarefas de design e de implementação.
• Alguns testes são particularmente complexos ou detalhados. Os testes dessa natureza podem se beneficiar da consideração cuidadosa antecipada, antes de iniciar a implementação do teste, e os artefatos do caso de teste e do design de teste são boas ferramentas para explorar essas considerações.
• A "profundidade" do teste é normalmente considerada como proporcional ao número de testes. Obtém-se maior confiança no próprio processo de teste quando a possível "profundidade" do teste pode ser raciocinada com base no número de casos de teste identificados.
• Uma medida da abrangência do esforço de teste baseia-se na cobertura de monitoração para algum conjunto de elementos motivadores. Os relatórios de cobertura podem basear-se em medidas, como o número de casos de teste identificados e o número de testes implementados e / ou executados para cada caso de teste ou a quantidade de esforço gasto em cada caso de teste.
• A escala e a complexidade do esforço de teste é proporcional ao número de casos de teste. Com uma quebra dos casos de teste, o esforço de teste pode ser raciocinado sobre um nível mais refinado de granularidade.
• Os tipos de design e desenvolvimento de testes e os recursos necessários são, em parte, controlados pelo número e complexidade dos casos de teste.

No entanto, há algumas questões a serem consideradas sobre os casos de teste:

• Nem todo teste é complexo o bastante para justificar a sobrecarga de criação de um artefato de caso de teste que precise ser revisado e mantido: o teste é tão simples que uma descrição textual resumida é suficiente para transmitir o que é necessário. Na verdade, a maioria dos casos de teste podem falhar na categoria. O tempo gasto para documentar um grande número de casos de teste simples pode resultar em perda de tempo nas tarefas de teste mais importantes.
• Algumas idéias iniciais para os testes são comprovadas subseqüentemente como inúteis em algum circunstância. Isso significa que alguns dos casos de teste que você identificou inicialmente com base nessas idéias serão abandonados. Essa realidade significa que qualquer trabalho de documentação detalhada dos casos de teste pode ser, subseqüentemente, abandonado e qualquer relatório de cobertura com base nos casos de teste precisa considerar essa situação. Portanto, pode ser melhor basear o relatório de cobertura de teste em questões de nível superior, em vez de nos casos de teste, e tratar os casos de teste como artefatos da equipe de teste utilizados conforme necessário.

Geralmente, os casos de teste são categorizados ou classificados pelo tipo ou requisito de teste ao qual estão associados e variam de acordo com isso. Uma heurística para identificar os casos de teste começa com o seguinte:

• demonstrar que o requisito foi atendido (caso de teste positivo)
• demonstrar que o requisito é atendido apenas sob as condições desejadas, referido como um teste negativo. Este caso de teste reflete condições ou dados inaceitáveis, anormais ou inesperados aos quais o software pode estar razoavelmente sujeito.

Derivando Casos de Teste de Casos de Uso

Os casos de teste para o teste funcional são derivados dos casos de uso do destino do teste (consulte Produto de Trabalho: Caso de Uso). É necessário desenvolver casos de teste para cada cenário de caso de uso. Os cenários de caso de uso são identificados pela descrição dos caminhos que percorrer o fluxo básico e os fluxos alternativos, do início ao fim do caso de uso.

No diagrama a seguir, por exemplo, os vários caminhos através de um caso de uso, que refletem o fluxo básico e os fluxos alternativos, são representados com as setas. O fluxo básico, representado pela linha preta e reta é o caminho mais simples através do caso de uso. Cada fluxo alternativo começa no fluxo básico e, depois, de acordo com uma condição específica, é executado. Os fluxos alternativos podem retornar ao fluxo básico (fluxos alternativos 1 e 3), podem originar-se de outro fluxo alternativo (fluxo alternativo 2), ou podem terminar o caso de uso sem retornar a um fluxo (fluxos alternativos 2 e 4).

Exemplos de Fluxos de Eventos em um caso de uso

Após cada caminho possível através do caso de uso mostrado no diagrama acima, é possível identificar os diversos cenários de caso de uso. Começando pelo fluxo básico e depois combinando-o com os fluxos alternativos, é possível identificar os cenários de caso de uso a seguir: 

Nota: Por praticidade, os Cenários 5, 6 e 8 descrevem apenas uma única execução do loop indicado pelo Fluxo Alternativo 3.    

É possível obter os casos de teste para cada cenário através da identificação da condição específica que causará a execução desse cenário de caso de uso específico.

Por exemplo, suponha que o caso de uso descrito no diagrama acima indicou o seguinte para o Fluxo Alternativo 3:

"Este fluxo de eventos ocorrerá se o valor em dólar digitado na Etapa 2 anterior, "Digitar o Valor da Retirada" for maior que o saldo atual da conta. O sistema exibe uma mensagem de aviso e, em seguida, torna a unir o fluxo básico na Etapa 2 "Digitar o Valor da Retirada" anterior, em que o cliente do banco pode digitar um novo valor de retirada."

Com essas informações, você pode começar a identificar os casos de teste necessários para a execução do fluxo alternativo 3:

Nota: os casos de teste mostrados anteriormente são muito simples, já que nenhuma outra informação foi fornecida. Os casos de teste raramente são tão simples.

Um exemplo mais realista de derivação de casos de teste a partir dos casos de uso é fornecido a seguir:

Exemplo:

Agentes e casos de uso em um caixa eletrônico.

A tabela a seguir contém o fluxo básico e alguns fluxos alternativos para o caso de uso Retirada em Dinheiro no diagrama acima:

Os cenários a seguir podem ser derivados desse caso de uso:

Nota: Por praticidade, os loops nos Fluxos alternativos 3 e 6 (Cenários 3 e 7) e as combinações de loops não foram incluídos na tabela anterior.

Para cada um desses sete cenários, é necessário identificar casos de teste. É possível identificar e gerenciar os casos de teste usando matrizes ou tabelas de decisão. Um formato comum é mostrado a seguir, em que cada linha representa um caso de teste individual e as colunas identificam informações de caso de teste.  Neste exemplo, para cada caso de teste, há um ID, uma Condição (ou descrição) e todos os elementos de dados que participam do caso de teste (como entrada ou já no banco de dados) e o resultado esperado.

Para desenvolver a matriz, primeiro identifique quais elementos de dados são necessários para a execução dos cenários de caso de uso. Em seguida, para cada cenário, identifique pelo menos um caso de teste que contenha a condição apropriada para executar o cenário. Por exemplo, na matriz a seguir, V (válido) é utilizado para indicar que essa condição deve ser VÁLIDA para que o fluxo básico seja executado e I (inválido) é utilizado para indicar a condição que chamará o fluxo alternativo desejado.  Na tabela a seguir, "n/d" indica que esta condição não é aplicável ao caso de teste.

Na matriz acima, os seis casos de teste executam os quatro cenários. Para o Fluxo Básico, o caso de teste CW1 acima é denominado caso de teste positivo. Ele executa, sem desvios, o caminho do Fluxo Básico através do caso de uso. O teste abrangente do Fluxo Básico deve incluir casos de teste negativos para garantir que esse fluxo só seja utilizado quando as condições estiverem corretas. Esses casos de teste negativos são representados pelos casos de teste CW2 - 6 (a célula sombreada indica a condição necessária para executar os fluxos alternativos). Embora CW2 - 6 consista em casos de teste negativos para o Fluxo Básico, eles são positivos para os Fluxos Alternativos 2 - 4 e há pelo menos um caso de teste negativo em cada um desses Fluxos Alternativos (CW1 - o Fluxo Básico).

O Cenário 4 é um exemplo em que não é suficiente haver apenas um caso de teste positivo e um negativo por cenário. Para testar completamente o Cenário de teste 4 - Senha Incorreta, são necessários pelo menos três casos de teste positivos (para disparar o Cenário 4):

• a senha incorreta é digitada, há novas tentativas, e esse Fluxo Alternativo retorna à Etapa 3 do Fluxo Básico - Digitar a Senha)
• a senha incorreta é digitada, não há novas tentativas, esse Fluxo Alternativo retém o cartão e termina o caso de uso.
• a senha CORRETA é digitada quando não há mais novas tentativas.  Esse Fluxo Alternativo retorna ao Fluxo Básico na Etapa 5 - Digitar o Valor.  

Observe que, na matriz acima, nenhum valor real foi digitado para as condições (dados). A vantagem de criar a matriz do caso de teste dessa maneira é a facilidade de ver as condições que estão sendo testadas. Também é muito fácil determinar se casos de teste suficientes foram identificados, já que você precisa apenas observar os Vs e Is (ou como feito aqui - as células sombreadas). Na tabela acima, há diversas condições para as quais não há células sombreadas. Portanto, estão faltando casos de teste como, por exemplo, para o Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto e para o Cenário 7 - Saldo Insuficiente em Conta.

Depois que casos de teste suficientes forem identificados, será necessário revisá-los e validá-los para assegurar a exatidão e adequação, bem como para eliminar casos de teste duplicados, equivalentes ou de alguma maneira redundantes. Consulte Conceito: Lista de Idéias de Teste para obter mais detalhes. Além disso, consulte a seção Definindo Dados de teste para Casos de Teste para obter detalhes adicionais.

Os casos de teste acima são apenas alguns dos necessários para verificar o Caso de Uso de Retirada em Dinheiro, referente a essa iteração. Outros casos de teste necessários contêm:

• Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto: Conta não localizada ou disponível
• Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto: A conta não permite retiradas
• Cenário 7 - Saldo em Conta Insuficiente: Valor solicitado maior que o valor em conta.

Em futuras iterações, quando outros fluxos forem implementados, os casos de teste serão necessários para:

• Cartões inválidos (informa-se que o cartão foi perdido, roubado, não é de um banco aceito, tem uma tarja danificada etc.)
• Incapacidade de ler um cartão (o leitor de cartões está obstruído, fora de linha ou com defeito)
• A conta está fechada, paralisada ou de outra maneira indisponível
• O valor no caixa eletrônico é insuficiente ou incapaz de compor o valor solicitado (diferente do CW3, visto que uma denominação está fora, mas não todas)
• Incapaz de entrar em contato com o sistema bancário para aprovação
• A rede do banco está fora de linha ou há uma falha de energia durante a transação

Ao identificar os casos de teste funcionais, verifique se:

• casos de teste suficientes, positivos e negativos, foram identificados para cada cenário de caso de uso 
• os casos de teste abordam qualquer regra de negócio implementada pelos casos de uso, garantindo que haja casos de teste, dentro, fora e na condição ou no valor de fronteira da regra de negócio
• os casos de teste abordam quaisquer seqüências de eventos ou ações, como aquelas identificadas nos diagramas de seqüência do modelo de design, ou estados ou as condições de objetos de interface do usuário.
• os casos de teste abordam qualquer requisito especial definido para o caso de uso, como o desempenho mínimo/máximo, às vezes combinado com as cargas ou os volumes de dados mínimos/máximos durante a execução dos casos de uso.

Consulte a seção Definindo Dados de Teste para Casos de Teste para obter orientação adicionais.

Derivando Casos de Teste de Especificações Suplementares

Nem todos os requisitos de um destino de teste serão refletidos em artefatos de requisitos funcionais, como especificações de casos de uso. Os requisitos não funcionais, como desempenho, segurança e acesso, e os requisitos de configuração especificam comportamentos ou características adicionais do destino do teste e são, geralmente, documentados separadamente dos requisitos funcionais. A Especificação Suplementar é uma das principais origens para derivação de casos de teste para esses requisitos adicionais.

Veja a seguir as diretrizes para obtenção desses casos de teste adicionais:

• Derivando Casos de Teste para Testes de Desempenho
• Derivando Casos de Teste para Testes de Segurança/Acesso
• Derivando Casos de Teste para Testes de Configuração
• Derivando Casos de Teste para Testes de Instalação
• Derivando Casos de Teste para outros Testes Não Funcionais

Derivando Casos de Teste para Testes de Desempenho

A principal entrada para os casos de teste de desempenho são as Especificações Suplementares que contêm os requisitos não funcionais (consulte Produto de Trabalho: Especificações Suplementares) . Use as seguintes diretrizes ao obter casos de teste para o teste de desempenho:

• verifique se há pelo menos um caso de teste identificado para cada sentença na especificação suplementar, que indica um critério de desempenho. Geralmente, os critérios de desempenho são expressos como tempo por transação, número de transações/usuários ou percentis.
• verifique se há pelo menos um caso de teste identificado para cada caso de uso crítico. Os casos de uso críticos são aqueles identificados nas instruções anteriores e/ou no documento de análise de carga de trabalho que deve ser avaliado utilizando medidas de desempenho (consulte Produto de Trabalho: Documento de Análise da Carga de Trabalho).

Como nos casos de teste para testes funcionais, normalmente haverá mais de um caso de teste por cenário ou requisito de uso. É comum definir vários casos de teste caso - por exemplo, um que esteja abaixo do valor limite de desempenho (taxa média de transações), outro no valor limite (taxa alta de transações) e um terceiro caso de teste acima do valor limite (taxa máxima de transações).

Além dos critérios de desempenho acima, verifique se você conseguiu identificar as condições específicas que afetam os tempos de resposta, inclusive:

• Tamanho do banco de dados - quantos registros existem?
• Carga de trabalho - padrões de transação:
  • tipo, número e freqüência de ações simultâneas do usuário,
  • tipo, número, freqüência e duração de transações simultâneas em execução
• Características do ambiente (configuração de hardware, netware e software)

Uma prática comum é capturar casos de teste para testes de desempenho em matrizes tabulares semelhantes às utilizadas para o teste funcional.

Consulte a seção Definindo Dados de Teste para Casos de Teste para obter detalhes adicionais.

Aqui estão alguns exemplos dos diferentes tipos de Testes de Desempenho:

Para o Teste de Carga:

Para o Teste de Esforço:

Derivando Casos de Teste para Testes de Segurança/Acesso

Os atores e os casos de uso descrevem a interação entre os usuários externos do sistema e as ações executadas pelo sistema a fim de gerar um valor para determinado agente. Os sistemas complexos contêm vários atores, e é essencial desenvolvermos casos de teste para garantir que apenas esses atores especificados executem os casos de uso. Isso ocorrerá especialmente se houver diferenças no fluxo de eventos do caso de uso com base no tipo de agente.

Por exemplo, nos casos de uso de caixa eletrônico, é possível executar diversos fluxos de eventos de caso de uso para o agente "Cliente de Banco" se seu cartão e conta forem do banco que possui o caixa eletrônico versus o "Cliente de Banco" que utiliza um cartão (e conta) de um banco concorrente ou tenta utilizar um cartão bancário não participante.

Siga as mesmas diretrizes listadas acima para os casos de teste funcionais.

Consulte a seção Definindo Dados de Teste para Casos de Teste para obter orientação adicionais.

Exemplo de casos de teste para Segurança e Acesso:

Derivando Casos de Teste para Testes de Configuração

Em sistemas distribuídos comuns, pode haver várias combinações de hardware e software permitidas que serão suportadas. O teste deve ser executado para verificar se o objetivo do teste funciona ou é executado de forma aceitável em configurações distintas, como em diversos sistemas operacionais, navegadores ou velocidades de CPU. Além disso, o teste também precisa abranger combinações de componentes para detectar defeitos provenientes de interações dos diversos componentes, por exemplo, garantir que a versão das DLLs instaladas por um aplicativo não entre em conflito com as versões das mesmas DLLs esperadas por outro aplicativo.

Para obter casos de teste para testes de configuração, use as seguintes diretrizes:

• Verifique se há pelo menos um caso de teste identificando cada configuração crítica. Para isso, basta identificar as configurações de hardware e software necessárias para o ambiente de objetivo do teste e priorizar as configurações, garantindo que as mais comuns sejam testadas primeiro, inclusive:
  • Suporte a impressoras
  • Conexões de rede - redes locais e de longa distância
  • Configurações de servidor - drivers e hardware de servidor
  • Outros softwares instalados na área de trabalho e/ou servidores
  • Versões de software para todos os softwares instalados
• Verifique se há pelo menos um caso de teste para cada configuração suscetível a problemas. Essas configurações podem conter:
  • Hardware com o pior desempenho.
  • Software co-residente com um histórico de problemas de compatibilidade.
  • Clientes que acessam o servidor através da conexão LAN/WAN mais lenta possível.
  • Recursos insuficientes (CPU lenta, memória ou resolução mínima, espaço em disco etc.)

Derivando Casos de Teste para Testes de Instalação

O teste de instalação precisa verificar se é possível instalar o objetivo do teste em todos os possíveis cenários de instalação. Os cenários de instalação podem incluir a instalação do objetivo do teste pela primeira vez ou a instalação de uma nova versão ou build desse objetivo de teste (em uma máquina com a versão anterior). O teste de instalação também deve garantir que o objetivo do teste seja executado de forma aceitável quando ocorrerem condições anormais, como espaço em disco insuficiente.

Os casos de teste devem abranger os cenários de instalação do software, inclusive:

• Mídia de distribuição, por exemplo, disquetes, CD-ROM ou servidor de arquivos.
• Nova instalação.
• Instalação completa.
• Instalações personalizadas.
• Instalações de atualização.

Os programas de instalação para software cliente-servidor têm um conjunto especializado de casos de teste. Diferente dos sistemas baseados em host, o programa de instalação geralmente é dividido entre o servidor e o cliente. Desse modo, é importante que o teste de instalação execute a instalação de todos os componentes do objetivo do teste, inclusive o cliente, as camadas intermediárias e os servidores.

Derivando Casos de Teste para outros Testes Não Funcionais

O ideal é que você encontre todos os recursos necessários para obter os casos de teste nos artefatos Modelo de Casos de Uso, Modelo de Design e Especificação Suplementar. Contudo, não é incomum que, nesse ponto, você precise complementar o que for encontrado.

Estes são alguns exemplos:

• Casos de teste para Testes Operacionais (para verificar se o software funciona quando em uso por "muito tempo" entre defeitos).
• Casos de teste que investigam gargalos de desempenho, recursos de volume do sistema ou forçam uma falha no objetivo do teste.

Na maioria dos casos, você pode encontrar esses casos de teste criando variáveis ou agregados dos casos de teste que você obteve a partir daqueles identificados anteriormente.

Derivando Casos de Teste para Testes de Aceitação do Produto

O teste de aceitação do produto é o teste final antes da implementação do software. A meta do teste de aceitação é verificar se o software está pronto e pode ser utilizado pelos usuários para executar as funções e tarefas para as quais o software foi construído. Esse teste geralmente envolve mais do que a execução da preparação do software. Também envolve todos os produtos de trabalho de produto fornecidos ao(s) cliente(s), como treinamento, documentação e pacotes. 

A derivação dos casos de teste para o(s) produtos de trabalho de software é feito do modo descrito nas seções anteriores. Dependendo do grau e da formalidade do teste de aceitação do produto, os casos de teste serão iguais ou semelhantes aos identificados anteriormente (formais) ou um subconjunto (informais). Independentemente da profundidade dos casos de teste, é necessário haver um acordo entre eles e os critérios de aceitação do produto antes que o teste do produto seja implementado e executado.

A avaliação do(s) produto(s) de trabalho que não são de software varia muito de acordo com o produto de trabalho em avaliação. Consulte as Diretrizes e as Listas de Verificação de cada produto de trabalho específico que não seja de software para obter informações sobre o modo e a finalidade de avaliá-lo.

Criar Casos de Teste de Verificação para Testes de Regressão

O teste de regressão compara dois builds ou duas versões do mesmo objetivo de teste e identifica diferenças como possíveis defeitos. Desse modo, ele pressupõe que uma nova versão deve se comportar como uma versão anterior e verifica se defeitos não foram introduzidos como resultado das mudanças.

O ideal é que todos os casos de teste em uma iteração sejam usados como casos de teste nas iterações posteriores. Utilize as diretrizes a seguir para identificar, criar e implementar os casos de teste que maximizam o valor do teste de regressão e da reutilização, ao mesmo tempo que minimizam a manutenção:

• Garanta que o caso de teste identifique apenas os elementos de dados críticos (os necessários para criar/suportar a condição que está sendo testada)
• Garanta que cada caso de teste descreva ou represente um conjunto exclusivo de entradas ou uma seqüência de eventos que resulte em um comportamento exclusivo do objetivo do teste.
• Elimine casos de teste redundantes ou equivalentes
• Agrupe os casos de teste cujo estado inicial do objetivo do teste e cujo estado dos dados de teste sejam os mesmos

Definindo Dados de Teste para Casos de Teste

Depois que os casos de teste são analisados e existe um acordo / aprovação geral sobre eles, é possível identificar os valores reais dos dados com mais detalhes (por exemplo, na matriz de implementação do caso de teste) e criar os artefatos dos dados de teste.

Consulte Diretriz: Dados de Teste para obter informações adicionais sobre a definição e a manutenção dos dados de teste.