Qualidade de Produtos de Software

1. Renata Bezerra (rbsa@cin.ufpe.br) Virgínia Chalegre (vcc@cin.ufpe.br) Qualidade de Produtos de Software

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 9126-2:2003 Métricas Externas • ISO/IEC TR 9126-3:2003 Métricas Internas • ISO/IEC TR 9126-4:2004Métricas de Qualidade em Uso

7. ISO 9126 - 1

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

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çõesparateste • 4.1. Pré-requisitos de teste • 4.2. Atividades de teste • 4.3. Registro de teste • 4.4. Relatório de teste

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

13. ProjetoSQuaRE • Software product Quality Requirements and Evaluation • Manual de utilização e reorganização das normas ISO/IEC 9126 e ISO/IEC 14598.

14. ProjetoSQuaRE

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

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 • 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

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: Testesintegradosaociclo de vida do software. É feito um Master Test Plan. A estratégia de testes é determinadaatravés de técnicas de gerenciamento de riscos e baseadaemrequisitos.