Qualidade de Produtos de Software Renata Bezerra ([email protected]) Virgínia Chalegre...

Qualidade de Produtos de Software

Renata Bezerra ([email protected])Virgínia Chalegre ([email protected])


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


IntroduçãoA indústria busca continuamente

aprimorar seus produtos de acordo com os padrões mais rigorosos em uso no mundo.

Maior qualidade = cliente satisfeito!


IntroduçãoUm problema fundamental da

qualidade de software é definir claramente os objetivos que se pretende atingir com um projeto.


Modelos de Qualidade de

Produto


ISO 9126 ISO/IEC 9126-1:2001

Modelo de Qualidade ISO/IEC TR 9126-2:2003

Métricas Externas ISO/IEC TR 9126-3:2003

Métricas Internas ISO/IEC TR 9126-4:2004

Métricas de Qualidade em Uso


ISO 9126 - 1


ISO 9126

influencia influencia influenciaQualidade

de processo

Medidas do processo

depende de

Atributos de

qualidade interna

Medidas internas

depende de

Atributos de

qualidade externa

Medidasexternas

depende de

Processo Produto de Software

Atributos de

qualidade no uso

Medidas de qualidade no

uso

Contextos de uso


ISO 12119

Avaliação de software de prateleira

Estabelece os requisitos de qualidade

Fornece instruções para teste, considerando estes requisitos


ISO 121193. Requisitos de qualidade 3.1. Descrição do Produto 3.2. Documentação do usuário 3.3. Programas e dados4. 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


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


ISO 14598Norma 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.

14598-2 Planejamento e Gerenciamento

Sobre como fazer uma avaliação, de forma geral

14598-3 Guia para Desenvolvedores Como avaliar sob o ponto de vista de quem desenvolve

14598-4 Guia para Aquisição Como avaliar sob o ponto de vista de quem vai adquirir

14598-5 Guia para Avaliação Como avaliar sob o ponto de vista de quem certifica

14598-6 Módulos de Avaliação Detalhes sobre como avaliar cada característica


Projeto SQuaRESoftware product Quality

Requirements and Evaluation Manual de utilização e

reorganização das normas ISO/IEC 9126 e ISO/IEC 14598.


Projeto SQuaRE

Requisitos de Qualidade

2503n

Modelo de Qualidade

2501n

Avaliação2504nGerenciamento

de Qualidade 2501n

Medições2501n


Teste de Software


Verificação e ValidaçãoV & 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


ObjetivosExecutar o sistema de modo a

encontrar defeitosGarantir que o sistema faz aquilo

que é suposto fazer


Abordagens de TestesAbordagem 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


Abordagens de TestesAbordagem Estrutural (Caixa Branca)

Interesse no que acontece “dentro da caixa”

Avalia as funcionalidades internas dos componentes do software


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


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


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


Processo de TestesPlanejamento e ControleAnálise e Projeto Implementação e ExecuçãoAvaliação do Critério de Saída e

RelatórioAtividade de Encerramento de

Teste


Processo de TestesPlanejamento e Controle

Determinar o escopo e riscos e identificar os objetivos de teste

Determinar a estratégia de testeDefinir recursos, humanos e

materiaisElaborar cronograma de testesEstabelecer os critérios de saída


Processo de TestesAnálise e Projeto

Revisar a base de testesIdentificar e descrever casos de testeEstruturar procedimentos de testeAvaliar a capacidade de testar os

requisitos


Processo de Testes Implementação

Implementar componentes de apoioCriar suítes de testeImplementar e verificar o ambiente


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


Processo de TestesAvaliação do critério de saída e

relatórioChecar os logs de testesVerificar 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


Processo de TestesAtividades 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


Processo de Testes X Processo de

Desenvolvimento de SoftwareModelo V


Inspeção de Software


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


ObjetivosIdentificar quaisquer desvios de

padrõesSugerir oportunidades de melhoria

para o autorPromover a troca de experiência

entre os participantes


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


O Processo de Inspeção


O Processo de InspeçãoPlanejamento

O moderador é responsável por:Selecionar a equipe de inspeçãoChecar se o produto está pronto para

inspeçãoOrganizar a reuniãoDelegar as atividades de cada membroGarantir a completude dos materiais a serem

inspecionadosO autor e o moderador decidem quantas

reuniões de inspeção serão requeridas


O Processo de InspeçãoVisão Geral

O autor apresenta as principais características do produto a ser inspecionado

É uma etapa opcional e depende da necessidade identificada pelo moderador


O Processo de InspeçãoPreparação

Os inspetores analisam o produto de trabalho em busca de não-conformidades

Fazem as anotações necessáriasO moderador analisa os logs antes da

reunião para determinar se a equipe está preparada para suas tarefas


O Processo de InspeçãoReuniã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


O Processo de InspeçãoRe-Trabalho

O autor corrige os defeitos identificados na reunião

Defeitos considerados mais relevantes devem ser corrigidos primeiro


O Processo de InspeçãoAcompanhamento

O moderador:Analisa o material corrigido pelos autoresVerifica se os defeitos foram corrigidos

com sucessoDecide se uma nova inspeção é

necessária


Testes e Inspeção No teste

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


Testes e InspeçãoNos Testes

Se o programa produziu um resultado não usual, você precisa

Detectar que aquilo não foi usualDescobrir o que o sistema estava

fazendoEncontrar em que ponto estava no

programaDescobrir que defeito poderia causar

este comportamento estranho


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


Modelo de Maturidade de

Testes de Software


TPI


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


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?


TMM


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.


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


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.


TIM

4 Objetivos gerais com sub-objetivos; Um objetivo só poderá ser atendido se

seus sub-objetivos também forem atendidos

Áreas Chave


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


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


Áreas Chave - TIMOrganizaçãoPlanejamento e RastreabilidadeCasos de Teste Testware (artefatos de teste)Revisões


ConclusãoGarantir a qualidade do produto é

essencialO cliente ficará mais satisfeitoTestes e Inspeções contribuem na

garantia da qualidadeDetectam defeitos e corrigem antes

de chegar nas mãos do cliente


Dúvidas

Qualidade de Produtos de Software Renata Bezerra ([email protected]) Virgínia Chalegre...

Documents

Transcript of Qualidade de Produtos de Software Renata Bezerra ([email protected]) Virgínia Chalegre...