Testes Baseados em Requisitos

Nas definições das fases de testes da seção anterior pode-se observar que são propostos testes baseados em requisitos. Isto significa que o desenvolvimento dos projetos também deverá ser focado em requisitos. Iremos apresentar outra definição para requisito, além da já apresentada no capítulo1. De acordo com o Glossário da IEEE 610.12-1990 ([Iee90]) requisito é:

1. Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo;

2. Uma condição ou capacidade que deve estar presente num sistema para satisfazer um contrato, padrão, especificação ou outro documento formal;

3. Uma representação documentada de uma condição ou capacidade de acordo com as definições (1) e (2).

Para a MTS os requisitos podem ser de diferentes tipos (requisito de negócio, de usuário, funcional, não funcional e detalhado) e define cada um deles conforme mostrado a seguir.

Requisitos de Negócio: São focados no entendimento do por quê o projeto ou sistema é

necessário e como contribuirá para os objetivos do negócio. Correspondem a objetivos, metas ou “desejos” da área de negócios. São escritos na linguagem da área de negócios e podem conter gráficos, tabelas e diagramas.

Requisitos de Usuário: Diz o que o usuário estará habilitado a realizar com o sistema ou

produto. São escritos sob o ponto de vista do usuário e podem conter "use-cases", cenários e processos de negócios. Os Requisitos de Usuário derivam dos Requisitos de Negócio e servem como base para os Requisitos Funcionais e Não-Funcionais.

Requisitos Funcionais: Determinam quais as funcionalidades que serão disponibilizadas

pelo sistema ou produto. Especifica, por exemplo, as ações, processamentos, respostas, cálculos e relatórios. Os Requisitos Funcionais são base para os Requisitos Não-Funcionais e Detalhados.

Requisitos Não-Funcionais: Referem-se às qualidades, características e restrições dos

Requisitos Funcionais e podem referir-se também aos Requisitos de Negócio ou de Usuário. São bases para os Requisitos Detalhados. Exemplos de tipos de Requisitos Não Funcionais: Operacionais (aparência, facilidade de uso); Desempenho (tempo de resposta); Recuperação (o que precisa ser feito antes e depois de uma falha); Disponibilidade (razão entre o tempo durante o qual um software se mantém operacional); Segurança (a segurança, a confidencialidade e a integridade do sistema); Testabilidade (funcionalidades que devem ser apresentadas para facilitar a preparação, execução ou evidenciação de testes); e Portabilidade (o sistema pode ser portado para outras plataformas).

Requisitos Detalhados: Como os Requisitos Funcionais e Não-Funcionais serão

implementados. São escritos sob a ótica dos desenvolvedores e contém especificações detalhadas sobre a implementação do sistema. Servem de base para o projeto físico e a programação.

Requisito de Teste

Um conceito importante para a MTS é o de requisito de teste. Um requisito de teste diz em algumas linhas como o requisito será testado. Um requisito pode ser decomposto em alguns requisitos de teste. Quando da execução dos testes, são os requisitos de teste que são validados e verificados e conseqüentemente e indiretamente, os requisitos também. O requisito de teste deve ser registrado no documento GRT – Gestão e Rastreabilidade dos Testes, que será apresentado na seção 3.4.2. No capítulo 4 entraremos em mais detalhes sobre somo deve ser a implementação da automação dos requisitos de testes.

A partir do requisito de teste podem ser especificados casos de testes. Os casos de testes são detalhamentos do requisito de teste, é no caso de teste que definiremos os valores de entrada e saída esperada para o teste, os passos necessários para a sua execução e o que deve ser feito antes e depois da execução do teste. Por exemplo, para uma aplicação que permita saques entre R$10,00 e R$ 500,00 múltiplos de 10, um requisito de teste poderia ser “Realizar saques superiores a R$ 500,00”. Este requisito de teste poderia gerar um caso de teste com valor de R$ 510,00, cujo resultado esperado é “saque inválido”. Um outro requisito de teste poderia ser “Realizar saques entre R$ 10,00 e R$ 500,00 não múltiplos de 10”. Este requisito de teste poderia gerar um caso de teste como R$ 15,00. A metodologia permite que, caso se deseje, não se registre

os casos de teste; a execução e o controle se o teste passou ou falhou pode ser feita diretamente no requisito de teste.

Revisões técnicas nos Requisitos

Como dissemos, para a MTS os testes caixa preta devem ser baseados em requisitos, surge uma questão: e se os requisitos não estiverem bem definidos? Vamos projetar testes que validem os requisitos, então é necessário que se tenha um mínimo de garantia de que estes requisitos estão bem definidos. Por isso a metodologia de testes considera fundamental que se faça revisões técnicas dos requisitos. Além disso, a revisão dos requisitos permite localizar e remover defeitos mais cedo e a menores custos, em comparação com o custo de remover o mesmo defeito em momentos posteriores.

A importância do documento de requisitos sugere um maior rigor na sua revisão. A falta de clareza nos requisitos, ou pior, a falta deles, é uma das razões mais freqüentes de insucesso na construção de sistemas. Devem ser questionados os requisitos evitando que requisitos incompletos, ambíguos, não realizáveis e não testáveis migrem para as fases seguintes de desenvolvimento.

Os requisitos devem ser revisados por alguém que não o seu autor, e com bons conhecimentos em requisitos e das técnicas de revisões de requisitos. As atividades de revisões de requisitos devem ser executadas nas fases iniciais do projeto no momento em que são gerados.

Os problemas encontrados nos requisitos pelas revisões devem ser registrados e acompanhados até o encerramento. Este registro e acompanhamento devem ser feitos no documento RF – Registro de Falhas, que veremos posteriormente.