Levantamento, Análise e GestãoRequisitos

Aula 09

Validação:● Critérios● Revisões dos Requisitos● Prototipação● Geração de Casos de Teste● Funcionais

Agenda

● Certificar que o documento de requisitos é uma descrição aceitável do sistema a implementar● Verificar se o documento de requisitos:

● É completo e consistente● Está em conformidade com os padrões da

organização● Não existem conflitos entre requisitos● Não existem erros técnicos● Não existem requisitos ambíguos

● Validação é importante uma vez que o custo para remover um erro de requisitos é grande

Validação de Requisitos

● Os requisitos estão claramente estabelecidos?● A fonte (pessoa, regulamento, documento) do requisito está identificada?● O requisito está limitado em termos quantitativos?● Que outros requisitos se relacionam a este requisito?● O requisito viola alguma restrição do domínio?● O requisito pode ser testado? É possível definir critérios de validação para os requisitos?● A especificação está estruturada, levando a fácil entendimento?● Os requisitos associados com o desempenho, comportamento e características operacionais do sistema foram claramente declarados?

Checklist para Validação de Requisitos

● Documento de requisitos● Versão completa do documento formatado● Organizado de acordo com os padrões da empresa

● Conhecimento organizacional● Conhecimento implícito da organização● Usado para avaliar o realismo do requisitos

● Padrões da organização● Usar padrões locais para a organização do

documento de requisitos

Itens para Validação de Requisitos

● Problemas:● São encontrados no documento de requisitos● Podem ter várias ações corretivas● Podem não ter quaisquer ações associadas

● Criar um Lista de Ações acordada em resposta aos problemas encontrados

Problemas na Validação de Requisitos

● Revisão de requisitos● Análise manual sistemática dos requisitos

● Prototipação● Uso de um modelo executável do sistema

para checar os requisitos● Geração de casos de teste

● Desenvolver testes para os requisitos a fim de verificar a testabilidade

Técnicas de Validação de Requisitos

Durante uma reunião...- O sistema que queremos deve fazer isto, isto, e

nesse caso também isto...- Sim, Sim, estou anotando...- Conversei com os usuários e basicamente este é o

sistema que teremos que desenvolver.- Sim- Ótimo, começaremos a especificar os requisitos

imediatamente.

Revisões de Requisitos – Um Caso Comum

Quatro meses depois ...- Senhores usuários, após o emprego das mais

modernas técnicas de especificação, produzimos este documento que descreve minuciosamente o Sistema.

- Ótimo! Bom! Hum! ... É um documento com 300 páginas e todos estes gráficos, tabelas. Enfim, vamos analisá-los e voltamos a falar.

Revisões de Requisitos – Um Caso Comum

Mais um mês e meio...- Sr. Analista, nosso pessoal

analisou com cuidado o documento. Tivemos muitas dificuldades em entendê-lo. Mas o que percebemos é que NÃO FOMOS CORRETAMENTE ENTENDIDOS!!!

- Como não? Tudo que está aí foi fruto de nosso entendimento pessoal. REALMENTE VOCÊS NÃO SABEM O QUE QUEREM!!!

Revisões de Requisitos – Um Caso Comum

Clientes Satisfeitos

10/08/11

● Estão assim quando: Atende todas expectativas Entrega no prazo Entrega no orçamento

● Tudo começa com Requisitos

Definindo o Sucesso de Software

Especificação

Desenvolvimento

Validação

Versão Inicial

Vesão InicialVesão InicialVersões Intermediárias

Versão Final

DescriçãoAlto Nível

Prototipação

Prototipação – Vantagens

● Contribuem para melhorar a qualidade da especificação dos futuros programas● Leva à diminuição dos gastos com manutenção• O treinamento dos usuários pode ser feito antes do produto ficar pronto• Algumas partes do protótipo podem vir a ser usadas no desenvolvimento do sistema finalObs: comum em métodos ágeis!

• Em geral o grande argumento contra a construção de protótipos é o custo• A construção do protótipo atrasa o início daimplementação do sistema final• Atrasos são um dos maiores problemas dos projetos de software• Construir um protótipo pode não ser tão mais rápido do que construir o sistema final• Se os ambientes utilizados forem diferentes este custo será um custo extra

Prototipação – Desvantagens

● Verificação – conjunto de atividades que garante que o software implemente corretamente uma função específica Estamos construindo certo o produto?● Validação – refere-se a um conjunto de atividades que garante que o software foi construído de acordo com as exigências do cliente Estamos construindo o produto certo?

Verificação e Validação

Os programas possuem um grande número de estados com rotinas complexas, atividades e algoritmosO tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumenta ainda mais a complexidade

Falha de Software

● Dizer que um programa falhou significa que o seu funcionamento não está de acordo com o esperado● A falha pode ser originada por diversos motivos, como:

● A especificação pode estar errada ou incompleta● A especificação pode conter requisitos impossíveis de

serem implementados ● Pode ser que haja erros no código, o algoritmo ● Pode estar implementado de forma errada ou

incompleta● Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema

Falha de Software

Atividade de Teste segundo o RUP

● Atividade de teste inicia-se no nível de módulos e prossegue “para fora” na direção da integração de todo o sistema baseado em computador● Diferentes técnicas de teste são apropriadas e diferentes pontos do tempo● Realizada pela equipe de desenvolvimento ou por um grupo de teste independente● Atividades de teste e de depuração são diferentes, a depuração deve ser acompanhada de uma estratégia de teste

Abordagem Estratégica ao Teste de Software

● Depois da integração os critérios de validação especificados na análise de requisitos devem ser testados● Garante exigências funcionais, comportamentais e de desempenho● Após a realização do teste: As características de função ou desempenho

conformam-se as especificações e são aceitas Se um desvio é descoberto e uma lista de

deficiências é criada

Estratégica ao Teste de Software

Modelo de TesteMétodo da Caixa Branca ● Método estrutural avalia o comportamento interno do componente de software para determinar defeitos na estrutura interna ou no código-fonte do software● Desenvolvido analisando-se o código-fonte e elaborando-se casos de teste que cubram todas as possibilidades do algoritmo implementado● Todas as variações originadas por estruturas de condições são testadas● São de responsabilidade dos desenvolvedores, já que estes têm conhecimento amplo do código-fonte● Recomendado para as fases de Teste de Unitário e de Integração

Método da Caixa Preta

● Tem por objetivo determinar se os requisitos foram total ou parcialmente satisfeitos pelo software● Verifica apenas os resultados produzidos e não requer conhecimento interno do sistema, apenas conhecimento dos requisitos do negócio● É aplicável a todas as fases de teste do processo de software● Devem ser desenvolvidos pelos membros da equipe que melhor conhecem os requisitos do sistema

Modelo de Teste

Estrutural (estamos construindo certo o produto?)Casos de teste concentrados na estrutura de controle, em nível de módulo de programa

Caixa Branca

Funcional (estamos construindo o produto certo?)Casos de teste concentrados nos requisitos

Caixa Preta

Modelo de Teste

● Atualmente, existem muitas maneiras de se testar um software:

● Teste de Unidade ou Unitário● Teste de Integração● Teste de Sistema● Teste de Aceitação● Teste de Recuperação● Teste de Segurança● Teste de Stress● Teste de Desempenho● Teste de Operação● Teste de Regressão

Estratégica ao Teste de Software

● Testar as menores unidades de software desenvolvidas (pequenas partes ou unidades do sistema) ● O universo alvo desse tipo de teste são os métodos dos objetos ou pequenos trechos de código● O objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema

1. Teste Unitário

● Precedência aritmética incorreta● Inicialização incorreta● Erro de precisão● Representação simbólica incorreta de uma expressão● Variáveis de laço impropriamente modificadas

Teste Unitário – Erros Comuns

Casos de teste devem descobrir erros de fluxo de controle e comparações:● Comparação de diferentes tipos de dados● Operadores lógicos ou precedência incorreta● Expectativa de igualdade quando um erro de

precisão torna a igualdade improvável● Comparação ou variável incorreta● Término de laço impróprio ou inexistente● Variáveis de laço impropriamente modificadas

Teste Unitário – Erros Comuns

● Descrição do erro é inteligível● Erro apontado não corresponde ao erro encontrado● Condição de erro provoca intervenção no sistema

antes do tratamento do erro● Processamento das condições de exceção é incorreto● Descrição do erro não oferece nenhuma informação

que ajude na localização da causa do erro

Teste Unitário – Erros Comuns

2. Teste de Integração

Máxima: Se todos os módulos funcionam individualmente porque se tem dúvida de que eles funcionarão quando colocados juntos?

● Dados podem ser perdidos ao longo da interface● Um módulo pode ter um efeito inesperado● Funções quando combinadas podem não produzir a função principal esperada

● Integração big-bang o programa completo é testado como um todo● Integração incremental o programa é construído e testado em pequenos segmentos, os erros são mais fáceis de serem encontrados e corrigidos

Tipos de Teste de Integração

M1

M3

M7

M4M2

M5 M6

M8

● Os módulos são integrados movimentando-se de cima para baixo● módulos subordinados podem ser incorporados de uma maneira depth-first ou breadth-first

Teste de Integração – Top Down

M1

M3M2

Módulos são integradosmovimentando-se de baixo para cima

D1 D2

Cluster

Teste de Integração – Buttom Up

● Tipo de teste caixa preta cujo objetivo é testar todos os elementos do sistema de ponta a ponta● Normalmente realizado quando o software esta funcionando completamente

3. Teste de Sistema

● Verificar se elementos como hardware, pessoas, bancos de dados, ou outros estão adequados em função do desempenho global do sistema:

● Projetar casos de teste que simulem todas as entradas de dados de outros sistemas

● Realizar testes simulando dados ruins ou erros em potencial para a interface

● Registrar e documentar o caso de testes● Participar do planejamento para garantir que o

teste seja adequado

Teste de Sistema

4. Teste de Aceitação

● Teste conduzido por usuários finais do sistema● Simula operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado● Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais● Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho

● Capacitam o cliente a validar todos os requisitos● Realizado pelo usuário final e não pelo desenvolvedor do sistema:

Teste Alfa – é levado a efeito por um cliente nas instalações do desenvolvedor. Erros e problemas serão registrados durante a interação

Teste Beta – é realizado nas instalações do cliente pelo usuário final. A interação não é controlada pelo desenvolvedor, problemas encontrados são relatados posteriormente ao desenvolvedor

Teste Gama – A comunidade do teste de software usa este termo de forma sarcástica referindo-se aos produtos que são mal testados e são entregues aos usuários para que estes encontrem os defeitos já em fase de produção

Tipos de Teste de Aceitação

● Um processo altamente gerenciado e costuma ser uma extensão do teste do sistema ● Os testes são planejados e projetados com o mesmo cuidado e nível de detalhe do teste do sistema● Os casos de teste escolhidos devem ser um subconjunto dos que foram realizados no teste do sistema● É importante não se distanciar de nenhuma forma dos casos de teste escolhidos● Em muitas organizações, o teste de aceitação formal é totalmente automatizado

Teste de Aceitação Formal

● Funções e os recursos a serem testados são conhecidos● Detalhes dos testes são conhecidos e podem ser medidos● Testes podem ser automatizados, o que permite o teste de regressão● Progresso dos testes pode ser medido e monitorado● Critérios de aceitabilidade são conhecidos

Benefícios do Teste de Aceitação Formal

● Procedimentos para executar o teste não são definidos com tanto rigor como no teste de aceitação formal● Funções e as tarefas de negócios a serem exploradas são identificadas e documentadas, mas não há casos de teste específicos para seguir● Testador individual determina o que fazer● Essa abordagem de teste de aceitação não é tão controlada como o teste formal e é mais subjetiva do que o tipo formal

Teste de Aceitação Informal

● Funções e os recursos a serem testados são conhecidos● Progresso dos testes pode ser medido e monitorado● Critérios de aceitabilidade são conhecidos● Serão revelados defeitos mais subjetivos do que no teste de aceitação formal

Benefícios do Teste de Aceitação Informal

● Forçar o software a falhar de diversas maneiras ● Verificar se a recuperação é adequadamente executada● Verificar a robustez e também a capacidade de um determinado software● Retornar a um estado operacional após estar em um estado de falha

5. Teste de Recuperação

● Verificar se todos os mecanismos de proteção embutidos em um sistema, de fato, estão ativos

O papel do projetista do sistema é fazer com que o acesso custe mais do que o valor da informação que será obtida

6. Teste de Segurança

● Executar o sistema de forma a exigir recursos em quantidade, frequência e volume anormais

Exemplo: Casos de teste que exigem máxima memória

7. Teste de Stress

●Testar o desempenho de run-time do software dentro do contexto de um sistema integrado● Ocorre ao longo de todos os processos de teste, porém só quando todos os módulos estão interligados é que o desempenho real pode ser verificado

8. Teste de Desempenho

9. Teste de Operação

● Teste que é conduzido pelos administradores do ambiente final onde o sistema ou software entrará em ambiente produtivo● Aplicável somente a sistemas de informação próprios de uma organização● Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida● Envolver os testes de instalação, simulações com backup e restauração das bases de dados, entre outros

10. Teste de Regressão

● Teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento

● Consistir em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema● Observar o impacto de alterações provocado pela nova versão ou ciclo de teste

Paralelismo entre as Atividades de Desenvolvimento

Dúvidas? AgradecimentosDúvidas? Agradecimentos

Home PageHome Pagehttp://fernandoans.site50.nethttp://fernandoans.site50.net

BlogBloghttp://fernandoanselmo.blogspot.comhttp://fernandoanselmo.blogspot.com

X25 Home PageX25 Home Pagehttp://www.x25.com.brhttp://www.x25.com.br

Fernando AnselmoFernando Anselmofernando.anselmo@x25.com.brfernando.anselmo@x25.com.br