Qualidade de Produtos de Software

Apresentação em tema: "Qualidade de Produtos de Software"— Transcrição da apresentação:

1 Qualidade de Produtos de Software
Renata Bezerra Virgínia Chalegre

2 Roteiro Introdução Modelos de qualidade de produto Teste de Software
Inspeção de Software Modelos de Maturidade de Testes de Software Conclusão Referências

3 Introdução A indústria busca continuamente aprimorar seus produtos de acordo com os padrões mais rigorosos em uso no mundo. Maior qualidade = cliente satisfeito!

4 Introdução Um problema fundamental da qualidade de software é definir claramente os objetivos que se pretende atingir com um projeto.

5 Modelos de Qualidade de Produto

6 ISO 9126 ISO/IEC 9126-1:2001 Modelo de Qualidade
ISO/IEC TR :2003 Métricas Externas ISO/IEC TR :2003 Métricas Internas ISO/IEC TR :2004 Métricas de Qualidade em Uso

7 ISO

8 Medidas de qualidade no uso
ISO 9126 influencia Qualidade de processo Medidas do processo depende de Atributos de qualidade interna Medidas internas Atributos de qualidade externa Medidas externas Processo Produto de Software Atributos de qualidade no uso Medidas de qualidade no uso Contextos de uso

9 ISO 12119 Avaliação de software de prateleira
Estabelece os requisitos de qualidade Fornece instruções para teste, considerando estes requisitos

10 ISO 12119 3. Requisitos de qualidade 3.1. Descrição do Produto
3.2. Documentação do usuário 3.3. Programas e dados 4. Instruções para teste 4.1. Pré-requisitos de teste 4.2. Atividades de teste 4.3. Registro de teste 4.4. Relatório de teste 3. Requisitos de qualidade 3.1. Descrição do Produto Descreve o produto, de forma a ajudar o comprador em potencial, servindo como base para testes. Cada declaração deve ser correta e testável. Deve incluir declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 3.2. Documentação do usuário Deve ser completa, correta, consistente, fácil de entender e capaz de dar uma visão geral do produto. 3.3. Programas e dados Descreve em detalhes cada uma das funções do software, incluindo declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 4. Instruções para teste 4.1. Pré-requisitos de teste Lista de itens necessários para o teste, incluindo documentos incluídos no pacote, componentes do sistema e material de treinamento. 4.2. Atividades de teste Instruções detalhadas sobre os procedimentos de teste, inclusive instalação e execução de cada uma das funções descritas. 4.3. Registro de teste Informações sobre como os testes foram realizados, de tal forma a permitir uma reprodução destes testes. Deve incluir parâmetros utilizados, resultados associados, falhas ocorridas e até a identidade do pessoal envolvido. 4.4. Relatório de teste Relatório incluindo: identificação do produto, hardware e software utilizado, documentos utilizados, resultados dos testes, lista de não conformidade com os requisitos, lista de não conformidade com as recomendações, datas, etc.

11 ISO 14598 É um guia para avaliação de produtos de software, baseado na utilização prática da norma ISO 9126 Contém conceitos para avaliar a qualidade de software e define um modelo de processo de avaliação genérico

12 ISO 14598 Norma Nome Finalidade 14598-1 Visão Geral
Ensina a utilizar as outras normas do grupo. Define os termos técnicos utilizados nas demais partes, contém requisitos gerais para especificação e avaliação de qualidade de software e esclarece os conceitos gerais. Planejamento e Gerenciamento Sobre como fazer uma avaliação, de forma geral Guia para Desenvolvedores Como avaliar sob o ponto de vista de quem desenvolve Guia para Aquisição Como avaliar sob o ponto de vista de quem vai adquirir Guia para Avaliação Como avaliar sob o ponto de vista de quem certifica Módulos de Avaliação Detalhes sobre como avaliar cada característica Junto com as normas NBR ISO/IEC e NBR ISO/IEC estabelecem itens necessários para o suporte à avaliação e junto com as normas NBR ISO/IEC , NBR ISO/IEC e NBR ISO/IEC estabelecem processo de avaliação específico para desenvolvedores, adquirentes e avaliadores de software, respectivamente

13 Projeto SQuaRE Software product Quality Requirements and Evaluation
Manual de utilização e reorganização das normas ISO/IEC 9126 e ISO/IEC

14 Requisitos de Qualidade 2503n Gerenciamento de Qualidade 2501n
Projeto SQuaRE Requisitos de Qualidade 2503n Modelo de Qualidade 2501n Avaliação 2504n Gerenciamento de Qualidade 2501n Medições 2501n Gerenciamento: os documentos desta divisão da norma são voltados a todos os possíveis usuários dela, como gerentes, programadores, avaliadores ou compradores. São definidos os termos utilizados em todos os demais documentos e são feitas recomendações e sugestões de caráter geral sobre como utilizar o SQuaRE. Modelo de Qualidade: esta divisão corresponde principalmente à ISO/IEC São definidos os conceitos de qualidade externa, interna e em uso, que permitem orientar diferentes perspectivas de avaliação. Por exemplo, desenvolvedores e clientes têm visões e preocupações diferentes relacionadas à qualidade do mesmo produto. É definido um modelo hierárquico de características de qualidade, permitindo que se faça uma descrição extensa e precisa do que cada um dos atores envolvidos espera de um produto. Medição: dois pontos importantes fazem parte dessa divisão. Primeiro, definir o que é uma medição e descrever os diversos aspectos relacionados à realização dessa tarefa. Por exemplo: cuidados relacionados com a garantia da precisão dos resultados obtidos. O segundo ponto consiste na proposta de uma série de métricas que podem ser utilizadas ou adaptadas pelos usuários das normas às suas necessidades específicas. Requisitos de Qualidade: umas das noções importantes introduzidas pela 9126 e retomada pelo projeto SQuaRE é estabelecer objetivos de qualidade para um produto. Isto significa que para garantir a qualidade de um produto, apenas realizar medidas não basta: é preciso que alvos tenham sido previamente especificados. Tais valores fazem parte, evidentemente, da especificação dos requisitos do software. Avaliação: a norma SquaRE é concretizada na realização de uma avaliação de qualidade a partir de medições cujos resultados devem ser confrontados contra um modelo definido pelo usuário. A divisão de avaliação é direcionada aos diferentes públicos da norma, como desenvolvedores e compradores. São sugeridos procedimentos a serem adotados em cada caso para realizar uma avaliação.

15 Teste de Software

16 Verificação e Validação
V & V – Verificação e Validação Verificação avalia um produto e determina se está de acordo com os requisitos Validação procura garantir que o produto atenda às necessidades dos clientes Teste de Software – técnica dinâmica de V & V Inspeção de Software – técnica estática de V & V

17 Objetivos Executar o sistema de modo a encontrar defeitos
Garantir que o sistema faz aquilo que é suposto fazer

18 Abordagens de Testes Abordagem Funcional (Caixa Preta)
Software visualizado como uma “caixa preta” Considera os dados de entrada e observa se a saída está de acordo com o esperado

19 Abordagens de Testes Abordagem Estrutural (Caixa Branca)
Interesse no que acontece “dentro da caixa” Avalia as funcionalidades internas dos componentes do software

20 Estágios de Testes Teste de Unidade – testa a estrutura interna e comportamento de componentes individuais Teste de Integração – as unidades da etapa anterior são testadas de forma integrada Teste de Sistema – testa o funcionamento da aplicação como um todo Teste de Aceitação – testes realizados pelos usuários do sistema na tentativa de garantir a sua confiança

21 Tipos de Testes Teste Funcional – focado nas regras de negócio do sistema Teste de Recuperação de Falha – sistema forçada a falhar para analisar o seu comportamento Teste de Segurança – verifica se o sistema previne acesso não autorizado Teste de Carga - mede o comportamento do sistema quando este é submetido a níveis altos de carga Teste de Performance - verifica o rendimento de um sistema

22 Tipos de Testes Teste de Stress - avalia o comportamento do sistema diante de condições que ultrapassem o limite especificado nos requisitos Teste de Configuração - testa o funcionamento do sistema em diferentes configurações de hardware/software Teste de Usabilidade – verifica se o produto tem uma interface amigável Teste de Regressão – re-execução de testes para validar correções realizadas

23 Processo de Testes Planejamento e Controle Análise e Projeto
Implementação e Execução Avaliação do Critério de Saída e Relatório Atividade de Encerramento de Teste

24 Processo de Testes Planejamento e Controle
Determinar o escopo e riscos e identificar os objetivos de teste Determinar a estratégia de teste Definir recursos, humanos e materiais Elaborar cronograma de testes Estabelecer os critérios de saída

25 Processo de Testes Análise e Projeto Revisar a base de testes
Identificar e descrever casos de teste Estruturar procedimentos de teste Avaliar a capacidade de testar os requisitos

26 Processo de Testes Implementação Implementar componentes de apoio
Criar suítes de teste Implementar e verificar o ambiente

27 Processo de Testes Execução
Executar as suítes de teste e casos de teste individuais Seguir as estratégias de teste definidas na etapa de planejamento Criar um log com as saídas da execução dos testes Comparar resultados obtidos com resultados esperados Registrar os defeitos em um repositório centralizado Realização de testes de regressão

28 Processo de Testes Avaliação do critério de saída e relatório
Checar os logs de testes Verificar necessidade de inclusão de mais testes ou mudança nos critérios de saída Escrever um relatório de resumo de testes para os stakeholders Esta é a fase em que se deseja observar se já foram executados testes suficientes para garantir a qualidade desejada do produto

29 Processo de Testes Atividades de Encerramento de teste
Garantir que todos os problemas reportados foram realmente resolvidos Finalizar e arquivar os artefatos produzidos Repassar os artefatos para a equipe de manutenção Avaliar como se deu o processo de testes e analisar as lições aprendidas

30 Processo de Testes X Processo de Desenvolvimento de Software
Modelo V

31 Inspeção de Software

32 Definição Técnica estática do processo de V & V
São efetuadas revisões no sistema com o objetivo de encontrar defeitos Tipicamente são analisados artefatos como: Especificação de Requisitos Projetos e especificações de interface com usuário Projeto de Arquitetura, Projeto de alto nível e Projeto detalhado Código fonte Planos de Teste e casos de Teste

33 Objetivos Identificar quaisquer desvios de padrões
Sugerir oportunidades de melhoria para o autor Promover a troca de experiência entre os participantes

34 A Equipe de Inspeção Autor – desenvolvedor do artefato que será inspecionado Inspetor – examina o produto na tentativa de encontrar defeitos Leitor – apresenta o artefato aos demais participantes Escritor – registra as informações sobre cada defeito encontrado Moderador – possui o papel mais crítico de todo o processo, liderando toda a equipe

35 O Processo de Inspeção

36 O Processo de Inspeção Planejamento O moderador é responsável por:
Selecionar a equipe de inspeção Checar se o produto está pronto para inspeção Organizar a reunião Delegar as atividades de cada membro Garantir a completude dos materiais a serem inspecionados O autor e o moderador decidem quantas reuniões de inspeção serão requeridas

37 O Processo de Inspeção Visão Geral
O autor apresenta as principais características do produto a ser inspecionado É uma etapa opcional e depende da necessidade identificada pelo moderador

38 O Processo de Inspeção Preparação
Os inspetores analisam o produto de trabalho em busca de não-conformidades Fazem as anotações necessárias O moderador analisa os logs antes da reunião para determinar se a equipe está preparada para suas tarefas

39 O Processo de Inspeção Reunião
O leitor realiza a leitura e interpretação do produto O autor tira quaisquer dúvidas que surgirem A equipe de inspetores identifica os possíveis defeitos A reunião não deve passar de duas horas Não devem ser discutidas formas de corrigir os defeitos

40 O Processo de Inspeção Re-Trabalho
O autor corrige os defeitos identificados na reunião Defeitos considerados mais relevantes devem ser corrigidos primeiro

41 O Processo de Inspeção Acompanhamento O moderador:
Analisa o material corrigido pelos autores Verifica se os defeitos foram corrigidos com sucesso Decide se uma nova inspeção é necessária

42 Testes e Inspeção No teste Nas Inspeções Você começa com um problema
Em seguida tem que encontrar o bug Depois, deve imaginar a correção Por fim, implementa e testa a correção Nas Inspeções Você vê o defeito Então imagina a correção Finalmente, implementa e revisa a correção

43 Testes e Inspeção Nos Testes
Se o programa produziu um resultado não usual, você precisa Detectar que aquilo não foi usual Descobrir o que o sistema estava fazendo Encontrar em que ponto estava no programa Descobrir que defeito poderia causar este comportamento estranho

44 Testes e Inspeção Nas Inspeções Você segue sua própria lógica
Quando encontra um defeito, sabe exatamente onde está Você sabe o que o programa deveria fazer e não está fazendo Logo, você sabe porque isto é um defeito Portanto, está em melhor posição para imaginar uma correção completa e eficaz Quando combinadas com testes, o número de defeitos encontrados pode superar os 90% de defeitos existentes

45 Modelo de Maturidade de Testes de Software

46 TPI

47 Elaboração de estratégias combinadas para testes de alto nível.
Níveis A B C D Áreas Chaves Estratégia de Teste Elaboração de simples estratégias para testes de alto nível. Por exemplo: para Testes de Sistemas. Elaboração de estratégias combinadas para testes de alto nível. Elaboração de estratégias combinadas para testes de alto nível e de baixo nível. Estratégia para todos os níveis de testes e combinação. Modelos de Ciclo de Vida Planejamento, Especificação, Execução. Planejamento, Preparação, Especificação, Execução, Finalização. Momento de envolvimento Na conclusão dos documentos base para os testes. No inicia da construção dos documentos base para os testes. Início da especificação dos requisitos Início do Projeto de desenvolvimento. Planejamento e Estimativa Estimativa e planejamento resumidos Estimativas e planejamentos baseados em dados históricos. Técnicas de Especificação de Testes Técnicas informais Técnicas formais

48 Modelo para Implantar Melhorias - TPI
Determinar o alvo e a abordagem: Que áreas serão atacadas ? Primeira avaliação: Conhecimento da situação atual são verificados os pontos fortes e fracos do processo de teste. Definir ações de melhoria: Baseadas nas metas e no resultado da avaliação. Formular plano: O plano aborda as atividades necessárias para orientar o processo de mudança . Implementar ações de melhoria: Execução do plano. São analisadas as ações executadas e bem sucedidas. Avaliação final: Qual foi o rendimento das ações implementadas?

49 TMM

50 TMM Nível 1 – Initial: não existe processo definido. O objetivo dos testes é mostrar que o software funciona. Nível 2 – Phase Definition: planos de teste são estabelecidos contendo estratégias de teste. Nível 3 – Integration: Testes integrados ao ciclo de vida do software. É feito um Master Test Plan. A estratégia de testes é determinada através de técnicas de gerenciamento de riscos e baseada em requisitos.

51 TMM Nível 4 – Management and Measurement: Revisões e inspeções são incorporadas ao ciclo de vida do desenvolvimento. Os produtos de software são avaliados a partir de critérios de qualidade , como reusabilidade e usabilidade. Casos de testes são armazenados e gerenciados em uma base de dados central para reuso e testes de regressão

52 TMM Nível 5 – Optimization: Métodos e técnicas são otimizadas e estão em melhoramento contínuo. A prevenção de defeitos e o controle de qualidade são introduzidos em outras áreas do processo. Há procedimentos para escolha e avaliação de ferramentas de testes.

53 TIM 4 Objetivos gerais com sub-objetivos;
Um objetivo só poderá ser atendido se seus sub-objetivos também forem atendidos Áreas Chave

54 Objetivos - TIM Nível 1 - Baselining
- Padronização dos documentos, métodos e políticas. - Análise e classificação dos problemas. Nível 2 – Cost-efectiveness - Detecção de bugs desde o início do projeto - Automação de tarefas de teste - Treinamento - Reuso

55 Objetivos - TIM Nivel 3 – Risk-lowering
- Envolvimento desde o início do projeto - Análise de custo x benefício para justificar os gastos - Análise de problemas nos produtos e processos - Métricas de produtos, processos e recursos - Análise e gerenciamento de riscos - Comunicação com todas as partes envolvidas nos projetos Nivel 4 - Optimizing - Conhecimento e entendimento através de experimentação e modelagem - Cooperação com todas as partes envolvidas nos projetos em todas as fases do desenvolvimento - Análise das causas raízes para os principais problemas - Melhoria contínua

56 Áreas Chave - TIM Organização Planejamento e Rastreabilidade
Casos de Teste Testware (artefatos de teste) Revisões Aspecto: Organização No nível Baselining deve-se organizar um conjunto mínimo de papéis para executar as atividades básicas de teste. No nível Cost-efectiveness a principal mudança em relação ao modelo organizacional é a independência da equipe de teste. No nível Risk-lowering aumenta a interação entre as equipes de desenvolvimento e a equipe de teste. A equipe de teste necessita conhecer mais sobre o desenvolvimento do produto, de forma a aumentar a qualidade do produto e o conhecimento das regras de negócio. No nível Optmizing os testadores fazem parte do time de desenvolvimento e possuem conhecimento em várias disciplinas. São estabelecidos grupos com o objetivo de avaliar continuamente o processo. Aspecto: Planejamento e Rastreabilidade No nível Baselining o projeto de teste possui um planejamento básico, nele são estabelecidos critérios de entrada e saída, os resultados dos testes são documentados, processados e distribuídos. No nível Cost-efectiveness, o planejamento e a rastreabilidade são auxiliados por ferramentas, alguns planos genéricos são utilizados. A escolha dos estágios e métodos de testes é alinhada de acordo com os objetos e os objetivos dos testes. No nível Risk lowerin,g a análise dos riscos é realizada e sua influência é bastante elevada no planejamento, além de afetar partes do plano, mais precisamente o os objetivos dos testes. No nível Optimizing, atividades de planejamento e a rastreabilidade é continuamente melhorada baseada na análise de métricas. Reuniões de post-mortem são realizadas e os resultados armazenados e distribuídos. Aspecto: Casos de Teste No nível Baseling os casos de testes são elaborados baseados nos requisitos de sistemas e segundo as instruções das políticas. No nível Cost-efectiveness, os casos de testes são projetados de acordo com técnicas documentadas. Com armazenamento dos casos de testes a reusabilidade se torna possível. No nível Risk-lowering, com o armazenamento dos casos de testes no nível anterior é possível selecioná-los de acordo com a criticidade. No nível Optmizing, medições, revisões e melhorias são realizadas sobre os casos de testes. Aspecto: Testware (artefatos de teste) No nível Baselining os problemas são reportados e computados. O nível Cost-efectiveness se caracteriza pelo uso de ferramentas de cobertura, banco de dados para gerenciar o testware. No nível Risk-lowering, são realizados testes de regressão quando o código sofre alteração. A análise de risco é realizada com uso de ferramentas. No nível Optimizing Ambiente de Teste é Integrado. Aspecto: Revisões No nível Baselining, Padrões de revisões de documentos são utilizados . No nível Cost-efectiveness, os projetos e códigos são documentados e revisados através de técnicas de revisão escolhidas pela organização. Técnicas de revisão e inspeção são constantemente evoluídas. Todo o testware, o processo e produto são revisados e medidos no nível de Risk lowering. No nível Optmizing, técnicas e time são selecionados baseados em fatos. Reunião de Post-mortem: é uma reunião com o objetivo de coletar de experiências eficazes e de baixo custo que pode contribuir de forma significativa para a melhoria dos processos de software.

57 Conclusão Garantir a qualidade do produto é essencial
O cliente ficará mais satisfeito Testes e Inspeções contribuem na garantia da qualidade Detectam defeitos e corrigem antes de chegar nas mãos do cliente

58 Dúvidas 58