Validação dos requisitos do sistema

Esta fase é iniciada pela equipe de desenvolvimento juntamente com os usuários. Nela, os trabalhos de elicitação, análise e especificação dos requisitos são direcionadas conforme as técnicas escolhidas para cada uma das fases.

Ao final da etapa de especificação dos requisitos, o documento dos requisitos é gerado. A partir daí, a equipe de teste é envolvida para validação dos requisitos já documentados, conforme mostra a Figura 5.2.

Com o documento dos requisitos em mãos, a equipe de teste inicia as atividades de criação dos casos de teste (processo 1 na Figura 5.2) . Em paralelo à criação das condições de teste a prototipação é também iniciada (processo 3 na Figura 5.2). Ao término do processo de criação dos casos de teste o relatório de quantidade de casos de teste por requisito é gerado e analisado (processo 2 na Figura 5.2). A análise deste relatório nos dirá também se existe algum requisito que deva também utilizar a prototipação para sua validação (arco conectando o processo 2 ao processo 3 na Figura 5.2). As linhas pontilhadas significam que o processo de prototipação será utilizado no processo proposto quando as funcionalidades exigirem tal tipo de validação. Caso contrário, utilizamos somente a técnica de teste de requisitos para validação (processo 1 na Figura 5.2).

Terminados os três processos, é gerada uma lista com os problemas encontrados e ações acordadas. A lista de problemas deve relatar todos os problemas identificados no documento de especificação (processo 4 na Figura 5.2), classificando-os de alguma forma, como por exemplo:

ambigüidade, inconsistência, etc. As ações acordadas são ações a serem executadas a partir dos problemas relacionados na lista de problemas [MAR01].

A seguir detalharemos cada processo dentro da etapa de validação dos requisitos: Criação dos casos de teste e Teste dos requisitos, Análise da Quantidade de Requisitos por Casos de Teste, Prototipação e Alteração dos Requisitos.

5.2.1.1 Criação dos Casos de teste e Teste dos Requisitos

É preciso ter em mente que o objetivo do uso de casos de teste (processo 1 na Figura 5.2) nesta fase é validar o requisito e não o sistema. Todos os participantes desta atividade, ou seja, usuários, equipes de desenvolvimento e de teste, devem ter ciência disto.

Outro ponto muito importante nesta atividade é a participação ativa das pessoas chaves. Elas devem ser usuários experientes que consigam abstrair as novas funcionalidades visualizando o procedimento correto para testar o requisito.

Esta técnica foi escolhida por possuir algumas vantagens. São elas: iniciação do processo de criação de casos de teste na fase inicial do projeto, reuso dos casos de teste em fases posteriores e interação da equipe de teste com a equipe de desenvolvimento e do projeto desde o início.

Neste processo é muito importante a documentação dos testes para que os resultados possam ser analisados posteriormente e que os casos de testes dos requisitos possam ser aproveitados nas próximas fases como fontes de conhecimento futuro. Utilizamos dois documentos para armazenar os casos de teste apoiados na norma IEEE 829 [IEEE829-98]: Especificação de casos de teste e Especificação de roteiro de teste. As informações armazenadas nestes documentos são mostradas na Figura 5.3 e Figura 5.4.

Esses documentos nos possibilitam armazenar os casos de teste e testá-los, de forma a manter um histórico de todo o processo de teste. Eles servirão posteriormente como repositório de dados do projeto e devem também ser usados, quando possível, nos testes de aceitação para garantir que o que foi acordado no início é realmente o que está sendo entregue [RAM96].

Documento dos Requisitos Prototipação Criação dos Casos de Teste e Teste dos Requisitos Análise: Quantidade de Casos de Teste X Requisitos Alteração dos Requisitos

Requisitos novos, alterados ou excluídos

VALIDAÇÃO DOS REQUISITOS DO SISTEMA

Casos de Teste

Documentos especificados no processo proposto

Processos especificados no processo proposto

Documento dos Requisitos Validados

Fluxo usado em projetos de complexidade alta

1 2 3 4 Lista de Problemas e Ações Acordadas Execução de Testes Manuais L inh a do T emp o TESTES DE ACEITAÇÃO Execução de Testes Automatizados Casos de Teste 5 Relatório de Incidentes de Teste Diário de Teste

Documentos não especificados no processo proposto

n Númeração dada aos processos especificados

Especificação de Casos de Teste

Número do Requisito Número seqüencial.

Descrição do Requisito Breve descrição de forma a identificar o mesmo. Número da Condição de

teste

Número seqüencial seguindo o seguinte formato:

requerimento.condição. Ex.: 1.1 = Condição de Teste 1 do Requisito 1.

Condição de Teste Texto explicativo da condição de teste

Número seqüencial que referencia o roteiro de teste. Número do Roteiro de

Teste

Figura 5.3 - Especificação de Casos de Teste usado na criação e execução dos casos de teste.

Especificação de Roteiro de Teste

Número do Roteiro Número seqüencial

Descrição do Roteiro Breve descrição do roteiro de teste Escrito por Nome de quem criou o roteiro de teste

Data Data da criação do roteiro

Número da Condição de teste

Número da condição de teste que o roteiro irá exercitar. Um roteiro de teste pode exercitar mais de uma condição de teste. Texto explicativo da condição de teste. Mesmo texto contido no Relatório de Casos de teste.

Condição de Teste

Pré Condições Condições necessárias para a execução do teste.

Número seqüencial. Um roteiro de teste pode exigir mais de um passo para sua execução.

Passos

Ação Descrição das ações que devem ocorrer para execução do passo. Resultado Esperado O que se espera da ação executada.

Resultado Atual - (P)assou

ou (F)alhou Status do resultado esperado.

Resolução/Comentário Caso tenha ocorrido alguma falha, explicar o ocorrido. Ou algum comentário importante.

Figura 5.4 - Especificação de Roteiro de Teste usado na criação e execução dos casos de teste.

5.2.1.2 Análise: Quantidade de Requisitos X Casos de Teste

Dificuldades no processo de geração de casos de teste significam que ou o requisito não está claro ou não é testável, o que implica em revisão da definição do requisito.

A análise das ligações de requisitos a casos de teste identifica requisitos não testáveis e/ou requisitos que, por terem muitas ligações, dificultam o processo de verificação da correção. A Figura 5.5 mostra que a simples análise visual dessas ligações aponta requisitos que se enquadram no caso de requisitos não testáveis [SAY03].

Figura 5.5 - Ligações de requisitos a casos de teste [SAY03].

A contagem dos casos de teste por requisitos é uma métrica simples de obter [SAY03]. Os valores obtidos deverão gerar um gráfico, como o mostrado na Figura 5.6. A análise do gráfico resultante é um bom parâmetro para apontar requisitos cuja verificação é complexa, pois exigem a execução de um grande número de casos de teste para concluir sobre sua correção [SAY03]. Estes dados também definem quais requisitos devem ser adicionalmente validados pelo processo de prototipação (processo 3 na Figura 5.2). Ou seja, quanto mais complexo é o requisito, maior a necessidade de validá-lo com qualidade.

A título de exemplo, observamos na Figura 5.6 que para o requisito de número 4 foi criado apenas um caso de teste e que os requisitos de número 3,8 e 11 possuem 6 casos de teste cada um. Já para um único requisito, o requisito de número 9, não foi criado nenhum caso de teste.

A quantidade de casos de teste por requisitos é extraída da Especificação de Casos de Teste descrito na Figura 5.3.

7 8 6 1 18 10 7 6 0 7 6 0 2 4 6 8 10 12 14 16 18 Número de Requisitos 1 2 3 4 5 6 7 8 9 10 11

Número do Caso de Teste

Número de Requisitos por Caso de Teste

Figura 5.6 - Exemplo de possível distribuição de requisitos por caso de teste.

5.2.1.3 Prototipação

Grande parte dos protótipos usados para validação dos requisitos foi utilizada também no processo de elicitação. Segundo Lopes [LOP02], construir um protótipo apenas para validação dos requisitos não é economicamente atraente. Porém, caso o processo de análise da quantidade de casos de teste por requisitos (processo 2 na Figura 5.2) encontre algum requisito com quantidade alta de casos de teste, recomenda-se o uso da prototipação para sua validação pois é um bom sinal de que o requisito possui uma verificação complexa ou que há necessidade de ampla cobertura de testes.

Outros motivos reforçam o uso da prototipação como ferramenta de validação de requisitos: aquisição de experiência para uso em etapas posteriores do projeto, utilização do protótipo na fase de teste para aumento da cobertura dos testes e interação da equipe de teste com a equipe de desenvolvimento desde o início do projeto para permitir a troca de conhecimentos.

5.2.1.4 Alteração dos Requisitos

Os processos descritos nas Seções 5.2.2.1, 5.2.2.2 e 5.2.2.3 geram um relatório: Lista de problemas e Ações acordadas. Este relatório contém as alterações que devem ser feitas no documento dos Requisitos e ajudarão no processo de rastreamento dos requisitos.