RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos

Transcrição

1 Universidade de Pernambuco Escola Politécnica de Pernambuco Departamento de Sistemas e Computação Programa de Pós-Graduação em Engenharia da Computação Ellen Polliana Ramos Souza RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos Dissertação de Mestrado Recife, Dezembro de 2008 i

2 ELLEN POLLIANA RAMOS SOUZA RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos DISSERTAÇÃO APRESENTADA AO PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO DA UNIVERSIDADE DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO TÍTULO DE MESTRE EM ENGENHARIA DA COMPUTAÇÃO. Orientador: Prof. Dra. Cristine Martins Gomes de Gusmão Recife, Dezembro/2008. ii

3 S729r Souza, Ellen Polliana Ramos RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos / Ellen Polliana Ramos Souza. Recife : O Autor, vi, 129 f. : 27 fig., 39 tab. Dissertação (mestrado) Universidade de Pernambuco. DSC Engenharia da Computação, Inclui bibliografia e apêndice. 1. Engenharia de Software. 2. Teste de Software. 3. Processo de Teste de Software I. Título. CDU - UPE CDU( : ) iii

4 Dedico este trabalho Aos meus pais, que sempre acreditaram em mim, fornecendo todo apoio necessário para que eu pudesse alcançar meus objetivos. Ao meu filho Gabriel que, com o seu sorriso, contagia a minha vida de alegria, coragem e força de vontade para crescer cada vez mais. Á Alberto, meu companheiro, amigo, cúmplice de todos os momentos bons ou ruins, sempre me apoiando e me confortando. Aos meus irmãos Day, Leu e Jó e familiares, pelo apoio e incentivo em todos os momentos. iv

5 Agradecimentos A minha orientadora, Cristine Gusmão, que aceitou o desafio de orientar uma aluna cansada, desmotivada e sem tempo para dedicar-se ao mestrado. Sem o seu apoio, eu jamais teria concluído esse trabalho. A todos os professores do DSC, pela preocupação contínua com o aprendizado e extrema dedicação a este programa de pós-graduação. A todos os colegas da primeira turma de mestrado, que, nos momentos difíceis, estiveram sempre ao meu lado, não me deixando fraquejar e nem desistir do mestrado. São eles: Naida, Lilian, Renata, César, Henrique, Marcelo, Mário, Alexandre, Petrônio, Diogo, Thyago, Danilo, Anthony, George e Bernardo. A Renata, Keldjan, Júlio e Ed, pela amizade, dedicação e contribuição com os seus trabalhos de iniciação científica e/ou conclusão de curso. Aos queridos voluntários, Emanoel, Hilda, Liliane, Raphael e Everton, que chegavam às 7h da manhã para participar do estudo de caso. À equipe MPhyScas, formada por César, Renata, Fernando, Danilo e Marcelo, pela disponibilidade para realização do estudo de caso. À Ana Georgina, secretária do DSC, pelo carinho e dedicação, sempre nos orientando e ajudando para que pudéssemos estudar com tranqüilidade. Ao amigo Breno Spindola, pelas valiosas contribuições, pelos conselhos e pela revisão deste e de outros trabalhos. Ao amigo Humberto Rocha, pela realização das simulações e revisão do modelo de processo. Aos colegas Simone, Tiago, Elvys, Fernando, Paulo e Virginia, do Projeto CIn Motorola, que me incentivaram a ingressar no mestrado e me forneceram todo o apoio necessário para iniciar este trabalho. Aos colegas Mônica Falcão, Nielso, Bruno Abreu e Márcia Falcão, do SERPRO, pelo incentivo para que eu pudesse dedicar-me ao mestrado. Aos colegas Tiago, Humberto, Adélia, Denílson, Rodrigo e Jarley, do SINPA, pela enorme ajuda e paciência, quando a minha mente já estava esgotada. À Ana Claudia, por cuidar de Gabriel sempre com muito zelo e carinho, deixando-me tranqüila para estudar. Aos demais amigos, que felizmente não são poucos, pelas contribuições, incentivo, conforto e compreensão pela a minha ausência nestes últimos dois anos. v

6 Resumo Neste trabalho, é apresentado o RBTProcess, um Modelo de Processo de Teste de Software baseado em Riscos, constituído de atividades da gerência de riscos e de processos de teste de software, papéis, guias, artefatos e um conjunto de métricas, fornecido com o propósito de medir e controlar os casos de teste e atividades do processo. O RBTProcess foi avaliado através de simulações de uso do processo e estudo de caso e é apoiado pela RBTTool, ferramenta de apoio ao Teste de Software baseado em Riscos, também apresentada neste trabalho. Teste baseado em risco ou Risk-based Testing (RBT) consiste em um conjunto de atividades que favorece a identificação de riscos associados aos requisitos do software. Uma vez identificados, os riscos são priorizados de acordo com a sua probabilidade de ocorrência e impacto e os casos de teste, por sua vez, são projetados com base nas estratégias para tratamento destes riscos. A motivação principal para este trabalho deve-se ao fato de que a atividade de Teste de Software requer esforço considerável, normalmente dentro de restrições de custo e prazo, e a abordagem RBT permite justamente priorizar esforços e alocar recursos para os requisitos do software que necessitam ser testados prioritariamente, otimizando o processo de teste. Entretanto, os engenheiros de teste, ainda encontram dificuldade em aplicar a abordagem na prática pela ausência de conhecimentos sólidos sobre as atividades da Gerência de Riscos de Software e, principalmente, pela ausência de ferramenta de apoio. A contribuição principal deste trabalho é demonstrar que a abordagem RBT, através do RBTProcess, permite concentrar os esforços de teste nos requisitos de software que possuem maior probabilidade de apresentar falhas. Outras contribuições são: (i) mostrar que os defeitos, com maior severidade, podem ser descobertos mais cedo, tendo em vista que os requisitos mais problemáticos serão testados prioritariamente; (ii) mostrar que a qualidade do produto final é melhorada, como conseqüência de uma atividade de testes bem planejada e, por fim, (iii) mostrar que as atividades da gerência de riscos de software, incluídas no processo de teste de software, não exigem muitos recursos e tempo para execução. Palavras-chave: Teste de Software baseado em Riscos, Modelo de Processo, Engenharia de Software, Gerência de Riscos de Software. vi

7 Abstract This work presents the RBTProcess, a Risk-based Software Testing Process Model that contains activities from risk management and software testing, roles, guidelines, artifacts and a set of metrics to measure and control risk-based test cases and activities. The RBTProcess was evaluated through simulations of process use and case study. It is supported by the RBTTool, a tool for Risk-based Software Testing, also presented in this work. Risk-based Testing (RBT) consists of a set of activities regarding risks identification related to software requirements. Once identified, the risks are prioritized according to their likelihood and impact and test cases are projected based on the strategies for treatment of the identified risks. The main motivation of this work is that testing process requires significant effort, besides costs and resources constraints and RBT allows prioritize limited efforts for the software components that need to be tested carefully, improving, in this way, the test activities. However, testers continually encounter difficulties in effectively applying risk-based in practice, because they normally do not have risk management knowledge and there is no software tool to support the approach. The main contribution of this work is to confirm that RBT, through RBTProcess, allows focusing on the software requirements that are more likely to failure. Other contributions are: (i) to demonstrate that defects with high severity are discovered earlier as a result of requirement prioritization; (ii) to show that the software product quality is improved as consequence of well planned test activities and (iii) to show that software risk management activities, included in the software test process, are not time and resource consuming. Keywords: Risk-based Software Testing, Process Model, Software Engineering, Software Risk Management. vii

8 Sumário Índice de Figuras Índice de Tabelas Tabela de Siglas e Símbolos SIGLAS SÍMBOLOS 1 Introdução Motivação Objetivos Objetivo Geral Objetivos Específicos Metodologia Organização da Dissertação 6 2 Riscos e Testes de Software: Conceitos Básicos, Modelos e Processos Teste de Software Conceitos Básicos Processo de Teste de Software segundo o Processo Unificado da Rational (RUP) Modelo de Maturidade de Teste de Software (TMM) Padrão IEEE para Verificação e Validação de Software Padrão IEEE para Documentação de Teste de Software Riscos na Engenharia de Software Conceitos Básicos Processo de Gerência de Riscos segundo o Guia PMBOK Processo de Gerência de Riscos segundo o Processo Unificado da Rational (RUP) Atividades da Área de Processo do Gerenciamento de Riscos do Modelo CMMI Atividades da Gerência de Riscos do Instituto de Engenharia de Software (SEI) Resumo do Capítulo 34 3 Teste de Software baseado em Riscos Atividades Principais Abordagens Abordagem baseada em Heurística Abordagem baseada em Métricas Abordagem baseada em Código-fonte Orientado a Objetos Abordagem para Teste de Regressão Abordagem baseada em Uso Abordagem baseada em Modelos Análise Comparativa Resumo do Capítulo 51 4 RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos Documentação do Modelo 52 xiii xv viii x xi xiii

9 4.2 Visão Geral Fases Papéis Disciplinas ou Conjuntos de Trabalho Identificar Riscos Analisar Riscos Planejar Testes Projetar Testes Executar Testes Avaliar Testes Controlar Riscos Relacionamento dos Artefatos Métricas Métricas para Controle e Medição de Casos de Teste baseado em Riscos Métricas para Controle e Medição das Atividades do Processo de Teste de Software baseado em Riscos Avaliação do Modelo de Processo Simulações Realizadas pela Autora Simulações Realizadas por Engenheiro de Teste com Experiência em Teste de Software Simulações Realizadas para Avaliar Métricas e Coletar Tempo de Atividades de Identificação e Análise de Riscos Estudo de Caso Resumo do Capítulo 90 5 RBTTool: Ferramenta de apoio ao Teste de Software baseado em Riscos Requisitos Material e Método Tecnologias Ambiente de Desenvolvimento e Frameworks Processos de Desenvolvimento e Gerência de Riscos Estágio Atual de Desenvolvimento Resumo do Capítulo 97 6 Conclusões Contribuições e Resultados Alcançados Limitações Encontradas Trabalhos Relacionados Trabalhos Futuros 101 Bibliografia 103 Pesquisa sobre a Abordagem de Teste baseado em Riscos 107 RBTTool: Telas 111 RBTProcess: Papéis 116 RBTProcess: Atividades 119 ix

10 Índice de Figuras Figura 2.1 Classificação para os termos erro, defeito e falha [Graham et al 2007]. 9 Figura 2.2 Estágios do teste de software. 10 Figura 2.3 Arquitetura geral do RUP (2003). 13 Figura 2.4 Atividades de teste do processo unificado da Rational [RUP 2003]. 14 Figura 2.5 Estrutura do TMM [Burnstein 1999]. 17 Figura 2.7 Relacionamento entre os artefatos e atividades de teste [IEEE ]. 24 Figura 2.8 Taxonomia de riscos proposta pelo SEI e adaptada por [Gusmão 2005]. 27 Figura 3.1 Atividades relevantes para RBT [Amland 1999]. 36 Figura 3.2 Esforço necessário para reduzir em 50% os riscos. 45 Figura 3.3 Amostra de um modelo de teste com informações de riscos. 47 Figura 4.1 Níveis de modelagem do SPEM. 53 Figura 4.2 Composição do Eclipse Process Framework [EPF 2007]. 54 Figura 4.3 Página do modelo de processo criada pelo EPFComposer [RBTProcess 2008]. 55 Figura 4.4 Fases do RBTProcess. 55 Figura 4.5 RBTProcess: Disciplina Identificar Riscos. 58 Figura 4.6 RBTProcess: Disciplina Analisar Riscos. 60 Figura 4.7 Métricas para cálculo de exposição ao risco dos requisitos. 60 Figura 4.8 RBTProcess: Disciplina Planejar Testes. 62 Figura 4.9 RBTProcess: Disciplina Projetar Testes. 64 Figura 4.10 Questionário baseado em taxonomia para a funcionalidade Group Tasks. 65 Figura 4.11 RBTProcess: Disciplina Executar Testes. 65 Figura 4.12 RBTProcess: Disciplina Avaliar Testes. 66 Figura 4.13 RBTProcess: Disciplina Controlar Riscos. 67 Figura 4.14 RBTProcess: Relacionamento dos artefatos. 69 Figura 4.16 Visão geral do fluxo de execução do estudo de caso. 80 Figura 5.1 Diagrama de caso de uso da RBTTool. 92 Figura 5.2 Componentes da Arquitetura RCP (2008). 95 x

11 Índice de Tabelas Tabela 1.1 Metodologia do Trabalho. 5 Tabela 2.1 Tipos de testes de software [RUP 2003]. 11 Tabela 2.2 Objetivos e atividades dos níveis do TMM. 19 Tabela 2.3 Conteúdo dos documentos de teste de software [IEEE ]. 23 Tabela 2.4 Matriz de impacto e probabilidade. 26 Tabela 2.5 Questões de estabilidade e completude para o elemento requisito. 28 Tabela 2.6 Objetivos e práticas da área de processo de gerenciamento de riscos. 31 Tabela 3.1 Etapas do teste baseado em riscos [Bach 1999]. 36 Tabela 3.2 Lista de categorias de critérios de qualidade [Bach 1999]. 37 Tabela 3.3 Lista genérica de riscos [Bach 1999]. 38 Tabela 3.4 Catálogo de riscos para um instalador [Bach 1999] 38 Tabela 3.5 Exposição ao risco calculado para a função fechar contas [Amland 1999]. 40 Tabela 3.6 Valores limites para métricas individuais. 42 Tabela 3.7 Métricas coletadas de um projeto Java. 43 Tabela 3.8 Possíveis casos de teste e risco associado. 47 Tabela 3.9 Análise comparativa das principais abordagens RBT. 50 Tabela 4.1 Estereótipos disponíveis no SPEM. 53 Tabela 4.2 Exemplo de indicadores para a métrica de qualidade da funcionalidade. 61 Tabela 4.3 Lista de priorização dos requisitos. 61 Tabela 4.4 Definição do escopo dos teste. 63 Tabela 4.5. Métrica para casos de teste baseado em riscos. 71 Tabela 4.6 Métricas para atividade de teste baseado em riscos. 72 Tabela 4.7 Métricas da atividade de identificação de riscos. 77 Tabela 4.8 Cálculo de exposição ao risco para o sistema Health-Watcher. 77 Tabela 4.9 Métricas da atividade de análise de riscos. 77 Tabela 4.10 Número de casos de teste por funcionalidade. 78 Tabela 4.11 Resultado da execução dos casos teste baseado em riscos. 78 xi

12 Tabela 4.12 Métricas da atividade de análise de riscos. 79 Tabela 4.13 Atividades de preparação para realização do estudo de caso. 83 Tabela 4.14 Atividades do RBTProcess. 83 Tabela 4.15 Tempo gasto na atividade de identificação de riscos. 85 Tabela 4.16 Características dos riscos identificados. 85 Tabela 4.17 Tempo gasto para análise dos riscos. 86 Tabela 4.18 Valores de exposição ao risco das funcionalidades do MPhyScaS. 86 Tabela 4.19 Número e severidade dos defeitos encontrados por abordagem. 88 Tabela 4.20 Concentração dos defeitos por caso de teste. 88 Tabela 4.21 Concentração dos defeitos por tempo de execução. 88 Tabela 4.22 Concentração dos defeitos por funcionalidade. 89 Tabela 5.1 Cronograma de atividades do ano de xii

13 Tabela de Siglas e Símbolos SIGLAS ADS Ambiente de Desenvolvimento de Software ARSP Additional Risk Score Prioritization CASE Computer-Aided Software Engineering CBO Coupling Between Objects CMM Capability Maturity Model CMMI Capability Maturity Model Integration DIT Depth in Tree DSC Departamento de Sistemas e Computação EPF Eclipse Process Framework FEM Finite Element Method GARA Processo Ágil de Gestão de Riscos GQM Goal Question Metric IDE Integrated Development Environment IEEE The institute of Electrical and Electronics Engineers IIT Illinois Institute of Technology ISO International Organization for Standardization ISTQB International Software Testing Qualifications Board JUDE Java and UML Developer Environment MPhyScaS Multi-Physics and Multi-Scales Solver Environment NASA National Aeronautics and Space Administration NOC Number of Children xiii

14 NOM Number of Methods OMG Object Management Group PMBOK Project Management Body of Knowledge PMI Project Management Institute OP Optimum Prioritization OpenUP Open Unified Process RBT Risk-based Testing RCP Rich Cliente Plataform RE Risk Exposure REM Requirement Management RFC The Response for a Class RiteDAP Risk-based test case Derivation And Prioritization RP Randomic Prioritization RUP Rational Unified Process SATC Software Assurance Technology Center SEI Software Engineering Institute SG Specific Goals SP Specific Practices SPEM Software Process Engineering Metamodel SQA Software Quality Assurance TBQ Taxonomy-Based Questionnaire TCMM Testing Capability Maturity Model TIM Test Improvement Model TMM Test Maturity Model TPI Test Process Improvement TOM Test Organization Maturity xiv

15 TRSP Total Risk Score Prioritization UFPE Universidade Federal de Pernambuco UMA Unified Method Architecture UML Unified Modeling Language UPE Universidade de Pernambuco V&V Verificação e Validação WMC The Weighted Methods per Class SÍMBOLOS C (v) Custo para Vendedor C (c) Custo para Cliente ER ( f ) Exposição ao Risco da Função f P ( f ) Probabilidade da Função f I ( f ) Impacto da Função f xv

16 Capítulo 1 Introdução As empresas, de forma geral, têm despertado para a importância da atividade de teste de software como forma de melhorar a qualidade dos seus produtos e manterem-se competitivas no mercado. Além disso, a complexidade das tecnologias utilizadas e dos produtos de software produzidos tem crescido, tornando-se indispensável a utilização de processos, métodos, técnicas e ferramentas que permitam a realização de teste de software de maneira sistemática e com fundamentação teórica, com o propósito de aumentar a qualidade do software, com o menor custo possível [Delamaro et al 2007]. Assim, o processo de testes exerce um importante papel dentro da garantia de qualidade de software ou Software Quality Assurance (SQA) assegurando que os requisitos satisfaçam as necessidades das partes envolvidas. Da mesma forma, a gerência de riscos de software tem sido fortemente debatida, estudada e utilizada em ambientes de desenvolvimento de software com o propósito de administrar oportunidades [Gusmão 2007], aumentando a probabilidade de atingir os objetivos do projeto, ou seja, entregar o produto de software com o menor custo, no menor tempo possível e com maior qualidade. O Teste baseado em Riscos ou Risk-based Testing (RBT), por sua vez, permite priorizar esforços e alocar recursos para os componentes de software que necessitam ser testados mais cuidadosamente a partir da identificação, análise e controle dos riscos associados aos requisitos, reduzindo o tempo e esforço necessários para testar um produto. O objetivo deste capítulo introdutório é apresentar a importância do tema abordado, as motivações, objetivos e os passos realizados para construção deste trabalho. 1

17 1.1 Motivação A atividade de teste de software tem se mostrado fundamental no desenvolvimento de software, buscando evitar, principalmente, que falhas cheguem aos clientes, deixando-os insatisfeitos e causando prejuízos. Esta atividade, no entanto, é difícil e custosa de ser realizada, uma vez que o domínio de entradas e saídas de um software é diverso, bem como são muitas as possibilidades de caminhos possíveis a serem testados. Além disso, segundo Kaner, a atividade de teste é bastante cara, chegando a custar até 45% do valor inicial de um produto em desenvolvimento [Kaner et al 1999]. Segundo estudos [Graham et al 2007], quanto mais tarde um erro é encontrado, maior é o custo para corrigi-lo que cresce de forma exponencial como mostrado na Figura 1.1. A mudança em um documento de requisito durante uma revisão ou inspeção de requitos tem baixo custo, entretanto, se realizada após a codificação do requisito, torna-se mais cara, uma vez que, além da atualização do documento, o código necessita ser reescrito. C U S T O custo para encontrar e corrigir defeitos aumenta ao longo do tempo Figura 1.1 Custo para encontrar e corrigir defeitos em um software. Outro problema relatado na literatura [Goldsmith 2006] é que, infelizmente, o processo de teste de software ainda é visto, por alguns, como um processo que tem início ao final do processo de desenvolvimento. Nestes casos, os problemas enfrentados em estágios anteriores têm sido resolvidos fazendo-se uso do tempo e dinheiro - normalmente bastante limitados - reservados para o teste, não sobrando recurso suficiente para se testar adequadamente o produto de software. Assim, o teste se torna bastante curto, e os sistemas produzidos tornam-se menos confiáveis. Além disso, a fase de testes também tem sido utilizada como buffer para compensar atrasos no projeto comprometendo, também, o tempo destinado aos testes e a qualidade do software [Goldsmith 2006]. TEMPO Requisitos Projeto Construção Teste Uso 2

18 Com relação aos riscos de software, é bastante comum projetos enfrentarem diversos problemas afetados por riscos inesperados, não planejados ou simplesmente ignorados. Desta forma, à medida que o tamanho e a complexidade dos sistemas crescem, aumenta a necessidade da utilização de metodologias para gerenciamento de riscos [Rios 2005]. A técnica de teste baseada em análise de riscos surgiu como uma abordagem para minimizar alguns dos problemas relacionados ao esforço da atividade de teste e da gerência de riscos. Assim, a atividade de testes é melhorada a partir da gerência dos riscos técnicos de software que podem ser tratados através da realização de atividades de teste de software. Apesar da abordagem RBT mostrar-se simples, os engenheiros de teste ainda encontram dificuldades em aplicá-la na prática [Goldsmith 2006], principalmente, porque a análise de riscos é algo complexo e necessita de conhecimento para sua aplicação [SEI 2006]. Também, não foram encontrados processos com atividades, papéis e artefatos bem definidos que possam guiar os engenheiros de testes no uso da abordagem e ferramentas específicas, o que, provavelmente, dificulta sua aplicação e disseminação. Visando diminuir esta dificuldade de utilização da abordagem RBT, este trabalho apresenta um Modelo de Processo de Teste de Software baseado em Riscos com guias, artefatos, atividades, papéis, métricas e apoiado por protótipo que forneça apoio às principais atividades da abordagem. 1.2 Objetivos Objetivo Geral O objetivo geral deste trabalho é definir um Modelo de Processo de Teste de Software baseado em Riscos, formado por atividades presentes nos processos de gerência de riscos e de testes de software, bem como, métodos e técnicas presentes nas abordagens de teste baseado em riscos disponíveis na literatura, com o propósito de facilitar e disseminar o uso da abordagem RBT Objetivos Específicos O conjunto de objetivos específicos necessários para a realização do objetivo geral é: Pesquisar abordagens, métodos, processos e ferramentas de teste baseado em riscos, identificando atividades em comum, formas de utilização, pontos fortes e fracos, elaborando um estudo comparativo. 3

19 Pesquisar conceitos básicos e processos para gerência de riscos e testes de software, identificando atividades que podem ser utilizadas na definição do modelo de processo. Propor um modelo de processo que integre atividades de gerência de riscos e testes de software, levando em consideração as técnicas e métodos de teste baseado em riscos identificados na literatura. Construir uma ferramenta que apóie a utilização da abordagem RBT através da implementação de funcionalidades que atendam às principais atividades da abordagem. Avaliar o modelo através de simulações e estudos de caso. Divulgar a abordagem RBT, modelo de processo e protótipo, através da escrita de artigos científicos. Propor novas linhas de pesquisas como forma de continuação deste trabalho. 1.3 Metodologia Para a obtenção dos objetivos definidos na Seção anterior, um conjunto de etapas foi definido contendo atividades e metodologia utilizada. A pesquisa pode ser divida em quatro fases distintas e contínuas como apresentado na Tabela 1.1. A primeira fase teve uma característica exploratória e possibilitou elencar os requisitos necessários para construção do modelo e do protótipo. A segunda fase constituiu na definição e construção do modelo de processo em si, através da compilação do material identificado na fase anterior. Na terceira fase, o foco foi na construção do protótipo de apoio à abordagem RBT, independente de processo, pois a finalidade era a avaliação dos requisitos do modelo de processo. Na quarta fase, o modelo de processo e o protótipo foram avaliados. No decorrer desta fase, mais precisamente após as simulações do modelo de processo, o modelo e dados coletados resultaram nas seguintes publicações: 1. SOUZA, E.; GUSMÃO C.; RBTProcess - Modelo de Processo de Teste de Software baseado em Riscos. In: 13º WTES - Workshop de Teses e Dissertações em Engenharia de Software, SOUZA, E.; GUSMÃO C.; ROCHA, H. RBTProcess - Proposta de Modelo de Processo de Teste de Software baseado em Riscos. In: III EBTS Encontro Brasileiro de Teste de Software,

20 Fase 1 Tabela 1.1 Metodologia do Trabalho. FASES ATIVIDADES METODOLOGIA Estudo sobre o tema abordado Fase 2 Definição do RBTProcess Fase 3 Construção da RBTTool Fase 4 Avaliação do RBTProcess Estudo inicial sobre testes, riscos de software e teste baseado em riscos; Levantamento das formas de utilização e dificuldades da abordagem RBT. Estudo aprofundado sobre testes, riscos de software e teste baseado em riscos; Definição do modelo de processo contendo as principais atividades da abordagem. Levantamento dos requisitos necessários para utilização da abordagem RBT; Implementação das funcionalidades identificadas. Instanciação do modelo de processo e definição do plano de aplicação do modelo de processo; Simulação do modelo de processo; Aplicação do modelo de processo; Coleta e avaliação dos resultados; Refinamento do modelo de processo. Divulgação da abordagem, modelo de processo Revisão bibliográfica; Aplicação de questionário. Identificação das principais atividades, elaboração de estudo comparativo as abordagens RBT; Seleção das principais atividades encontradas nos principais processos de gerência de riscos e testes de software. Revisão das principais abordagens RBT identificando atividades em comum; Definição de ambiente de desenvolvimento, processo e tecnologias utilizadas para construção da ferramenta. Entrevista com os participantes do estudo de caso, estudo da documentação do software; Execução das atividades do processo utilizando documentos de projetos de desenvolvimento de software; Definição dos papéis e realização das atividades definidas no modelo de processo em um projeto de desenvolvimento de software; Coleta do resultado dos testes e aplicação de questionário com os integrantes da equipe de desenvolvimento e com o cliente do software; Coleta do tempo de realização das atividades, grau de dificuldade e oportunidades de melhorias através da realização de questionário e avaliação dos resultados. Publicação de artigos em eventos nacionais e internacionais. Escrita e defesa da dissertação. 5

21 1.4 Organização da Dissertação Após este capítulo introdutório, este trabalho é apresentado como segue: Capítulo 2 - Riscos e Testes de Software: Conceitos Básicos, Modelos e Processos: apresenta os conceitos básicos da área de teste e de riscos de software, processos e modelos estudados e utilizados como base para definição do RBTProcess. O objetivo deste capítulo é listar a terminologia e as principais atividades da gerência de riscos e do processo de teste de software. Capítulo 3 - Teste de Software baseado em Riscos: apresenta a revisão bibliográfica sobre a abordagem de teste baseado em riscos, histórico, principais atividades e análise comparativa. O objetivo deste capítulo é apresentar as diferentes abordagens, destacando seus pontos fortes e identificando oportunidades de melhorias, que foram aproveitadas para definição do RBTProcess. Capítulo 4 - RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos: apresenta o RBTProcess, descrevendo como o mesmo foi construído, modelado e documentado, suas fases, papéis, atividades e artefatos. Também são apresentadas métricas para acompanhamento do progresso das atividades RBT e resultado das avaliações do modelo. Capítulo 5 - RBTTool: Ferramenta de apoio ao Teste de Software baseado em Riscos: apresenta os requisitos necessários para construção de ferramenta de apoio à abordagem RBT, tecnologias utilizadas, processos e ambiente de desenvolvimento, estágio atual de desenvolvimento e avaliação da ferramenta. Capítulo 6 - Conclusões: contém as conclusões, contribuições, limitações encontradas e propostas de continuação deste trabalho. Apêndice A: apresenta o questionário utilizado na pesquisa sobre conhecimento e formas de utilização da abordagem RBT, bem como os resultados coletados. Apêndice B: apresenta as telas da RBTTool através de um exemplo de utilização da ferramenta. Apêndice C: apresenta os papéis do RBTProcess documentados na página do processo. processo. Apêndice D: apresenta as atividades do RBTProcess documentadas na página do 6

22 Capítulo 2 Riscos e Testes de Software: Conceitos Básicos, Modelos e Processos Processos de teste têm se mostrado fundamentais na garantia da qualidade dos produtos de software, buscando evitar, principalmente, que falhas cheguem até os clientes, deixando-os insatisfeitos e causando prejuízos. A gerência de riscos de software, por sua vez, é essencial para o aumento contínuo da qualidade e produtividade exigido pelo mercado, cada vez mais competitivo [Gusmão 2007]. Este capítulo tem como objetivos destacar a importância das atividades de teste Seção 2.1 e riscos na Engenharia de Software Seção 2.2, apresentar conceitos chave, processos, abordagens e modelos que serviram como base para construção do Modelo de Processo proposto neste trabalho. 2.1 Teste de Software De acordo com Myers [Meyers 1979], teste é o processo de executar um programa com o intuito de encontrar defeitos. No entanto, atividades do processo de teste de software podem ser realizadas já nas fases iniciais do desenvolvimento, antes mesmo da codificação, através do planejamento e projeto de casos de teste, por exemplo. Uma definição mais completa é fornecida por Sommerville (2003), segundo o qual, as atividades de verificação e validação (V&V) destinam-se a mostrar, respectivamente, que um produto de software está de acordo com suas especificações e que ele atende às expectativas 7

23 de todas as partes envolvidas no sistema. Dentro do processo de V&V, encontra-se o teste de software, uma técnica dinâmica, que envolve executar uma implementação de software com os dados de teste e examinar suas saídas e comportamento operacional, a fim de verificar se ele está funcionando conforme o esperado. Segundo o International Software Testing Qualifications Board (ISTQB) [Graham et al 2007] a palavra qualidade é definida como o grau até o qual um componente, sistema ou processo atende aos requisitos especificados e às necessidades e expectativas dos usuários. A qualidade de um produto de software está fortemente relacionada à satisfação do cliente, e o teste de software é uma das formas de validar se o produto desenvolvido atende às necessidades de seus usuários [Kaner et al 1999]. A execução de casos de teste é utilizada, também, para avaliar, de forma quantitativa, a qualidade de um produto de software. Através dos relatórios de resultado da execução dos casos de testes e rastreamento de requisitos funcionais e não funcionais, é possível obter percentuais de testes que estão passando, falhando ou que não puderam ser executados para um conjunto de requisitos, em uma determinada versão, como forma de mensurar a cobertura dos testes. O resultado da execução dos testes pode representar confiança na qualidade do software caso sejam encontrados poucos ou nenhum defeito. Um teste projetado adequadamente e cuja execução não encontre defeitos reduz o nível de riscos em um produto de software. Por outro lado, quando os testes encontram defeitos, a qualidade do sistema aumenta quando estes são corrigidos. É importante destacar que testes mal projetados, ou executados de forma incorreta, podem encontrar poucos defeitos, deixando uma falsa impressão de qualidade [Graham et al 2007] Conceitos Básicos Antes de apresentar os principais conceitos de testes, vale ressaltar a diferença entre os termos erro, defeito e falha, normalmente utilizados com o mesmo significado. O erro consiste em uma ação, geralmente humana, que pode produzir um defeito no código ou em qualquer outro artefato do software. Se um defeito é executado em um código, por exemplo, o software pode vir a apresentar falha. A Figura 2.1 apresenta uma classificação para esses termos. Abaixo, segue definição extraída do glossário do ISTQB [Graham et al 2007]. 8

24 Erro (engano): Uma ação humana ou do sistema que produz um resultado incorreto. Estas ações podem surgir por falta de experiência, informação, entendimento ou até mesmo por falta de atenção. Defeito (bug ou falta): Brecha em um componente ou sistema que pode fazer com que este falhe ao desempenhar sua função. Por erro ou engano, podemos inicializar vaiáveis de informar incorreta, acessar valores inexistentes em estruturas de dados, realizar conversões entre tipos de dados incompatíveis, dentre outras, introduzindo assim, defeitos no código-fonte. Pensando na etapa de elicitação de requisitos, os defeitos são funcionalidades especificadas de forma incorreta ou incompleta, por exemplo. Falha: Desvio, em um componente ou sistema, do seu resultado ou serviço esperado. A falha ocorre justamente quando a parte do sistema defeituoso é executada. Caso o código defeituoso não seja executado, o sistema pode nunca falhar e o defeito jamais ser descoberto. Com relação aos requisitos de software, funcionalidades especificadas de forma incorreta ou incompleta resultam em resultado diferente do esperado pelo cliente e/ou usuário. Figura 2.1 Classificação para os termos erro, defeito e falha [Graham et al 2007]. Abordagens Para criação ou projeto dos casos de teste, duas principais abordagens podem ser utilizadas: Funcional ou caixa preta : os casos de testes são criados a partir de uma análise dos relacionamentos entre os dados de entrada e saída, com base nos requisitos levantados com os usuários. Essa abordagem é aplicada durante as últimas etapas do processo de teste de software. Estrutural ou caixa branca : os testes são criados a partir de uma análise dos caminhos lógicos possíveis de serem executados, de modo que é necessário o conhecimento do funcionamento interno dos componentes do software. É aplicado durante a codificação do software. 9

25 Estágios Os estágios definem o momento do ciclo de vida do software em que os testes são realizados. Em cada estágio do processo de software, desde o levantamento dos requisitos até o desenvolvimento do programa, testes estáticos ou dinâmicos podem ser realizados. A Figura 2.2 apresenta os principais níveis ou estágios do teste de software. Módulo Subsistema Teste de Unidade Teste de Integração Sistema Teste de Sistema Teste de Aceitação Figura 2.2 Estágios do teste de software. Teste de Unidade: componentes individuais (ex: métodos e classes) são testados. Tem por objetivo testar a estrutura interna e comportamento do módulo e é geralmente realizado pelo desenvolvedor durante a implementação do software. Teste de Integração: as unidades testadas independentemente agora são testadas de forma integrada. É recomendada a integração das unidades de forma incremental e este teste é realizado geralmente por um desenvolvedor. Teste de Sistema: o software integrado com o ambiente operacional, similar ao de produção, é testado. Geralmente, é um teste caixa preta, executado por um testador de sistemas após a liberação de um executável do software. É recomendado que o testador seja membro de um grupo independente de testes. Teste de Aceitação: o software é testado pelo usuário final. É realizado um teste caixa preta a fim de demonstrar a conformidade com os requisitos de software. Tipos de Testes Diferentes tipos de testes são projetados e executados com o intuito de avaliar um objetivo específico. Na Tabela 2.1, é apresentada uma lista dos principais tipos de testes extraída do Processo Unificado da Rational [RUP 2003]. A dimensão de qualidade que aparece na primeira coluna da tabela representa as categorias de qualidade presentes no modelo FURPS 1 e detalhadas a seguir: 1 FURPS é um modelo de referência criado por Robert Grady na Hewlett Packard, que define as cinco principais dimensões de qualidade para um software: Functionality, Usability, Reliability, Performance e Supportability 10

26 Funcionalidade: possibilita verificar se a aplicação está em conformidade com os seus requisitos. Usabilidade: testa a aplicação da perspectiva da conveniência do usuário final. Confiabilidade: verifica se a aplicação se comporta de maneira consistente e previsível. Performance: verifica o comportamento da aplicação numa condição de carga. Suportabilidade: testa a habilidade da aplicação suportar várias plataformas, DIMENSÃO DE QUALIDADE Funcionalidade Usabilidade Confiabilidade Performance Suportabilidade Atividades configurações e ambientes diferentes. Tabela 2.1 Tipos de testes de software [RUP 2003]. TIPO DE TESTE funcionais: têm por objetivo testar as funcionalidades do sistema em termos de regras de negócio. segurança: verifica se os mecanismos de proteção de acesso estão funcionando satisfatoriamente. volume: submete grandes quantidades de dados ao sistema para determinar se limites que causam a falha do software são alcançados. usabilidade: verifica aparência e comportamento da interface, navegação, consistência, aderência a padrões, tempo para aprender como usar uma funcionalidade integridade: testa a corretude dos métodos de acesso à base de dados e as informações armazenadas. estresse: verifica o funcionamento do sistema em situações limite ou fora da tolerância esperada. desempenho: verifica o tempo de resposta e processamento (para diferentes configurações, diferentes cargas de trabalho, número de usuários, tamanho da base de dados, etc.) configuração: verifica o funcionamento adequado do sistema em diferentes configurações de hardware/software. instalação/desinstalação: verifica a correta instalação e desinstalação do sistema para diferentes plataformas de hardware/software e opções de instalação. O processo de teste de software define como os testes serão planejados, projetados, implementados, executados e avaliados através de um conjunto de atividades, artefatos e papéis. A seguir são apresentadas as principais atividades de um processo de testes extraídas de [Graham et al 2007] e descritas seqüencialmente. Planejar e Controlar: durante esta etapa, os objetivos dos clientes, satekholders e projetos devem ser totalmente entendidos e os riscos relacionados às atividades de teste devem ser endereçados, com o propósito de estabelecer metas e objetivos para o teste de software. O planejamento determina e acompanha, de forma geral, escopo e objetivos dos testes, a abordagem utilizada para construção dos casos de teste, os recursos físicos e humanos, cronograma de planejamento, projeto, execução e acompanhamento dos testes, além de definir os critérios de saída e a cobertura dos testes, ou seja, o momento em que a atividade de teste será 11

27 finalizada. O resultado das atividades de teste é continuamente monitorado através de métricas para acompanhamento do progresso, critério de saída e cobertura dos testes. Análise e projeto: nesta atividade, objetivos gerais de teste são transformados em cenários e condições de testes tangíveis. Para isto, são revisados as análises de riscos, requisitos funcionais e não funcionais, arquiteturas, modelos de análise e projeto e interface do software. Implementação e execução: os cenários de testes são transformados em casos e procedimentos de teste utilizando a abordagem e estratégias definidas durante o planejamento e validadas durante a análise. O ambiente é criado, incluindo os dados para execução dos testes, bem como os casos de teste implementados. Suítes de teste são criadas para execução, através da priorização dos requisitos do software. Os casos de teste são finalmente executados e um log de teste é gerado como resultado. No caso em que defeitos são encontrados no software ou mesmo nos casos de teste, solicitações de mudança são abertas e designadas para os responsáveis para que, posteriormente, esses defeitos sejam corrigidos e retestados. Avaliação do critério de saída e resultado: a execução dos testes é avaliada de acordo com o que foi definido na atividade de planejamento. Relatórios de acompanhamento para os diversos stakeholders são criados através de análise do resultado dos logs de teste e do status das solicitações de mudança. Além disso, é verificado o critério de saída, que determina quando uma dada atividade de teste é concluída. Atividades de encerramento dos testes: nesta etapa, dados são coletados com o intuito de consolidar experiência, isto inclui: analisar ambiente, dados de teste, fatos, números e procedimentos de testes Processo de Teste de Software segundo o Processo Unificado da Rational (RUP) O RUP [RUP 2003] é um processo da Engenharia de Software que oferece as melhores práticas relacionadas ao desenvolvimento de produtos de software através da definição de atividades, responsabilidade, artefatos boas práticas e diretrizes. O RUP foi criado pela Rational Software Corporation, que hoje pertence a IBM, e está organizado em duas dimensões como mostra a Figura 2.3. A dimensão dinâmica representa o 12

28 tempo e é expressa em termos de fases, iterações e marcos. A dimensão estática representa os componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo. O RUP é considerado um processo pesado e preferencialmente aplicável a grandes equipes de projetos de desenvolvimento, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala [RUP 2008]. Para a disciplina de teste de software, o RUP provê conceitos básicos, fluxo de trabalho, atividades, artefatos e diretrizes, além de um conjunto de ferramentas. Figura 2.3 Arquitetura geral do RUP (2003). Na dimensão estática, encontram-se as disciplinas ou fluxos do processo. O fluxo de requisitos produz o primeiro subsídio para a identificação dos testes de sistemas que serão executados. O fluxo de análise e projeto descreve como desenvolver um projeto que é entrada para a definição dos testes de integração da arquitetura. No fluxo de planejamento e gerenciamento, os testes são planejados para cada iteração. Finalmente, o código produzido no fluxo de implementação é testado no fluxo de teste. Com relação à dimensão dinâmica, o processo de desenvolvimento do RUP é dividido quatro fases, onde cada fase possui uma ou mais iterações, bem como seus marcos. A seguir, são apresentados os objetivos do fluxo ou disciplina de teste de software para cada uma das fases do processo. Concepção: o foco é no planejamento inicial dos testes durante o planejamento do projeto. Elaboração: foco principal é o projeto e execução de testes de integração, de forma a validar e estabelecer uma arquitetura estável para o sistema. 13

29 Construção: o foco principal das atividades de teste é o projeto e execução de testes de sistema para os requisitos implementados. Transição: o foco dos testes muda para a homologação e avaliação da correção das mudanças efetuadas devido a defeitos encontrados. A Figura 2.4 apresenta os papéis, atividades e artefatos definidos para a atividade de teste do processo unificado da Rational explicadas a seguir. Figura 2.4 Atividades de teste do processo unificado da Rational [RUP 2003]. Gerente de Testes É responsável pelo planejamento e gerenciamento de recursos e resolução de problemas que representam um obstáculo para o esforço de teste. Estão sob sua responsabilidade as atividades: Combinar Missão: negociar a forma mais eficaz de usar os recursos de teste para cada iteração. Acordar sobre os objetivos e os produtos a serem liberados na iteração através da compreensão inicial do escopo, objetivo e expectativa dos envolvidos. Identificar Motivadores de Teste: identificar a lista específica de itens, incluindo eventos e artefatos, que servirão para motivar o teste na iteração. 14

30 Obter Confirmação de Testabilidade: promover a criação de um software testável que apoie as necessidades do esforço de teste, através do entendimento das necessidades de implementação e avaliação do teste. Promover e apoiar o uso de técnicas e ferramentas apropriadas de automação. Avaliar e Defender Qualidade: identificar e assegurar a resolução dos defeitos que exercem um impacto prejudicial grave sobre a qualidade do software. Monitorar e apoiar mudanças que forneçam qualidade para o software. Avaliar e Aprimorar Esforço de Teste: avaliar a produtividade, a eficácia e a abrangência do esforço de teste, realizando ajustes quando necessário para alcanças os objetivos. Analista de Teste É responsável por identificar e definir os testes necessários, monitorar a abrangência dos testes e avaliar a qualidade geral obtida ao testar o produto de software. Estão sob sua responsabilidade as atividades: Identificar Objetivos do Teste: identificar os elementos de sistema individuais, tanto de hardware quanto de software, que precisem ser testados. Criar uma lista com estes itens de teste para estimativa de esforço e construção do plano de teste. Identificar Idéias de Teste: identificar as idéias de teste que devem ser exploradas para avaliar a qualidade aceitável do produto de software, através da realização de um brainstorm de idéias. Definir Detalhes do Teste: definir as condições individuais necessárias para realizar uma idéia de teste em um contexto específico. Definir Necessidades de Avaliação e Rastreabilidade: definir a estratégia de avaliação para o esforço de teste, bem como os requisitos de rastreabilidade e cobertura dos testes. Determinar Resultados do Teste: fazer avaliações resumidas contínuas da qualidade do produto, com o propósito de fornecer resultados e propor ações corretivas apropriadas para resolver falhas identificadas durante os testes. Verificar Mudanças no Build: confirmar a conclusão de uma solicitação de mudança, normalmente, realizando um subconjunto de testes em uma ou mais versões. 15

31 Designer ou Projetista de Teste É responsável por definir a abordagem de teste e assegurar sua correta implementação. Envolve identificar as técnicas, ferramentas e diretrizes apropriadas para implementar os testes necessários. Estão sob sua responsabilidade as seguintes atividades: Definir Abordagem do Teste: identificar cada técnica específica a ser empregada para realização do teste desejado. Definir Configurações do Ambiente de Teste: definir os requisitos dos ambientes de avaliação necessários para apoiar o esforço de teste. Identificar Mecanismos de Testabilidade: identificar os possíveis mecanismos de teste necessários para a abordagem de teste selecionada. Estruturar a Implementação de Testes: atribuir responsabilidades às áreas de implementação do conjunto de testes e seus conteúdos, além de descrever os conjuntos de testes a serem impementados. Definir Elementos de Testabilidade: identificar os elementos físicos da infraestrutura de implementação de teste necessária para permitir testes em cada configuração de ambiente de teste. Desenvolver Guia de Teste: efetuar ajustes na maneira como o processo é desempenhado e registrar essas decisões, com o propósito de desenvolver o conhecimento sobre os pontos fortes e fracos do processo de teste. O Testador É responsável pelas atividades centrais do esforço de teste, que envolve conduzir os testes necessários e registrar os resultados. O detalhamento das atividades é apresentado a seguir: Implementar Testes: implementar testes significativos que forneçam a validação necessária do produto. Implementar Conjunto de Testes: organizar ou montar coleções de testes para serem executados juntos de uma maneira significativa. Executar Conjunto de Testes: executar os conjuntos de testes apropriados necessários para validar a qualidade do produto. Analisar Falha de Teste: investigar os resultados dos testes, analisar as falhas que ocorreram durante a implementação e execução do teste e registrar solicitações de mudança. 16

32 2.1.3 Modelo de Maturidade de Teste de Software (TMM) Os modelos de maturidade são utilizados para avaliar e melhorar a qualidade dos processos em uma organização [Vasconcelos 2007]. Modelos como o Capability Maturity Model Integration (CMMI) abrangem todas as fases do desenvolvimento de software, e o teste de software aparece como uma destas fases. No entanto existem também modelos específicos para melhoria de processo de teste de software que foram criados com a finalidade de cobrir deficiências nas atividades de teste dos modelos genéricos [Reffson et al 2006]. O Test Maturity Model (TMM) é um modelo voltado para teste de software que avalia atividades e métodos, além de definir papéis, responsabilidades e boas práticas. Foi criado em 1996, pelo Illinois Institute of Technology (IIT). É o modelo de maturidade de teste de software mais conhecido e é inspirado em outro modelo também bastante conhecido, como o CMMI [Vasconcelos 2007]. O TMM é um modelo de validação baseado em um questionário, no qual é verificado o nível de maturidade da área de TI em relação ao teste. A partir do TMM, foram desenvolvidos outros modelos de melhoria do Processo de teste como o Testing Capability Maturity Model (TCMM), o Test Improvement Model (TIM), o Test Process Improvement (TPI) e o Test Organization Maturity (TOM) [Reffson et al 2006]. O TMM possui cinco níveis de maturidade com objetivos, áreas de processo e boas práticas. A Figura 2.5 mostra a arquitetura do TMM, onde cada nível é composto por um conjunto de objetivos que indicam o nível de maturidade do processo de teste. Figura 2.5 Estrutura do TMM [Burnstein 1999]. 17

33 Nível 1 Inicial Neste nível, o processo é caótico e não há distinção entre as atividades de teste e depuração. Os testes são realizados de forma ad hoc após a codificação do sistema. Normalmente não há qualquer treinamento e o objetivo do teste é mostrar que o sistema e o software funcionam. Nível 2 Gerenciado As funções do teste e da depuração são claramente definidas. O teste é visto como uma fase seguindo a codificação. Os processos são padronizados, contendo técnicas e métodos de testes. O objetivo do teste, neste nível, é mostrar que o software atende às especificações. Nível 3 Definido O teste está integrado no ciclo de vida do produto de software. A atividade de teste é estabelecida formalmente na organização com treinamento, controle e monitoramento do processo de teste. O objetivo do teste é mostrar que o software não funciona, tomando como base os requisitos. Nível 4 Quantitativamente Gerenciado A atividade de teste é um processo medido e quantificado. Os produtos de software são testados para atributos de qualidade como usabilidade, manutenibilidade, confiabilidade e outros. Casos de teste são coletados e registrados em uma base de dados para reuso em testes de regressão. Os defeitos são registrados com nível de severidade atribuídos para correção de acordo com a prioridade. Nível 5 Em Otimização A atividade de teste é institucionalizada. O processo de teste é bem definido e gerenciado. O custo e a eficiência dos testes são monitorados. Ferramentas para automação fazem parte do processo de teste e existem procedimentos estabelecidos para seleção e avaliação de ferramentas de teste. A Tabela 2.2 apresenta os objetivos e principais subobjetivos para cada nível do TMM extraídos de [Reffson et al 2006, Sartori 2005 e Veenendaal 2006]. 18

34 Tabela 2.2 Objetivos e atividades dos níveis do TMM. NÍVEL OBJETIVOS / SUBOBJETIVOS 1 O teste é realizado de forma ad hoc, normalmente, pela própria equipe de desenvolvimento Desenvolver metas e políticas de teste e depuração: Equipe de teste deve desenvolver e registrar objetivos do teste; Objetivos do teste devem ser refletidos nos planos de teste. 2. Iniciar um processo de planejamento de testes: Gerência deve definir políticas de planejamento de teste; Definição de template do Plano de Teste aprovado pela gerência contendo cronograma de atividades, alocação de recursos, critérios de aceitação para todos os níveis de teste; 3. Institucionalizar técnicas e métodos básicos de teste: Definição de abordagens e estratégias de testes adotadas pela equipe. Ex. abordagem funcional, estrutural, níveis e tipos de testes Estabelecer uma organização de teste de software: Estabelecer um grupo de teste amplo, da organização, com liderança, suporte, e financiamento da gerência superior. 2. Integrar o teste no ciclo de vida do software: A fase de teste dever ser dividida e organizada para integrar-se ao ciclo de vida do software. 3. Controlar e monitorar o processo de teste: Definição e utilização de conjunto de métricas para acompanhamento do processo de teste. 4. Estabelecer um programa de treinamento: Definir um plano de treinamento; Estabelecer um grupo de treinamento com ferramentas, facilidades e materiais Estabelecer um programa amplo de revisão: Os grupos de teste e da garantia de qualidade do software devem desenvolver e documentar objetivos, procedimentos de continuação e mecanismos de gravação para revisões. 2. Estabelecer um programa de medições de teste: Desenvolver plano de medição do teste com mecanismos para levantamento, análise, e aplicação dos dados; Documentar planos de ação que aplicam resultados de medições às melhorias do Processo de Teste. 3. Avaliação da qualidade de software: A gerência superior e os grupos da garantia da qualidade do teste de software devem definir políticas, objetivos da qualidade, e atributos de qualidade para produtos de software Prevenção de defeitos: Dever ser definida uma equipe para prevenção de defeitos com suporte da gerência; 2. Controle de qualidade: Os grupos do teste e de garantia da qualidade devem estabelecer objetivos para produtos de qualidade; Os gerentes de teste devem incorporar estes objetivos da qualidade em planos de teste. 3. Otimização do processo de teste: A organização deve desenvolver, documentar e apoiar procedimentos e políticas para otimização do Processo de Teste; Padrão IEEE para Verificação e Validação de Software A verificação e validação (V&V) de software é uma disciplina da Engenharia de Software que tem como propósito determinar se o produto desenvolvido em uma dada atividade está em conformidade com os requisitos definidos para a mesma e, principalmente, se o software construído satisfaz suas intenções de uso e as necessidades dos usuários. 19

35 O padrão IEEE define o processo de verificação e validação de software em termos de atividades específicas e tarefas relacionadas. Este padrão é uma revisão do padrão IEEE e introduz conceitos chave como níveis de integridade de software, atividade mínima de V&V para cada nível, intensidade, rigor e critérios para as atividades de V&V. Tem como propósito, estabelecer uma estrutura comum para processos, atividades e tarefas de V&V, além de definir o conteúdo do plano de V&V de software. Este padrão aplica-se a produtos de software que estão em desenvolvimento ou sofrendo manutenções corretivas ou evolutivas. São definidas atividades de V&V não somente para o processo de desenvolvimento, mas também para processos de gerenciamento, aquisição, fornecimento, operação e manutenção. A Figura 2.6 apresenta a estrutura do processo do padrão IEEE , em que são definidas atividades para cada processo e um conjunto mínimo de tarefas de V&V para cada atividade. Para este trabalho, foram estudadas as tarefas de V&V presentes nas atividades do processo de desenvolvimento do software como gerenciamento, concepção, análise de requisitos, projeto, codificação, integração, teste e outras. Framework Processo V&V IEEE Std Processo de Verificação e Validação (V&V) Aquisição V&V Fornecimento V&V Desenvolvimento V&V Operação V&V Manutenção V&V Atividades V&V Atividades V&V V&V Atividades V&V V&V Atividades V&V V&V Atividades V&V V&V Atividades V&V V&V Tarefas V&V Atividades Tarefas V&V V&V Atividades Tarefas V&V V&V Atividades Tarefas V&V V&V Atividades Tarefas V&V V&V Atividades Tarefas V&V V&V Figura 2.6 Estrutura do processo de V&V [IEEE ]. Atividade de Gerenciamento de V&V Esta atividade é realizada durante todo o ciclo de desenvolvimento. Tem como objetivo acompanhar, revisar e controlar continuamente o cronograma do projeto, as tarefas e os recursos de acordo com o plano de teste. Algumas tarefas de V&V para esta atividade são: criação do plano de verificação e validação, gerenciamento das revisões de V&V e avaliação de mudanças na baseline. 20

36 Atividade de Concepção de V&V Esta atividade representa a separação entre o problema que o usuário deseja resolver e a implementação para solucionar este problema. Tem como objetivo verificar os requisitos do sistema, validando a solução selecionada para resolver o problema do usuário. As tarefas mínimas de V&V para esta atividade são: avaliação do documento de concepção; análise de criticidade e rastreabilidade; análise de problemas e riscos. Atividade de Requisito V&V A atividade de requisito define os requisitos funcionais e não funcionais do software. O objetivo desta atividade é garantir a corretude, a completude, a exatidão, a testabilidade e a consistência dos requisitos. Algumas tarefas de V&V para esta atividade são: análise de rastreabilidade, interfaces e criticidade; avaliação dos requisitos do software; criação e verificação do plano de V&V de sistema; criação e verificação do plano de V&V de aceitação. Atividade de Projeto V&V Nesta atividade, os requisitos do software são transformados em arquitetura e projetos detalhados de componentes. O projeto inclui banco de dados, bem como definição de interfaces de comunicação. O objetivo desta atividade é demonstrar que o projeto é uma transformação correta, precisa e completa dos requisitos do software. Para isto, as seguintes atividades de V&V precisam ser realizadas: avaliação do projeto de software; criação e verificação do plano de V&V de componente; criação e verificação do plano de V&V de integração; criação e verificação do projeto de teste de V&V. Atividade de Implementação V&V A implementação transforma o projeto dos requisitos em código, estrutura de banco de dados e executáveis. O objetivo desta atividade é verificar e validar se as transformações para código ocorrem de forma correta, precisa e completa. As tarefas de V&V realizadas nesta atividade são: avaliação do código fonte e de sua documentação; criação e verificação de casos de teste de V&V; criação e verificação de procedimentos de teste de V&V; verificação e execução de testes de componente de V&V. 21

37 Atividade de Teste V&V O objetivo desta atividade é garantir que o software construído atenda às especificações dos requisitos através da execução de testes de integração, sistemas e aceitação. Tarefas de V&V para esta atividade são: criação e verificação de procedimentos de teste de V&V; execução e verificação de testes de integração de V&V; execução e verificação de testes de sistema de V&V; execução e verificação de testes de aceitação de V&V. Atividade de Instalação V&V O objetivo desta atividade é assegurar a correta instalação e configuração do software no ambiente alvo. Tarefas de V&V para esta atividade são: auditoria de configuração e instalação; geração de relatório final de V&V Padrão IEEE para Documentação de Teste de Software O Padrão IEEE foi criado com o propósito de padronizar um conjunto básico de documentos ou artefatos produzidos pelas atividades de teste de software. Esta padronização facilita a comunicação entre clientes e fornecedores através de uma referência comum para os documentos de teste. Também, auxilia na definição e avaliação de completude do processo de teste. Em muitas organizações, a utilização da documentação definida neste padrão aumenta a capacidade de gerenciamento dos testes [IEEE ]. Este padrão cobre os documentos de planejamento, especificação e relatório de testes. O planejamento dos testes define o escopo, as abordagens, as estratégias, os recursos e o cronograma das atividades de teste. A especificação corresponde ao projeto, identificação de casos de teste e detalhamento dos procedimentos de teste. Os relatórios de teste definem os itens de teste, registros de execuções, registro de incidentes e resumo dos resultados. A Tabela 2.3 apresenta o conteúdo de cada documento e seus responsáveis. A Figura 2.7 apresenta o relacionamento entre os artefatos produzidos nas atividades de teste. Os documentos de projeto como Plano de Projeto, Documento de Requisitos e Cronograma são essenciais para a construção do Plano de Teste. A partir das funcionalidades a serem testadas, definidas no Plano de Teste, o Projeto de Teste é definido com a abordagem adotada para cada caso de teste. O documento de Especificação de Caso de Teste é opcional, e os casos de teste podem ser diretamente detalhados no Procedimento de Teste. Após a execução, evidências do teste devem ser registradas (Log de Teste) e, quando necessário, solicitações de mudança (Relatório de Incidente) são abertas. 22

38 Tabela 2.3 Conteúdo dos documentos de teste de software [IEEE ]. DOCUMENTOS CAMPOS BÁSICOS RESPONSÁVEIS Plano de Teste Identificador; Introdução; Itens de teste; Funcionalidades a serem testados; Funcionalidades não testadas; Abordagem do teste; Critérios de liberação/falha dos itens; Requisitos de suspensão e retomada; Entregas do teste; Tarefas do teste; Necessidades de Líder de Projeto ambientes; Responsabilidades, Necessidades da equipe e treinamento; Cronograma; Riscos; Aprovações; Especificação de Caso de Teste Identificador; Itens de teste; Entrada necessária e saída esperada; Ambiente necessário; Requisitos para execução do teste; Dependência com outros casos de teste; Projeto de Teste Identificador; Funcionalidades a serem testadas; Abordagem refinada; Casos de teste; Critérios de passagem e falha por Funcionalidades. Casos de Teste Identificador; Itens de teste; Especificação de entrada; Especificação de saída; Necessidades do ambiente; Requisitos ou procedimentos especiais; Dependências entre casos de teste; Procedimentos de Teste Relatório de Itens de Teste Relatório de Incidentes Relatório de Resultado de Teste Relatório de Sumário dos Testes Identificador; Propósito; Requisitos especiais; Passos do procedimento; Identificador; Itens passados; Localização; Estado; Aprovações; Identificador; Sumário; Descrição do incidente; Severidade; Impacto; Identificador; Descrição; Entradas das atividades de evento; Descrição da execução; Resultados; informações sobre o ambiente; Eventos anormais (conexão com relatório de incidentes); Identificador; Sumário; Variações; Avaliação Funcional; Sumário de resultados; Avaliação dos testes; Sumário de atividades; Aprovações; Líder de Projeto e Analistas de Teste Testadores Equipe de Teste 23

39 Documento do Projeto Documento de Itens Itens de Teste Plano de Teste Projeto de Teste Projeto de Teste Projeto de Teste Documento especificado por este padrão Especificação de Caso de Teste Procedimento de Teste Relatório de Itens de Teste Documento NÃO especificado por este padrão Item de Teste NÃO especificado por este padrão Execução de Teste Processo NÃO especificado por este padrão Log de Teste Log de Teste Relatório de Incidente Relatório de Incidente Relatório de Sumário do Teste Figura 2.7 Relacionamento entre os artefatos e atividades de teste [IEEE ]. 24

40 2.2 Riscos na Engenharia de Software Mesmo com a adoção de novas tecnologias, modelos de processos, técnicas, métodos e ferramentas disponíveis, a maioria dos sistemas desenvolvidos ainda apresenta atrasos no desenvolvimento, custos acima do planejado e funcionalidades aquém das expectativas devido a riscos inesperados, não planejados ou simplesmente ignorados [Rios 2005]. A gerência de projetos, em especial, a gerência de riscos, procura monitorar todo o processo de desenvolvimento do software identificando riscos, suas probabilidades de manifestação, estimando os prejuízos e orientando quanto aos procedimentos a serem adotados. De acordo com Guia PMBOK - Project Management Body of Knowledge [PMI 2004], um risco de projeto é um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade. O objetivo da gerencia de riscos do projeto é aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos negativos no projeto. O Instituto de Engenharia de Software (SEI) define risco como a possibilidade de sofrer perdas nos objetivos do projeto, como impactar na qualidade do produto final, atrasar cronograma, aumentar custos ou mesmo falhar o projeto [SEI 2006]. Neste trabalho, é utilizada a definição de riscos de software fornecida pelo SEI, onde o risco para o teste de software é a possibilidade de uma funcionalidade apresentar falhas, quando em uso pelo usuário, resultando em um produto de software de baixa qualidade Conceitos Básicos Antes de apresentar os conceitos básicos sobre riscos de software, vale ressaltar a diferença entre risco e problema. Os riscos são incertezas de que um evento futuro poderá afetar de forma negativa os objetivos do projeto, enquanto um problema é algo que existe naquele momento e ameaça diretamente os objetivos do projeto. Ou seja, o problema é um risco já materializado. A diferença é muito importante, pois ações para gerenciar riscos serão muito diferentes das ações para gerenciar problemas. Como existe apenas a probabilidade de que o risco venha a ocorrer, ações podem ser tomadas para minimizar, transferir ou até eliminá-lo, ou seja, ações são realizadas preventivamente para que o risco não venha a se tornar um problema. 25

41 Exposição ao risco A gravidade de um risco é avaliada a partir da combinação da probabilidade ou freqüência de ocorrência e da magnitude das conseqüências dessa ocorrência. Uma das métricas mais conhecidas e utilizadas [Boehm 1991] para calcular a exposição ao risco é apresentada na Equação 2.1, onde P(f) representa a probabilidade de ocorrência do risco em uma função e I(f) o impacto desta ocorrência na função. Os valores de P e I são números definidos dentro de uma escala. ER ( f ) = P( f ) * I ( f ) Equação 2.1 Cálculo de exposição ao risco. A Tabela 2.4 apresenta um exemplo da matriz de probabilidade e impacto com escala de 1 (um) a 3 (três) para a probabilidade e 1 (um) a 5 (cinco) para o impacto. Neste exemplo, as escalas de impacto e probabilidade são diferentes, porém não há nenhuma regra para a definição das escalas, podendo estas, inclusive, possuírem o mesmo valor. Tabela 2.4 Matriz de impacto e probabilidade. Alto (3) Médio (2) Baixo (1) Impacto Muito Alto (5) Alto (ER = 15) Alto (ER =10) Médio (ER = 5) Alto (4) Alto (ER = 12) Médio (ER = 8) Baixo (ER = 4) Médio (3) Médio (ER = 9) Médio (ER = 6) Baixo (ER = 3) Baixo (2) Médio (ER = 6) Baixo (ER = 4) Baixo (ER = 2) Muito Baixo (1) Baixo (ER = 3) Baixo (ER = 2) Baixo (ER = 1) Probabilidade Classificação Os riscos de software podem ser classificados de diversas formas. Neste trabalho, é utilizada a classificação definida pelo SEI [Carr et al 1993], que fornece uma taxonomia para os riscos de acordo com a sua origem: Engenharia de Produto: problemas no produto relacionados a ações técnicas, também conhecidos como riscos técnicos. Os riscos de produto afetam a qualidade ou o desempenho do software que está sendo desenvolvido e são os riscos tratados neste trabalho. Ambiente de Desenvolvimento: problemas no processo (desenvolvimento) produtivo do software. Estes riscos são também conhecidos como riscos de projeto, pois afetam, dentre outros, o cronograma ou os recursos do projeto. 26

42 Restrições dos Programas: problemas que acontecem no projeto e no processo devido a ações da gerência. São comumente chamados de riscos de negócio e afetam a organização que desenvolve ou adquire o software. A taxonomia organiza os riscos de software em classes, cada classe está subdividida em elementos que, por sua vez, são divididos em atributos, como mostrado na Figura 2.8. Na classe Engenharia de Produto, temos o elemento Requisitos, que contém os atributos Estabilidade, Completude, Claridade, Validade, Viabilidade, Precedente e Escala. Figura 2.8 Taxonomia de riscos proposta pelo SEI e adaptada por [Gusmão 2005]. Além da taxonomia, o SEI fornece um questionário baseado em taxonomia de riscos, o Taxonomy-Based Questionnaire (TBQ) para a etapa de identificação dos riscos. O TBQ conduz os entrevistados através da taxonomia, sugerindo áreas para discussão adicional. A Tabela 2.5 apresenta um exemplo das questões contidas no TBQ para o elemento Requisito da classe Engenharia de Produto. Neste exemplo, caso o entrevistado responda sim, indica a existência de riscos na funcionalidade ou requisito analisado. 27

43 Tabela 2.5 Questões de estabilidade e completude para o elemento requisito. Classe: Engenharia de Produto Elemento: Requisito Atributo: [01] Os requisitos da funcionalidade estão mudando enquanto ela está sendo desenvolvida? Estabilidade Se SIM, qual parte da funcionalidade está mudando? Atributo: [02] Ainda existe algo para ser especificado nesta funcionalidade? Completude Se SIM, qual parte da funcionalidade não está especificada? Estratégias para Tratamento dos Riscos Quatro estratégias lidam, normalmente, com ameaças ou riscos com impacto negativo nos objetivos do projeto: Prevenir: definição de ações para eliminar o risco; Transferir: repassa para outra parte a responsabilidade pelo gerenciamento de um risco; Mitigar: redução da probabilidade e/ou impacto de um risco até um limite aceitável; Aceitar: o plano de gerenciamento do projeto não é alterado para tratar um risco ou não se consegue identificar uma estratégia de resposta adequada; Processo de Gerência de Riscos segundo o Guia PMBOK O Instituto de Gerência de Projeto Project Management Institute (PMI) criou em 1986 a primeira versão do Guia PMBOK - Project Management Body of Knowledge Guide [PMI 2004], guia que descreve o conhecimento e as melhores práticas em gerenciamento de projetos. De acordo com o Guia PMBOK, o conhecimento necessário para gerenciar projetos está dividido em nove áreas: Gerência de Integração, Gerência de Escopo, Gerência de Tempo, Gerência de Custo, Gerência de Qualidade, Gerência de Recursos Humanos, Gerência de Comunicação, Gerência de Riscos e Gerência de Aquisições. A gerência de riscos do projeto inclui os processos referentes ao planejamento da gerência de riscos, à identificação, à análise, ao planejamento das respostas e ao controle e à monitoração dos riscos em um projeto. Esses processos interagem entre si e com os processos das outras áreas de conhecimento da gerência de projetos. Planejar a Gerência de Risco Consiste no planejamento e execução das atividades da gerência de riscos a serem realizadas no projeto. 28

44 Identificação de Riscos Identifica e documenta os riscos que podem afetar, de alguma forma, o sucesso do projeto. Técnicas como reuniões de brainstorm, entrevistas, listas de verificação, questionários são comumente utilizadas nesta fase. Análise Qualitativa de Riscos Nesta fase, os riscos identificados são priorizados através da combinação de sua probabilidade de ocorrência e impacto. Análise Quantitativa de Riscos Consiste na análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto. Técnicas mais avançadas como estatística, simulação e outras são utilizadas para a priorização nesta análise. Planejamento de Respostas a Riscos Desenvolvem-se ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. Monitoramento e Controle de Riscos Os riscos identificados são acompanhados e há o monitoramento dos riscos residuais e identificação de novos riscos, execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projeto Processo de Gerência de Riscos segundo o Processo Unificado da Rational (RUP) Como descrito na Seção 2.1.2, o RUP é um processo da Engenharia de Software baseado em melhores práticas de desenvolvimento e em princípios fundamentais, dentre os quais ser direcionado a riscos. De acordo com o processo, é essencial identificar e combater os itens de risco mais alto no início do projeto. Juntamente com cada risco, deve haver um plano para tratamento, que é entrada para o planejamento das atividades do projeto e das iterações. O foco das fases do RUP com relação aos riscos de software é: Concepção: foco no tratamento dos riscos relacionados a restrições dos programas, também conhecidos como riscos de negócio. 29

45 Elaboração: foco principalmente nos riscos técnicos, examinando os riscos de arquitetura e, se necessário, revisando-se o escopo do projeto à medida que seus requisitos tornam-se mais bem compreendidos. Construção: foco nos riscos técnicos associados ao desenvolvimento e ao teste, que podem impedir a conclusão do desenvolvimento do produto de software. Transição: foco nos riscos associados com a logística de entrega do produto ao usuário. O Gerente de Projeto é responsável pela execução das atividades: Desenvolver o Plano de Gerenciamento de Riscos e Identificar e Avaliar Riscos, que têm como entrada ou saída os artefatos: Documento de Visão, Plano de Gerenciamento de Riscos e Lista de Riscos. Identificar e Avaliar Riscos O Gerente identifica, analisa e prioriza os possíveis riscos. Identifica estratégias de prevenção, diminuição e contingência e reavalia os riscos durante e ao final de cada iteração. Desenvolver o Plano de Gerenciamento de Riscos O Gerente define procedimentos e ferramentas para gerenciamento de riscos, cria lista inicial de riscos, define equipe de gerenciamento de riscos, define estratégias para gerenciar os dez maiores riscos e define a programação para elaboração de relatórios e revisões de riscos Atividades da Área de Processo do Gerenciamento de Riscos do Modelo CMMI O modelo Capability Maturity Model Integration (CMMI) foi criado em agosto de 2000 para integrar os diversos modelos do CMM que atendem às várias atividades relacionadas ao desenvolvimento de software [CMMI 2006]. O CMMI tem como objetivo guiar a avaliação de melhorias nos processos das organizações e contém duas formas de representação: Representação Contínua: possibilita à organização utilizar a ordem de melhoria que melhor atende aos objetivos de negócio da empresa. É caracterizado pelos níveis de capacidade: incompleto, executado, gerenciado, definido, quantitativamente gerenciado e em otimização. Representação por Estágios: disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios, onde cada estágio serve de base para o próximo. É caracterizado pelos níveis de maturidade: inicial, gerenciado, definido, quantitativamente gerenciado e em otimização. 30

46 Cada nível é constituído por um conjunto de áreas de processos, compostas por objetivos específicos e objetivos genéricos. Cada objetivo específico (SG) pode ser composto por um conjunto de práticas específicas (SP) como mostrado na Tabela 2.6. Tabela 2.6 Objetivos e práticas da área de processo de gerenciamento de riscos. SG1 Preparar-se para a Gerência de Riscos SP 1.1 Determinar Fontes e Categorias de Riscos SP 1.2 Definir Parâmetros de Riscos SP 1.3 Estabelecer uma Estratégia para a Gerência de Riscos SG2 Identificar e Analisar Riscos SP 2.1 Identificar Riscos SP 2.2 Avaliar, Categorizar e Priorizar Riscos SG3 Mitigar Riscos SP 3.1 Desenvolver Planos de Mitigação de Riscos SP 3.2 Implementar Planos de Mitigação de Riscos O gerenciamento de riscos em projetos é tratado inicialmente pelo CMMI no segundo nível de maturidade pelas SGs Desenvolvimento do Plano do Projeto e Monitorar o Projeto de Acordo com o Plano. Esta atuação, entretanto, é feita de uma forma reativa, ou seja, com foco apenas na identificação dos riscos para conscientização e reação à medida que eles ocorram. O gerenciamento de riscos é efetivamente tratado no terceiro nível de maturidade através da área de processo de Gerenciamento de Riscos. Esta área de processo atua de uma forma proativa no sentido de minimizar os impactos dos riscos nos objetivos do projeto. A seguir, é fornecida uma breve descrição para as práticas específicas da área de processo de gerenciamento de riscos apresentadas na Tabela 2.6. Determinar Fontes e Categorias de Riscos A identificação prematura das fontes de riscos internas ou externas possibilita a identificação prematura dos riscos. Estabelecer categorias para os riscos provê um mecanismo para coletar e organizar os riscos e gerenciar as atenções para aqueles riscos que podem ter conseqüências mais sérias. Definir Parâmetros de Riscos Os parâmetros são usados para analisar e categorizar os riscos e para controlar a tarefa de gerência de riscos. Eles Servem para avaliar e quantificar a probabilidade dos riscos e os níveis de severidade dos mesmos. 31

47 Estabelecer uma Estratégia para a Gerência de Riscos Fazem parte da estratégia, a definição do escopo para gerência de riscos, os métodos e ferramentas que serão utilizados, as fontes e categorias de riscos, parâmetros e técnicas de mitigação. Identificar Riscos Os riscos identificados são documentados, incluindo o contexto, condições e conseqüências de sua ocorrência. Avaliar, Categorizar e Priorizar Riscos Cada risco é avaliado e recebe valores de acordo com os parâmetros de risco, que incluem probabilidade, severidade ou impacto e limites. Para o tratamento, é interessante agrupar os riscos em níveis ou categorias. Desenvolver Planos de Mitigação de Riscos Inclui técnicas e métodos usados para evitar, reduzir e controlar a probabilidade de ocorrência do risco e a contingência caso o risco ocorra. Implementar Planos de Mitigação de Riscos Planos de mitigação de riscos são desenvolvidos e implementados quando necessário para reduzir os riscos antes que eles se tornem problemas Atividades da Gerência de Riscos do Instituto de Engenharia de Software (SEI) A gerência de riscos, de acordo com o SEI - Software Engineering Institute, é uma prática com processos, métodos e ferramentas para gerenciar riscos em um projeto [SEI 2006]. Ela fornece um ambiente disciplinado para a tomada de decisão, a fim de avaliar continuamente o que pode dar errado (os riscos), determinar quais riscos são importantes de tratar e implementar estratégias para tratamentos dos riscos identificados. O paradigma de riscos definido pelo SEI [SEI 2006] apresentado na Figura 2.9 mostra as diferentes atividades que compõem a gerência de riscos. A definição é apresentada na forma de um círculo para enfatizar que o processo é contínuo. A comunicação está localizada ao centro porque as informações precisam fluir entre as atividades e porque a comunicação é, normalmente, um grande obstáculo para a gerência de riscos. O framework define seis 32

48 atividades, estruturadas da forma que melhor se encaixam na gerência de projeto. A seguir, é apresentado um breve resumo das atividades do paradigma de gerência de riscos: CONTROLAR IDENTIFICAR RASTREAR COMUNICAR ANALISAR PLANEJAR Figura 2.9 Paradigma da gerência de riscos [SEI 2006]. Identificar Localiza os riscos antes que estes se tornem problemas. Para a identificação de riscos, o SEI propõe o questionário baseado em taxonomia de riscos [Carr et al 1993] apresentado na Seção Analisar Transforma os dados dos riscos em informação para tomada de decisão. Avalia o impacto, a probabilidade, classifica os riscos e os prioriza. Planejar Traduz as informações dos riscos em decisões e ações para o presente e futuro e implementa estas ações. Formas de tratamento para os riscos foram apresentadas na Seção Acompanhar Monitora os indicadores de riscos e ações de mitigação. Métricas apropriadas de riscos são utilizadas para monitoramento e controle. Controlar Corrige desvios dos planos de mitigação de riscos. 33

49 Comunicar Provê informações internas e externas do projeto nas atividades de riscos. A comunicação acontece entre todas as atividades da gerência de riscos. 2.3 Resumo do Capítulo Nos dias atuais, práticas de teste e gerência de riscos estão sendo bastante demandadas pelas organizações com o propósito de produzirem software com qualidade e com o menor esforço possível. O teste de software assegura que os requisitos corretos foram implementados, enquanto que a gerência de riscos possibilita o conhecimento e tratamento dos fatores de riscos antes que esses se tornem problemas e impactem nos objetivos do projeto. Este Capítulo apresentou um resumo dos conceitos, características, modelos e processos da área de testes e riscos de software. Ele é fundamental para o entendimento dos conceitos, atividades, práticas e papéis do RBTProcess, que foi concebido a partir das informações apresentadas. Os modelos de teste e riscos de software, bem como os processos apresentados neste Capítulo são completos, bem definidos, largamente conhecidos e utilizados na indústria e academia. Além de serem referências para a construção de outros modelos e processos. 34

50 Capítulo 3 Teste de Software baseado em Riscos O consultor James Bach é considerado o pai da abordagem de teste baseado em riscos [Goldsmith 2006]. Ele descreveu a idéia em seu artigo intitulado: The Challenge of Good Enough Software em outubro de 1995 na revista American Programmer [Bach 1995]. O teste baseado em risco consiste em um conjunto de atividades que favorece a identificação de fatores de riscos associados aos requisitos do software. Uma vez identificados, os riscos são priorizados de acordo com a sua probabilidade de ocorrência e impacto. Os casos de teste, por sua vez, são projetados com base nas estratégias para tratamento dos fatores de riscos identificados. O controle da execução dos testes permite uma mitigação dos fatores de riscos associados. A avaliação e o controle desses fatores de riscos não são atividades triviais e requerem bastante experiência e conhecimento do negócio [Bach 2003]. Vale ressaltar que os riscos tratados nesta abordagem são os riscos relacionados à engenharia de produto ou riscos técnicos, que podem ser mitigados através do teste de software. Focar em teste baseado em risco significa fazer julgamento sobre cobertura de teste; seleção do número de testes a ser conduzido; escolhas dos tipos de testes e de revisões; o uso e balanceamento entre teste dinâmico e análise estática, dentre outros problemas [Redmill 2004]. A abordagem RBT é utilizada, mais fortemente, no planejamento e na estratégia de execução dos casos de teste [Bach 2003]. Seu uso, entretanto, é recomendado também na de fase construção ou projeto dos casos de teste, como forma de otimizar o processo de teste, projetando casos de teste apenas para os requisitos prioritários. 35

51 Bach (1999) divide a abordagem RBT em três etapas, conforme mostra a Tabela 3.1. Essas são as etapas essenciais da abordagem RBT, onde os riscos técnicos associados aos requisitos de software são identificados, analisados e controlados. Tabela 3.1 Etapas do teste baseado em riscos [Bach 1999]. 1. Elaboração de lista de Esta etapa consiste na identificação e análise dos riscos técnicos associados aos riscos priorizada requisitos do software. 2. Realização de testes Consiste na criação e execução de testes que verificam a existência ou não do que exploram cada risco identificado. As abordagens encontradas na literatura não fornecem risco metodologia para a atividade de criação dos casos de teste. No entanto, para a execução, diversas estratégias foram encontradas e vão desde listas de execução ordenadas por exposição ao risco [Chen 2002] a listas ordenadas por tempo de 3. Acompanhamento e controle dos riscos execução de cada caso de teste [Schaefer 2002]. Assim que um risco for eliminado, um novo risco surge e os esforços de teste devem ser ajustados para que foquem sempre nos riscos mais importantes. 3.1 Atividades A Figura 3.1 apresenta o modelo de atividades do processo de gerência de riscos definido por Karolak e alterado por Amland [Amland 1999] para incluir elementos relevantes aos testes baseado em risco dentro de um processo de teste. As caixas ovais representam as alterações realizadas por Amland e são artefatos produzidos ou atividades realizadas a partir das atividades (retângulos) do processo de gerenciamento de riscos. Para cada atividade do ciclo de vida do processo de teste de software, há uma correspondente na gerência de riscos, com o intuito de fornecer o tratamento e acompanhamento adequado para os riscos técnicos identificados. Árvore de itens de testes Identificação dos Riscos Estratégia dos Riscos Plano de Testes Mitigação dos Riscos Inspeção e Execução dos Testes Métricas de Testes Avaliação dos Riscos Comunicação dos Riscos Matriz: Custo e Probabilidade Previsão dos Riscos Figura 3.1 Atividades relevantes para RBT [Amland 1999]. A atividade de identificação de riscos produz como resultado um lista de riscos associados aos requisitos a serem testados. A partir da avaliação qualitativa e/ou quantitativa, os riscos são priorizados. Também, estratégias para mitigação dos riscos são elaboradas de 36

52 acordo com sua prioridade, e estas informações servem como base para criação do plano de testes. Quando os testes ou inspeções são realizados, os riscos são mitigados, ou pelo menos, são minimizados através da descoberta de workarounds para que o impacto dos fatores de riscos seja menor. A comunicação dos riscos fornece os dados para definição e acompanhamento dos riscos através de um conjunto de métricas. 3.2 Principais Abordagens Nesta seção, são apresentadas a principais abordagens RBT disponíveis na literatura, esboçando suas características, pontos fortes e oportunidades de melhoria Abordagem baseada em Heurística Bach define duas abordagens distintas, baseadas em heurística para a atividade de identificação dos riscos: na abordagem Inside-Out, o produto é estudado e é questionado, repetidamente, o que pode dar errado neste produto; na abordagem Outside-In, uma lista de potenciais riscos é utilizada, juntamente com detalhes do produto [Bach 1999]. Para cada risco, é identificado se este se aplica ou não a um determinado componente. Bach sugere três tipos de listas para auxiliar a identificação dos riscos: Lista de categorias de critérios de qualidade: são categorias desenvolvidas para atenderem a diferentes tipos de requisitos. A lista é apresentada na Tabela 3.2 e foi desenvolvida a partir dos critérios do padrão ISO 9126 e FURPS 1. Tabela 3.2 Lista de categorias de critérios de qualidade [Bach 1999]. Capacidade O requisito realiza a função requerida? Confiabilidade A funcionalidade resiste a falhas em todas as situações? Usabilidade Quão fácil é a utilização da funcionalidade pelo usuário? Performance Quão rápido é o tempo de resposta da funcionalidade? Instalabilidade Quão fácil é a instalação do software? Compatibilidade Quão bem a funcionalidade trabalha com componentes externos e outras configurações? Suportabilidade Quão econômica é a funcionalidade para fornecer suporte ao usuário? Testabilidade Como o produto pode ser testado efetivamente? Manutenibilidade Quão econômicas são as manutenções corretivas e evolutivas? Portabilidade Quão econômica é a portabilidade para outra plataforma? Localizabilidade Quão econômica é a disponibilização da funcionalidade em outra língua? Listas genéricas de riscos: são aquelas que possuem riscos universais a qualquer sistema. São apresentadas na Tabela

53 Complexo Novo Modificado Dependência em componente superior: Dependente de componente inferior Crítico Preciso Popular Estratégico Terceirizado Distribuído Defeituoso Falhou recentemente Tabela 3.3 Lista genérica de riscos [Bach 1999]. Qualquer coisa desproporcionalmente grande. Qualquer coisa que não possua histórico no produto. Qualquer coisa que tenha sido modificada ou melhorada. Qualquer coisa cuja falha causaria um efeito cascata de falhas no resto do sistema. Qualquer coisa que seja extremamente dependente de falhas no resto do sistema. Qualquer coisa cuja falha poderia causar um dano substancial. Qualquer coisa que deva atender a requisitos exatos. Que será muito usado. Qualquer coisa que tenha especial importância para o seu negócio, como uma característica que lhe distingue da competição. Qualquer coisa usada no seu produto, mas que foi desenvolvida fora do projeto. Qualquer coisa que esteja espalhada em relação a tempo ou espaço, e que seus elementos devam trabalhar juntos. Qualquer coisa que conhecidamente tenha problemas. Qualquer coisa com uma história recente de falha. Os catálogos de risco: São listas de riscos que pertencem a um domínio em particular. A Tabela 3.4 apresenta uma versão resumida do que seria um catálogo de riscos para um instalador. Tabela 3.4 Catálogo de riscos para um instalador [Bach 1999] Instalação dos arquivos errados. Arquivos corrompidos. Hardware não foi configurado de forma apropriada. Outras aplicações corrompidas. O protetor de tela interfere no instalador. Não há detecção de aplicações incompatíveis. O instalador silenciosamente substitui ou modifica arquivos críticos ou parâmetros. O processo de instalação é muito lento. O processo requer o constante monitoramento do usuário. O processo de instalação é confuso. Após a identificação dos riscos utilizando uma das abordagens explicadas anteriormente. A estes, são atribuídos valores em uma escala de interesse, e os riscos com maior valor são testados prioritariamente. O autor também sugere formas de organização dos riscos para facilitar o acompanhamento e controle dos mesmos. A principal dificuldade dessa abordagem está no conhecimento prévio do negócio a fim de realizar a análise dos riscos da maneira mais fiel possível. Existe a possibilidade de a análise ter sido realizada de forma errada e, conseqüentemente, os verdadeiros riscos não terem sido atacados da forma correta. 38

54 3.2.2 Abordagem baseada em Métricas Amland desenvolveu um conjunto de métricas para a análise de risco com o objetivo de subsidiar um processo de teste [Amland 1999]. Essas métricas foram aplicadas em estudo de caso de uma aplicação de instituição financeira. O modelo para o cálculo da exposição ao risco é baseado na probabilidade de uma falha ocorrer e no custo dessa falha na função correspondente, tanto para o provedor do serviço quanto para o cliente. Na sua metodologia, existem três fontes de análise de risco: Qualidade da função (área) a ser testada. O autor propõe uma função, na qual são levados em consideração aspectos como qualidade do produto de software, esperiência dos desenvolvedores e complexidade, tamanho e maturidade das funcionalidades. Segundo o autor, funcionalidades complexas, de má qualidade e/ou desenvolvidas por programadores inexperientes estão mais expostas a falhas que funções baseadas em projeto de melhor qualidade e que foram desenvolvidas por programadores mais experientes. Essa função corresponde à probabilidade P(f), que pode assumir valores entre 0 e 1. As conseqüências de uma falha ponto de vista de um cliente, em uma situação de produção podem ser representadas, dentre outras, pela probabilidade de ameaça legal, perda de posicionamento no mercado e pelo não cumprimento de regulamentações governamentais. Estas conseqüências representam o custo de uma falha para o consumidor C(c). As conseqüências de uma falha do ponto de vista do vendedor do serviço estão relacionadas, dentre outras, à probabilidade de publicidade negativa, altos custos de manutenção de software e perda de clientes. Estas conseqüências representam o custo de uma falha para o vendedor C(v). Para o autor, o custo para o consumidor é igualmente importante na análise dos riscos em relação ao custo do vendedor. A exposição de risco é dada pela função: C( c) + C( v) Re( f ) = P( f )* 2 Equação 3.1 Cálculo para exposição do risco. Tendo em vista o grau de exposição ao risco, as áreas com risco mais alto têm maior prioridade nos testes e, durante a execução dos testes, à medida que falhas vão aparecendo, 39

55 novas prioridades podem ser adicionadas ao projeto. Também, o grau de exposição ao risco vai sendo atualizado para cada funcionalidade e a prioridade do teste pode ser modificada. Um exemplo de grau de exposição ao risco calculado para a função Fechar Contas é mostrado na Tabela 3.5. O grau de exposição ao risco foi calculado para todas as funções e a lista foi ordenada para identificar quais áreas deveriam ser focadas durante o teste. A probabilidade é calculada como a média ponderada de uma função em particular dividida pela maior média ponderada de todas as funções, resultando em uma probabilidade na faixa entre 0 e 1. Tabela 3.5 Exposição ao risco calculado para a função fechar contas [Amland 1999]. CUSTO PROBABILIDADE Função C(v) C(c) Média Nova Projeto/ Tamanho Comple- Média Proba- Expo- Função Qualidade (1) xidade Ponde- bilidade sição (5) (5) (3) rada ao Risco Fechar Conta ,75 0,74 1,48 Além das métricas para o cálculo de exposição ao risco, Amland utiliza, em seu estudo de caso, métricas para acompanhamento do progresso dos testes. Alguns exemplos são: número de casos de testes planejados e executados, número de defeitos por funções, número de horas gastas em teste por defeito encontrado e número de horas gastas para correção de defeitos. A abordagem utilizada por Amland realiza as atividades apresentadas na Figura 3.1 e está dividida em seis passos apresentados a seguir: 1. Identificação e Estratégia dos Riscos o Passo 1: Planejamento: faz parte de toda atividade de teste realizar o planejamento, definindo as funcionalidades que serão testadas, ambiente de teste, padrões de documentação, execução e registro. A estratégia de riscos também é definida nesse passo. 2. Avaliação dos riscos o Passo 2: Identificar os indicadores de riscos: os indicadores são definidos juntamente com o grupo do projeto. É importante que os indicadores façam sentido para o sistema e que todos tenham o mesmo 40

56 entendimento. Foram utilizados como indicadores, dentre outros, o número de defeitos, número de linhas de código, número de mudanças desde a última versão e complexidade da função. o Passo 3: Identificar o custo de um defeito: assim como no passo 2, indicadores são definidos para o custo de um defeito, tanto para o usuário (cliente), quanto para o desenvolvedor (vendedor) do produto de software. o Passo 4: Identificar elementos críticos: calcular a exposição do risco de cada funcionalidade utilizando os valores obtidos nos passos 2 e Mitigação dos Riscos Passo 5: Execução dos testes: uma vez concluída a análise do riscos, os testes seguem a ordem de execução da lista de priorização. Deve-se acompanhar não somente a ordem de execução, mas também a depedência entre os casos de testes e realizar as adaptações necessárias. 4. Comunicação e Previsão dos Riscos o Passo 6: Estimar o tempo para completar: utilizar as métricas de progresso dos testes para reportar a situação atual dos testes e prever o tempo necessário para completá-los. A abordagem definida por Amland foi utilizada para testar dois módulos de uma aplicação financeira contendo, respectivamente, doze e trezentas funcionalidades. Sendo que, para o segundo, por falta de tempo, foram avaliadas as vinte funcionalidades mais importantes para o cliente. Um dos maiores problemas relatados por Amland foi falta de conhecimento de algumas funcionalidades que dificultou a análise e produziu resultados não confiáveis. Um nível mínimo de teste foi definido para as funcionalidades com baixa exposição ao risco e testes extras foram definidos para funcionalidades com maior exposição ao risco. O cliente avaliou o produto entregue como de excelente qualidade. O número de defeitos encontrados foi similar ao das versões anteriores, porém o tempo gasto para concluir os testes e o número de recursos utilizados foi menor. O grande desafio da definição da abordagem, segundo Amland, foi a identificação dos indicadores de custo de falha e de qualidade. Foi utilizada uma abordagem simples, mas, segundo o autor, satisfatória. Assim, como na maioria das abordagens, o autor mantém foco somente na atividade de análise dos riscos, não fornecendo subsídios para a identificação dos riscos associados aos requisitos, fundamental para a criação dos casos de teste baseado em riscos. 41

57 3.2.3 Abordagem baseada em Código-fonte Orientado a Objetos [Rosenberg et al 1999] fornecem uma metodologia para identificação de classes que estejam mais propensas a erros, através da aplicação de métricas de complexidade de software orientado a objetos. Segundo os autores foi comprovado que o código mais complexo tem uma maior incidência de erros ou problemas. Seis métricas de medição de projetos orientadas a objeto são utilizadas, identificadas e aplicadas pelo Software Assurance Technology Center (SATC) da Goddard Space Flight Center na NASA. São elas: Número de Métodos ou Number of Methods (NOM): é uma contagem dos diferentes métodos existentes em uma classe. Número Ponderado de Métodos Por Classe ou The Weighted Methods per Class (WMC): é uma soma ponderada dos métodos em uma classe. Se os pesos forem iguais, equivale à métrica anterior. Acoplamento entre objetos ou Coupling Between Objects (CBO): é uma contagem do número de outras classes nas quais uma classe está acoplada. A resposta a uma classe ou The Response for a Class (RFC): é a cardinalidade do conjunto de todos os métodos que podem ser invocados em resposta à uma mensagem para um objeto da classe. Profundidade na árvore ou Depth in Tree (DIT): a profundidade de uma classe, de acordo com a hierarquia, é o número de saltos saindo de uma classe até a raiz da hierarquia de classes. É medida pelo número de ancestrais na classe. Quando existe herança múltipla, a maior DIT é utilizada. Número de filhos ou Number of Children (NOC): o número de filhos é o número de subclasses que herdam diretamente da classe na hierarquia. Por mais de três anos, o SATC coletou e analisou código orientado a objetos escritos em C++ e em Java. Mais de classes de mais de 15 programas foram analisadas. Os valores limites para as métricas individuais, apresentados na Tabela 3.6, foram derivados do estudo da distribuição das métricas coletadas. Tabela 3.6 Valores limites para métricas individuais. VALOR LIMITE MÉTRICA NOM Preferencialmente menor que 20 e aceitável até 40 WMC Preferencialmente menor que 25 e aceitável até 40 CBO Aceitável até 5 RFC Aceitável até 50 DIT Aceitável até 5 NOC Não há consenso, mas, quanto maior, mais alta é a probabilidade de erro 42

58 Segundo os autores, uma métrica nunca deveria ser utilizada sozinha. Para avaliar os riscos do código, são necessárias, pelo menos, duas ou três métricas para termos indicação de um problema em potencial. O alto risco é identificado para classes que tem, ao menos, duas métricas que excedem os limites recomendados. A Tabela 3.7 é um exemplo de métricas de um projeto Java. As células em vermelho representam métricas fora do limite aceitável. Tabela 3.7 Métricas coletadas de um projeto Java. CLASSE NO. MÉTODOS CBO RFC RFC/NOM WMC DIT NOC A análise das classes é fácil de ser aplicada, inclusive pode ser realizada de forma automática. No entanto os autores não propõem estratégias de testes para o código, tampouco formas de rastreamento das funcionalidades impactadas por classes com alto risco de falhas Abordagem para Teste de Regressão Chen, em sua dissertação de mestrado [Chen 2002], define uma estratégia para execução de testes de regressão baseada em especificação. A justificativa principal da autora é que teste de regressão baseado em código é bom para teste de unidade, mas tem problemas de escalabilidade, pois à medida que o tamanho do software cresce, torna-se difícil gerenciar a informação do teste e criar matrizes de rastreabilidade. A autora define dois conjuntos de testes de regressão: Testes de regressão para os componentes que foram alterados: pelo menos um teste é executado para cada componente inserido ou alterado. Testes de regressão baseado em Riscos para os componentes que aparentemente não sofreram modificações: para estes, uma análise de riscos é realizada a partir de questionários submetidos aos participantes do projeto. Esta abordagem projeta casos de teste que focam nas áreas do software que possuem maior risco. Como conseqüência, pode nos auxiliar a atingir um nível de confiabilidade 43

59 adequado na qualidade do software. Essa metodologia utiliza o modelo de risco desenvolvido por Amland [Amland 1999] e apresentado na Seção A fase de seleção de casos de teste envolve os seguintes passos: Passo 1: estimar o custo de cada caso de teste. Ou seja, o custo que uma falha possa causar. O custo é calculado da mesma forma proposta por Amland. Passo 2: derivar a severidade para cada caso de teste. Esse valor é computado a partir do número de defeitos e da severidade destes defeitos. Passo 3: calcular o grau de exposição de risco para cada caso de teste. A exposição ao risco é calculada a partir do custo e da severidade. Passo 4: selecionar os casos de teste que têm os maiores valores de exposição ao risco. A seleção de cenários baseado em riscos deve obedecer duas regras: Regra 1: selecionar os cenários para cobrir os casos de teste mais críticos Regra 2: garantir que os cenários cubram tantos casos de teste quanto possível A seleção de cenários baseado em riscos tem os seguintes passos: Passo 1: calcular a exposição de riscos para cada cenário. Calculado a partir da soma da exposição ao risco dos casos de testes associado a este cenário. Passo 2: selecionar os cenários com maior exposição ao risco Passo 3: atualizar a matriz de rastreabilidade, removendo os cenários selecionados e os testes já cobertos e recalculando a exposição ao risco. Passo 4: repetir os passos 1, 2 e 3 o quanto necessário A abordagem se mostrou bastante eficiente de acordo com os resultados apresentados pela autora. Além disso, a análise realizada através de questionários submetidos aos desenvolvedores, com questões que os mesmos dominam, não constituiu uma tarefa complexa. Segundo a autora, com a ajuda de ferramentas, todo o processo foi realizado de forma rápida. Como a abordagem toma como base, a documentação do sistema, esta, por sua vez, deve encontrar-se sempre atualizada Abordagem baseada em Uso Besson define uma estratégia baseada em uso, segundo a qual, qualquer atividade de teste implica em uma diminuição dos riscos [Besson 2004]. De acordo com o autor, independente 44

60 da quantidade de testes executados, sempre haverá um risco. A idéia é investir o mínimo de esforço em teste possível para maximizar a redução dos riscos. Na sua abordagem, o autor controla os esforços de teste baseado na utilização do sistema, seguindo a teoria de Pareto, que afirma que vinte por cento das funcionalidades permitem ao usuário realizar oitenta por cento do seu trabalho. Seguindo o que diz a teoria de Pareto, o autor sugere testar apenas as funcionalidades que estão incluídas nestes 20%, aumentando assim a qualidade e reduzindo drasticamente o esforço e o custo do teste de software. A Figura 3.2 apresenta o esforço necessário para eliminar todos os riscos identificados (reta em vermelho). Seguindo a idéia de Pareto, a relação entre risco e esforço ficaria mais parecida com o gráfico representado pela linha em azul. Logo, diminuir o risco em cinqüenta por cento pode ser alcançado em um curto espaço de tempo se uma priorização dos testes é feita a partir de uma análise dos riscos. Figura 3.2 Esforço necessário para reduzir em 50% os riscos. A metodologia proposta por Besson é dividida em cinco passos: Passo 1: identificar funcionalidades vitais que podem previnir o usuário de utilizar o sistema se um defeito for encontrado, ou seja, um defeito com alta severidade. Uma forma eficiente de listar essas funcionalidades é a partir de pesquisas com os usuários finais do sistema, experts no domínio do sistema ou através de dados estátisticos de uso de versões anteriores. Uma vez que o risco aumenta com a frequencia de uso, as funcionalidades mais usadas terão maior risco. Passo 2: projetar casos de testes para cada funcionalidade listada no Passo 1. 45

61 Passo 3: estimar tamanho (em hora ou minutos) do esforço necessário para executar os casos de testes identificados. Passo 4: ordenar os casos de testes em ordem ascendente de acordo com o esforço, dessa forma, os casos de testes com menor esforço são executados primeiro. Passo 5: iniciar a execução dos casos de teste na ordem estabelecida no Passo 4 até que o tempo termine. A análise dos riscos é, de certa forma, fácil de ser realizada, uma vez que o usuário especifica as funções que são mais utilizadas no sistema, ou seja, as funções que permitem ao usuário realizar oitenta por cento das suas atividades. Como o autor sugere a execução de testes baseada em esforço, os testes que gastam menos tempo são executados primeiro até que o tempo acabe. Essa abordagem pode ser útil em culturas organizacionais avessas ao teste, visto que se testa somente 20% das funcionalidades disponíveis no software Abordagem baseada em Modelos [Stallbaum et al 2008] desenvolveram uma técnica automática para priorização de casos de testes a partir de análise de riscos e geração de casos de testes de sistema a partir de diagramas de estados como modelos de testes. A abordagem proposta, denominada Risk-based test case Derivation And Prioritization (RiteDAP), acrescenta informações sobre risco a cada transição do diagrama de estado através da definição de valores de probabilidade e impacto, permitindo que um conjunto de casos de teste priorizado seja extraído do modelo. A Figura 3.3 apresenta um modelo de teste (diagrama de estados) com informação sobre risco determinada pela função R (P, D) = P*D, onde P é a probabilidade de uma entidade conter um defeito e D o dano causado por este defeito. Vale salientar que a abordagem gera cenários de casos de teste, ou seja, não são fornecidos procedimentos de teste, bem como os dados de entrada e saída. Para derivar a ordem de execução dos casos de testes, são somadas as informações de riscos (R) de cada transição que compõe o caso de teste. A Tabela 3.8 apresenta alguns casos de teste que podem ser derivados do modelo apresentado na Figura 3.3. Os casos de teste são executados na seguinte ordem: S4, S2, S6, S7, S3, S5, S1. Esta ordem é chamada de Total Risk Score Prioritization (TRSP). 46

62 Figura 3.3 Amostra de um modelo de teste com informações de riscos. Outra forma de execução seria levar em consideração os riscos já cobertos pelos casos de testes anteriores, chamada de Additional Risk Score Prioritization (ARSP), ou seja, não são incluídos em um caminho, os cenários que já foram testados em outro caminho. Por exemplo, na Tabela 3.8, o caminho abghklmntlmn poderia se possível, ser removido de S7, uma vez que este caminho já está sendo coberto em S2. Desta forma, são testados apenas os cenários com riscos que não foram ainda cobertos. Tabela 3.8 Possíveis casos de teste e risco associado. CASO DE TESTE CAMINHO Σ (R) S1 abghklmnopef 17 S2 abghklmntlmnopqrsf 41 S3 abghijpef 27 S4 abghijpqrsf 45 S5 abcdef 19 S6 abcdqrsf 38 S7 abghklmntlmntlmnopef 29 Para validação da abordagem, os autores usaram o diagrama de máquina de estados para calcular taxas de impostos na Alemanha. A base da validação é a hipótese de que, com a priorização dos riscos, a abordagem deve encontrar os defeitos mais cedo. Para a comparação, 47

63 além das duas técnicas de priorização propostas pelos autores (TRSP e ARSP), a priorização randômica (RP) e a priorização ótima (OP) foram utilizadas. RP é alcançada quando todos os casos de teste são escolhidos randomicamente a partir de um conjunto de casos de teste gerados inicialmente. A OP é alcançada quando todas as faltas são descobertas pelo conjunto de casos de teste gerados inicialmente. Na OP, inspeções manuais também foram realizadas para descobrir faltas. No total, oitenta casos de testes foram executados. TRSP encontrou todos os defeitos nos primeiros oito casos de teste. ARSP teve um resultado melhor encontrando todos os defeitos nos quatro primeiros casos de testes. 3.3 Análise Comparativa Após o estudo das diversas abordagens, apresentadas nas Seções a 3.2.6, foi possível realizar um estudo analítico, mostrado na Tabela 3.9. Com exceção da abordagem proposta por [Rosenberg et al 1999], todas as outras utilizam a abordagem funcional ou caixa-preta para construção dos casos de teste, no nível de sistema. Bach propõe diferentes heurísticas para identificar, analisar e controlar riscos durante o processo de teste com o propósito de melhorar a qualidade do produto, focando nas partes do software que precisam ser mais bem testadas. No entanto, o autor não fornece nenhuma indicação de como os casos de teste são gerados. Amland propõe métricas para a análise dos riscos com o propósito de reduzir custos da fase de teste do projeto de desenvolvimento de software e reduzir futuros custos de produção pela otimização do processo de teste. As métricas propostas pelo autor levam em consideração que funcionalidades complexas, novas, construídas com pouca qualidade e com tamanho grande possuem probabilidade maior de apresentar falhas. O autor, também, não fornece nenhuma orientação sobre a criação dos casos de teste. Para Chen, o crescimento contínuo das suítes de teste e a evolução das funcionalidades de um produto de software tornam inviável ou extremamente custosa a execução de um teste de regressão completo. Por este motivo, uma abordagem baseada em riscos reduz o volume de teste de regressão a ser executado, possibilitando que as áreas mais críticas sejam testadas prioritariamente. A autora não realiza a atividade de identificação de riscos e assume que os casos de teste já estão prontos. Dependendo da quantidade de casos de teste, esta abordagem pode ser inviável, uma vez que a análise de riscos é feita a partir dos casos de teste e não a 48

64 partir dos requisitos, como acontece nas demais abordagens, visto que um requisito pode ter n casos de teste associados. Rosenberg e demais autores fornecem uma abordagem para identificação de classes que estejam mais propensas a falhas, através da aplicação de métricas de complexidade de software orientado a objetos. A análise pode ser realizada de forma automática. Os autores, contudo, não propõem estratégias de testes para o código, tampouco formas de rastreamento das funcionalidades impactadas por classes com alto risco de falhas. A abordagem apresentada por Besson utiliza a informação de percentual de uso da funcionalidade para priorização. Isto a torna fácil de ser utilizada, porém não garante que as funcionalidades que estão sendo tratadas estejam mais propensas a apresentar falhas ou precisam ser mais bem testadas. Stallbaum e demais autores desenvolveram uma técnica automática para priorização e geração de casos de teste, utilizando diagramas de estados como modelos de testes. A análise de risco é bastante subjetiva, levando em consideração apenas a probabilidade de ocorrência e o dano. Dependendo do tamanho dos modelos e do número de funcionalidade do software, a análise de cada transição do diagrama pode levar muito tempo ou mesmo tornar-se inviável. A Tabela 3.9 apresenta uma análise comparativa das principais abordagens apresentadas com o modelo de processo proposto neste trabalho. Para a comparação foram elencadas atividades da gerência de riscos de software, que são úteis para o teste de software e atividades mínimas de teste de software existentes em qualquer processo. O RBTProcess está incluído na Tabela 3.9 apenas para efeito de comparação, uma vez este será explicado no Capítulo 4. 49

65 Tabela 3.9 Análise comparativa das principais abordagens RBT. ABORDAGEM/ PROCESSO IDENTIFICAR RISCOS ANALISAR RISCOS PLANEJAR TESTES PROJETAR TESTES EXECUTAR TESTES AVALIAR TESTES CONTROLAR RISCOS Baseada em Heurística Baseada em Métricas Baseada em Uso Testes de Regressão Código Fonte Orientado a Objetos Baseada em Modelo RBTProcess Listas de critérios de qualidade, genéricas e catálogo de riscos Questionário, listas e reunião de brainstorm Equação de Barry Boehm Métricas específicas para Teste de Software Utiliza a informação de percentual de uso Métrica proposta por Amland Métrica para código fonte OO Análise de probabilidade e dano Métrica proposta por Amland com adaptações v Matriz de rastreabilidade Ordem de exposição ao risco Percentual de uso da funcionalidade e tempo de execução do caso de teste v Leva em consideração que os casos de teste estão prontos Ordem de exposição ao risco v Fornece um conjunto de métricas para controle de progresso dos testes v Planeja as iterações de acordo com a exposição ao risco Deriva testes a partir do modelo Indica tipos de casos de teste de acordo com a exposição ao risco v Faz menção a esta atividade, mas não fornece detalhes Não faz menção a esta atividade O RBTProcess será explicado no Capítulo 4. Ordem de exposição ao risco Ordem de exposição ao risco Inclui atividade de avaliação de processo de teste padrão v v Fornece um conjunto de métricas para controle de progresso dos testes 50

66 3.4 Resumo do Capítulo Apesar das diversas abordagens encontradas na literatura, nenhuma fornece um conjunto de atividades completo que auxilie os engenheiros de teste em todo o processo de teste de software. A grande maioria tem como características focar em testes funcionais ou caixapreta e fornecer atividades para análise dos riscos e/ou execução dos casos de teste. Apenas Bach, fornece abordagem baseada em heurística para identificação de riscos, que é essencial para criação dos casos de teste, uma vez que estes são projetados para tratar os riscos identificados. Existe um consenso entre os autores das abordagens apresentadas neste Capítulo de que a abordagem RBT permite reduzir esforços de teste e identificar funcionalidades críticas, entretanto nenhum autor informa o percentual de esforço reduzido e a confiabilidade alcançada com a adoção da abordagem. 51

67 Capítulo 4 RBTProcess: Modelo de Processo de Teste de Software baseado em Riscos Segundo Sommerville (2003), um modelo de processo é uma descrição simplificada de um processo de software, que é apresentada a partir de uma perspectiva específica. Neste Capítulo, é descrito o RBTProcess, um Modelo de Processo de Teste de Software baseado em Riscos. O RBTProcess foi construído a partir de atividades presentes no gerenciamento de riscos e nos processos de teste de software disponíveis na literatura e apresentados nos Capítulos 2 e 3. O RBTProcess é apresentando com seus respectivos fluxos de trabalho, papéis, fases e artefatos. Além disso, são apresentados a forma como o modelo foi documentado e o resultado das simulações de uso do processo e do estudo de caso realizados. 4.1 Documentação do Modelo O modelo de processo está documentado graficamente através do Software Process Engineering Metamodel (SPEM) [SPEM 2005]. O SPEM é um metamodelo que define estereótipos da Unified Modeling Language (UML) para a modelagem de processos de software padrão do Object Management Group (OMG) [SPEM 2005]. A Figura 4.1 apresenta os níveis de modelagem do SPEM. O RBTProcess está modelado no nível M1. 52

68 Figura 4.1 Níveis de modelagem do SPEM. A Tabela 4.1 apresenta uma breve descrição dos estereótipos disponíveis no SPEM e utilizados neste trabalho. Tabela 4.1 Estereótipos disponíveis no SPEM. NOTAÇÃO ESTEREÓTIPO DESCRIÇÃO Papel Descreve os papéis, responsabilidades e competências de (ProcessRole) determinado indivíduo dentro do processo. Artefato (WorkProduct) Descreve algo que contém informação ou é uma entidade física produzida ou usada por atividades do processo. Ex. modelos, códigos, executáveis, planos e documentos. Documento Representa um documento criado, visualizado ou modificado através (Document) Conjunto de Trabalho (WorkDefinition) Atividade (Activity) Guias (Guidance) Disciplina (Discipline) Fase (Phase) de um processo. Descreve a execução, operações realizadas e transformações feitas nos artefatos. Representa um conjunto de atividades. Descreve os passos que um papel realiza para concluir uma única atividade. Elemento do modelo que se associa ao outros elementos e pode conter descrições adicionais, tais como: técnicas, guias e padrões. Agrupamento de elementos do processo (artefatos, papéis, atividades) cujas atividades são organizadas segundo algum ponto de vista em comum. Ex. teste, análise, requisito, projeto e etc. Representa um conjunto de trabalho de alto nível e que é limitado por um milestone. Para criação, documentação e publicação do processo, foi utilizado o Eclipse Process Framework (EPF) [EPF 2007]. O projeto EPF é composto por uma ferramenta de autoria baseada no Eclipse [Eclipse 2008], que descreve o processo, chamada de EPFComposer, além de alguns processos já prontos para serem customizados. A EPFComposer fornece uma terminologia comum, padronizada e reusável através da UMA Unified Method Architecture para definição de métodos e processos. Além de ser facilmente customizável para os diversos tipos de projeto. A Figura 4.2 apresenta uma visão das partes que compõem o projeto EPF e onde o RBTProcess está localizado. 53

69 Figura 4.2 Composição do Eclipse Process Framework [EPF 2007]. No Apêndice A, é apresentado o resultado de uma pesquisa que fornece uma visão sobre a área de teste de toftware, mais especificamente sobre o teste baseado em riscos, em Pernambuco e no Brasil. Nesta pesquisa, pudemos confirmar que a maioria (noventa por cento) das empresas realiza testes funcionais ou caixa-preta e que um número bastante pequeno de entrevistados possui conhecimento avançado sobre riscos de software. Essas informações foram decisivas para, respectivamente, manter o foco do processo em testes funcionais e para criar o papel do Analista de Riscos. Também, identificamos, na pesquisa, que as pessoas que conhecem ou utilizam a abordagem possuem dificuldade em identificar riscos de software. Com isso, propomos, no RBTProcess, o questionário baseado em taxonomia, onde a identificação dos riscos técnicos associados aos requisitos do software é realizada de forma intuitiva, não necessitando de conhecimento prévio sobre a gerência de riscos. 4.2 Visão Geral O RBTProcess é iterativo, orientado a riscos e possui quatro fases distintas juntamente com seus marcos, atividades e responsáveis, como mostrado da Figura Fases O RBTProcess possui quatro fases distintas juntamente com seus marcos e atividades como mostrado na Figura

70 Figura 4.3 Página do modelo de processo criada pelo EPFComposer [RBTProcess 2008]. Figura 4.4 Fases do RBTProcess. Planejamento O foco desta fase é o planejamento inicial dos testes com base na análise dos riscos e tem como marco a priorização dos requisitos a serem testados. Compreende as disciplinas Identificar Riscos, Analisar Riscos e Planejar Testes. 55

71 Projeto Nesta fase, os casos de testes planejados são projetados, com base nos riscos identificados. Compreende a disciplina Projetar Testes. O marco desta fase é a criação de casos de teste que verificam a existência ou não dos riscos identificados. Execução Os casos de testes planejados e projetados são executados. Compreende a disciplina Executar Testes. O marco desta fase é a execução de casos de teste que verificam se riscos associados aos requisitos foram mitigados. Controle Os resultados das execuções dos testes são coletados, analisados e acompanhados. Na disciplina Avaliar Testes, os números, estratégias, tempo de execução e solicitações de mudança são verificados. Na disciplina Controlar Riscos, é realizado o acompanhamento dos riscos. Os riscos mitigados são eliminados da lista de riscos identificados que é entrada para o planejamento da próxima iteração. O marco desta fase é o controle dos riscos mitigados Papéis Os papéis identificados são os mesmos encontrados em diversos processos de teste de software como o Gerente de Testes, o Projetista de Testes e o Testador. Apenas o Analista de Riscos é um papel do processo de gerenciamento de riscos, essencial para identificação, análise e controle dos riscos associados aos requisitos do software. O Apêndice C fornece mais detalhes sobre os papéis do RBTProcess. Analista de Riscos É responsável pelas atividades da Gerência de Riscos como identificação, análise e controle de riscos. O analista pode, inclusive, ser membro da equipe de teste. Ele deve possuir conhecimentos sobre teste de software, identificação e análise dos riscos, além de conhecimento sobre os requisitos do software a ser testado. Gerente de Testes É responsável pela condução e controle das atividades do processo. Alguns dos conhecimentos necessários para o Gerente de Testes referem-se a processos, projeto e planejamento dos testes. 56

72 Projetista de Testes É responsável pela criação dos casos de teste para mitigar os riscos identificados. O projetista necessita de um conhecimento sobre os requisitos do sistema e tecnologia adotada, ferramentas, técnicas para construção de casos de teste, estratégias e tipos de teste. Testador Realiza a execução dos testes projetados e registra solicitações de mudança, quando necessário. O testador necessita de conhecimento sobre o processo de teste, ferramentas utilizadas para execução, configuração do ambiente de execução e solicitação de mudança, além do conhecimento sobre os requisitos do sistema. 4.3 Disciplinas ou Conjuntos de Trabalho Como apresentado no início deste Capítulo, o modelo de processo proposto é constituído de atividades presentes no gerenciamento de riscos e atividades do processo de teste de software. As atividades do processo de teste de software sofreram algumas adaptações, uma vez que essas, agora, são guiadas por riscos. As disciplinas Identificar, Analisar e Controlar Riscos são provenientes do gerenciamento de riscos e baseadas no RUP [RUP 2003], Guia PMBOK [PMI 2004] e CMMI [CMMI 2006]. As disciplinas Planejar, Projetar, Executar e Avaliar Testes são provenientes de processos de teste, baseadas no IEEE Std : Standard for Software Test Documentation [IEEE ], IEEE Std : Standard for Software Verification and Validation [IEEE ], TMM [Veenendaal 2006] e RUP [RUP 2003]. Nas subseções a seguir, são apresentadas as disciplinas do modelo de processo. Um maior detalhamento será fornecido às atividades de gerenciamento de riscos e ao impacto das mesmas nas atividades do processo de teste de software. O modelo de processo completo está disponível em [RBTProcess 2008]. O Apêndice D fornece mais detalhes sobre as Disciplinas do RBTProcess Identificar Riscos Tem como objetivo identificar os riscos técnicos associados aos requisitos do software que podem afetar, de alguma forma, o sucesso do projeto e que também podem ser mitigados através da execução de testes. 57

73 Além do Analista de Riscos que é responsável por esta atividade, o Analista de Requisito, Gerente e Projetista de Teste e Arquiteto ou Desenvolvedor do Software participam da identificação dos riscos. A Figura 4.5 apresenta as atividades, responsáveis e principais artefatos produzidos e/ou consumidos. Figura 4.5 RBTProcess: Disciplina Identificar Riscos. Revisar Fontes e Categoria de Riscos Tem como objetivos avaliar e adaptar as listas de riscos e o questionário baseado em taxonomia para o software que será testado. Os artefatos disponíveis no processo são genéricos e podem ser utilizados em qualquer projeto de desenvolvimento. As listas de riscos fornecidas no RBTProcess são sugeridas por Bach [Bach 1999], em sua abordagem baseada em heurística, como forma de auxiliar os engenheiros de testes na identificação dos riscos técnicos ou de produtos. Além das listas, o questionário baseado em taxonomia de riscos ou Taxonomy Based Questionnaire (TBQ) [Carr et al 1993], apresentado na Seção 2.2, é utilizado, com algumas adaptações, para auxiliar a atividade de identificação dos riscos. O questionário completo é composto por 20 questões que indicam ou não a presença de riscos associados aos requisitos do software. O Analista de Riscos seleciona as questões que serão utilizadas no questionário, levando em consideração o domínio do software a ser testado. São avaliados riscos relacionados à estabilidade, completude, claridade, viabilidade, usabilidade e outros. Idealmente, esta atividade deve ser realizada logo após a definição dos requisitos ou funcionalidades a serem desenvolvidos, alterados ou evoluídos. 58

74 Responder Questionário (TBQ) É a primeira etapa da identificação dos riscos. Para cada requisito, os participantes respondem as perguntas e, de acordo com a resposta, é indicada a existência ou não do risco. Os participantes não precisam ter qualquer conhecimento sobre riscos de software. Um representante de cada etapa do processo de desenvolvimento de software (requisito, análise, projeto, implementação, teste) deve participar desta atividade. Quando possível, o usuário final também pode responder o questionário. O SEI recomenda cinco participantes para esta atividade [Carr et al 1993]. Quando todos tiverem respondido, o Analista de Riscos consolida todas as respostas, extraindo os riscos associados às perguntas, elimina os riscos duplicados e produz uma lista com os riscos identificados para cada requisito ou funcionalidade. Esta atividade deve ocorrer logo após a revisão dos requisitos, uma vez que os requisitos estão sendo estudados naquele momento e existe uma probabilidade maior de todos se lembrarem do propósito e detalhes de cada requisito ou funcionalidade. Realizar Reunião de Brainstorm Esta reunião tem como objetivos validar os riscos levantados na atividade anterior e identificar riscos associados ao domínio do produto de software. Além disso, os participantes podem fornecer mais detalhes sobre os riscos identificados que possam auxiliar no projeto dos casos de teste. As listas de riscos podem ser utilizadas para guiar a reunião de brainstorm, visando torná-la mais eficiente. O produto dessa atividade é o refinamento da lista de riscos identificados para cada requisito ou funcionalidade Analisar Riscos Tem como objetivo a priorização dos requisitos ou funcionalidades do software a ser testado com base na análise dos riscos técnicos identificados na disciplina Identificar Riscos. Além do Analista de Riscos, que é responsável por esta atividade, o Analista de Requisito, Gerente e Projetista de Teste e Arquiteto ou Desenvolvedor do Software participam da priorização dos riscos. A Figura 4.6 apresenta as atividades, responsáveis e principais artefatos produzidos e/ou consumidos. 59

75 Figura 4.6 RBTProcess: Disciplina Analisar Riscos. Calcular Exposição ao Risco As fórmulas utilizadas neste processo para a priorização dos riscos foram propostas por Amland [Amland 1999] e posteriormente utilizadas por Chen [Chen 2002], em sua estratégia para execução de testes de regressão baseada em riscos, com algumas adaptações. A fórmula de Amland foi explicada no Capítulo 3. As métricas e pesos definidos por Amland foram utilizados nas primeiras versões deste processo da forma como foram sugeridos pelo autor. No entanto, com a avaliação do processo através de simulações, algumas adaptações foram necessárias, além da inclusão de nova métrica (Dependência) à fórmula para que o cálculo de exposição ao risco alcançasse maior confiabilidade. A Figura 4.7 apresenta as métricas propostas por Amland, com seus respectivos pesos, além da métrica proposta neste trabalho. A primeira coluna desta tabela representa o identificador de cada uma das funcionalidades testadas. O nome das funcionalidades aparece na Tabela 4.3. Figura 4.7 Métricas para cálculo de exposição ao risco dos requisitos. 60

76 Os participantes desta atividade são os mesmos que realizaram a identificação dos riscos. A escala sugerida pelo RBTProcess para os indicadores de custo e probabilidade vai de 1 até 3. Um guia é fornecido para atribuição desses indicadores de acordo com a atividade realizada pelo participante. Para a métrica de qualidade, por exemplo, são sugeridos os valores para os indicadores apresentados na Tabela 4.2. Tabela 4.2 Exemplo de indicadores para a métrica de qualidade da funcionalidade. INDICADOR DESENVOLVEDOR TESTADOR ANALISTA DE REQUISITOS 1 Não tem conhecimento das Funcionalidade não Requisito está estável tecnologias/ferramentas utilizadas no desenvolvimento do software apresentou defeitos nas últimas versões. 2 Tem conhecimento razoável das Funcionalidade Requisito ou tecnologias/ferramentas utilizadas no apresentou alguns funcionalidade tem desenvolvimento do software defeitos nas últimas sofrido poucas versões. alterações 3 Domina a tecnologias/ferramentas Funcionalidade Requisito ou utilizadas no desenvolvimento do apresentou muitos funcionalidade tem software defeitos nas últimas sofrido muitas versões. alterações Priorizar Riscos Os riscos analisados na etapa anterior são consolidados pelo Analista de Riscos, gerando a lista de priorização dos riscos. É calculada a média dos valores de exposição ao risco atribuídas, pelos participantes, a cada funcionalidade. Além disso, o Analista de Riscos classifica os requisitos, definindo intervalos para o valor de exposição ao risco como apresentado na Tabela 4.3. No RBTProcess, as funcionalidades com maior exposição ao risco são testadas primeiro. Em seguida, são testadas as funcionalidades com prioridade média. As funcionalidades com prioridade baixa somente são testadas se houver tempo disponível. Tabela 4.3 Lista de priorização dos requisitos. ID. FUNCIONALIDADE REQ. DESENV. TESTE MÉDIA PRIORIDADE FUNC01 Simulator Properties FUNC06 Local States FUNC08 Phenomenon-State Relation BAIXA FUNC09 Quantity Tasks FUNC03 Global States FUNC04 Blocks MÉDIA FUNC05 Create Group FUNC07 Create Phenomenon FUNC11 Search FUNC02 Kernel Configuration ALTA FUNC10 Group Tasks

77 4.3.3 Planejar Testes Tem como objetivo direcionar e controlar as atividades de teste com base na avaliação de riscos. O Gerente de Testes é o responsável pela atividade, mas ele conta com a participação do Projetista ou Arquiteto de Testes. As atividades de planejamento são as mesmas de qualquer processo de teste de software, porém o Gerente de Teste possui a informação de riscos identificados e exposição ao risco para cada funcionalidade como principal entrada para definição de escopo, recursos, cronogramas e outros. A Figura 4.8 apresenta as atividades, responsáveis e principais artefatos produzidos e/ou consumidos. Figura 4.8 RBTProcess: Disciplina Planejar Testes. Definir Escopo dos Testes Consiste na definição dos requisitos que serão testados ou não, tomando, como base, a análise dos risco. A priorização dos requisitos é realizada a partir dos valores de exposição ao riscos. O RBTProcess sugere que, a cada iteração, sejam testados, por exemplo, um conjunto de requisitos de acordo com a sua prioridade. Os requisitos classificados como de baixa prioridade somente são testados se houver tempo disponível. A Tabela 4.4 apresenta um exemplo de definição do escopo, utilizando a informação dos riscos da Tabela 4.3 e supondo que o Gerente tem apenas duas iterações para projetar e executar todos os testes. O Gerente definiu que, na primeira iteração, serão testados os requisitos com alta prioridade, na segunda, os requisitos com média prioridade e os requisitos com baixa prioridade são testados se 62

78 houver tempo disponível. A cada iteração, esse planejamento é revisto de acordo com o controle dos riscos. Iteração I Iteração II Caso sobre tempo Definir Estratégia Tabela 4.4 Definição do escopo dos teste. ESCOPO DA ITERAÇÃO NÚMERO DE RISCOS IDENTIFICADOS FUNC10 8 FUNC02 5 FUNC11 1 FUNC07 1 FUNC05 7 FUNC04 0 FUNC03 1 FUNC09 1 FUNC08 0 FUNC06 3 FUNC01 3 Diversas estratégias podem ser utilizadas com base na análise dos riscos. Uma delas é, por exemplo, a automação dos testes para os requisitos classificados como de alta prioridade. Definir Cronograma Também com base na análise dos riscos, os requisitos com prioridade alta serão planejados, projetados e executados nas primeiras iterações. Os requisitos com baixa prioridade só serão planejados, projetados e executados se houver tempo disponível Projetar Testes Tem como objetivo identificar e descrever os casos de teste para os requisitos e riscos a serem testados com base na análise de riscos. É nesta atividade que está o grande diferencial da abordagem RBT, pois, além do documento de requisitos e do planejamento dos testes, o Projetista de Teste recebe o documento de identificação dos riscos para criação dos cenários de teste que visam mitigar os riscos identificados. Assim, como na disciplina de Planejamento de Testes, as atividades são as mesmas, o que muda é a forma como estas serão conduzidas e realizadas. O Analista de Riscos também participa desta atividade. A Figura 4.9 apresenta as atividades, responsáveis e principais artefatos produzidos e/ou consumidos. 63

79 Figura 4.9 RBTProcess: Disciplina Projetar Testes. Definir Estratégia de Casos de Teste Consiste na identificação dos cenários a serem testados, além da definição da abordagem e tipo de testes que serão utilizados. Considerando a idéia do principle of diverse half-measures explicada por Bach [Bach 2003], onde ele enfatiza que não é indicado utilizar apenas uma abordagem de teste, ou seja, não se deve executar somente teste baseado em riscos, principalmente, porque existe o risco de os requisitos não terem sido analisados corretamente. Assim, o processo sugere diferentes coberturas para os requisitos, de acordo com sua importância: Requisitos com baixa prioridade: testar somente os casos de teste relacionados aos riscos, se houver tempo disponível; Requisitos com média prioridade: testar os casos de teste relacionados aos riscos, testar o cenário do fluxo principal e testar possíveis fluxos alterados ou incluídos durante a iteração; Requisitos com alta prioridade: testar os casos de teste relacionados aos riscos e todos os fluxos do requisito (principal, exceção e alternativo). Um exemplo de caso de teste criado com base na identificação e análise dos riscos para os dados apresentados na Figura 4.10, seria criar um caso de teste para a funcionalidade Group Tasks, incluindo e alterando Group Tasks to tipo Custom, já que este foi identificado como um requisito incompleto ou mal especificado. 64

80 Figura 4.10 Questionário baseado em taxonomia para a funcionalidade Group Tasks. Especificar Caso de Teste e Descrever Procedimento de Teste Os casos de teste que foram identificados são agora detalhados seguindo as estratégias definidas. Para cada risco identificado, testes são criados com o propósito de mitigar os fatores de riscos. O estilo de criação dos casos de teste para execução recomendado pelo processo é o independente, de forma que estes possam ser executados em qualquer ordem. Criar Pacotes de Execução Criar pacotes para a execução contendo os casos de teste baseado em riscos, ordenados de acordo com a priorização realizada na atividade Analisar Riscos Executar Testes Esta é a atividade em que, de fato, os riscos são mitigados através da execução de casos de teste baseado em riscos. Tem como objetivo executar testes e verificar a corretude do software, avaliando os resultados e registrando os problemas encontrados. O Testador é responsável por esta atividade e executa os testes na ordem de priorização definida pelo Projetista de Teste. A Figura 4.11 apresenta as atividades, responsáveis e principais artefatos produzidos e/ou consumidos. Figura 4.11 RBTProcess: Disciplina Executar Testes. 65

81 Configurar Ambiente de Teste Antes do início da execução dos casos teste, deve-se configurar o ambiente para a realização dos testes que podem necessitar, dentre outros recursos, de ferramentas específicas e de base de dados de teste. Executar Testes e Reportar Resultados A principal entrada para esta atividade é a planilha de execução criada pelo Projetista de Testes. Ao executar os testes, o testador gera os logs com o resultado, como evidência das execuções e, quando falhas são encontradas, solicitações de mudanças são criadas. Quando um caso de teste é executado e não apresenta nenhuma falha, para a abordagem RBT significa que o risco associado ao requisito foi mitigado. Similarmente, um risco é mitigado quando um caso de teste falha e o defeito encontrado é corrigido e validado Avaliar Testes Tem como objetivo medir quantitativa e qualitativamente o progresso dos testes e produzir um relatório de avaliação. O Projetista de Testes avalia o resultado da execução dos casos de teste sem se preocupar com os riscos que foram mitigados. Esta atividade não sofre alterações para o processo de teste baseado em riscos, uma vez que todo o controle a acompanhamento dos riscos foi definido na disciplina Controlar Riscos, sob a responsabilidade do Analista de Riscos. A Figura 4.12 apresenta as atividades, responsáveis e principais artefatos produzidos e/ou consumidos. Figura 4.12 RBTProcess: Disciplina Avaliar Testes. Avaliar Estratégias Nesta atividade, o Projetista de Testes, de acordo com os resultados, verifica se as abordagens utilizadas foram satisfatórias. 66

82 Avaliar Cobertura O projetista verifica se os casos de teste executados e seus respectivos resultados alcançaram a cobertura determinada no plano de teste. Avaliar Resultado Geral O Projetista de testes avalia os resultados gerados na atividade Executar Testes e cria o relatório de resultado dos testes com número de casos de teste planejados, executados e seus resultados. Além disso, o projetista avalia as estratégias utilizadas e a cobertura dos casos de testes Controlar Riscos Essa disciplina é responsável pelo acompanhamento dos riscos identificados. O Analista de Riscos é responsável pela identificação e documentação do percentual de riscos mitigados por funcionalidade. Além da criação do Relatório de Avaliação dos Riscos, o Analista é responsável pela atualização do Documento de Identificação e Análise dos riscos, principal entrada para a atividade de planejamento dos testes. O principal artefato de entrada para esta atividade é o Relatório de Avaliação dos Testes. A Figura 4.13 apresenta as atividades, responsáveis e principais artefatos produzidos e/ou consumidos. Figura 4.13 RBTProcess: Disciplina Controlar Riscos. Identificar Riscos Mitigados Através do relatório de resultado dos testes e das solicitações de mudanças criadas, o Analista de Riscos identifica os riscos mitigados e atualiza o documento de riscos. Além disso, o 67

83 analista gera um relatório informando todos os riscos mitigados ou o percentual de mitigação, criando uma nova lista de priorização dos riscos. Avaliar Status dos Riscos e Avaliar Resultado Geral dos Riscos O Analista de Riscos acompanha a evolução e os status dos riscos, reportando o resultado e atualizando a lista de priorização a cada iteração. 4.4 Relacionamento dos Artefatos Os artefatos com borda pontilhada na Figura 4.14 são originados do processo de teste baseado em riscos. Os artefatos com sombra fazem parte de processos de teste de software [IEEE ]. Os demais são alguns dos artefatos criados durante o processo de desenvolvimento de software, de uma forma geral. Os documentos de identificação e análise dos riscos são criados pelo Analista de Riscos na fase de planejamento e atualizados após a execução dos testes, na fase de controle. O plano de teste é criado, pelo Gerente, levando em consideração os riscos identificados e analisados e o cronograma do projeto. Os procedimentos de teste contêm os passos necessários para verificar a existência dos riscos identificados. Os testes são executados na ordem em que aparecem na planilha de execução, ou seja, na ordem de prioridade dos requisitos. Solicitações de mudanças são criadas para os defeitos encontrados que, quando corrigidos, mitigam os riscos associados. 4.5 Métricas As métricas possibilitam quantificar características do processo ou do software e apóiam atividades importantes do gerenciamento de projeto como planejamento, organização, controle e melhorias [SMG 2001]. Assim, métricas para teste de software servem como indicadores para o progresso das atividades de teste e podem também ser utilizadas para melhorar práticas e atividades. Nesta Seção, são apresentadas métricas para acompanhamento do progresso, esforço, custo, estabilidade, qualidade e outras categorias do teste baseado em riscos utilizadas nas atividades Avaliar Testes e Controlar Riscos do RBTProcess. As métricas estão divididas em duas categorias: 68

84 Métricas para controle e medição dos casos de teste baseado em riscos, apresentadas na Seção Métricas para controle e medição das atividades do processo de teste de software baseado em riscos, apresentadas na Seção Figura 4.14 RBTProcess: Relacionamento dos artefatos. A abordagem Goal Question Metric (GQM), desenvolvida por Victor Basili [GQM 2008], foi utilizada para definição das métricas propostas no RBTProcess. GQM define um modelo de medição em três níveis como apresentado na Figura Nível Conceitual Business Goals Measurement Goals Quais são os objetivos do negócio? O que é necessário para atingir esses objetivos? Nível Operacional Question Que questões ajudam no planejamento e controle do progresso para alcançar estes objetivos Nível Quantitativo Metric Figura 4.15 Níveis do GQM [GQM 2008]. Que medidas/métricas são necessárias para responder estas perguntas? 69

85 No nível conceitual estão os objetivos da medição que são definidos em termos da entidade, propósito, atributos de qualidade, ponto de vista e ambiente. No nível operacional, cada objetivo é refinado em um conjunto de perguntas que representam uma definição operacional desse objetivo. No nível quantitativo, para cada pergunta, métricas relevantes são definidas Métricas para Controle e Medição de Casos de Teste baseado em Riscos Para cada requisito ou funcionalidade do produto de software, riscos são identificados e analisados. Depois, casos de teste são projetados para avaliar as ocorrências dos fatores de riscos. Quando estes casos de teste são executados e falhas são observadas, os testadores reportam o defeito para que possa ser corrigido e o risco, relacionado a esse caso de teste, mitigado. Amland [Amland 1999] propõe algumas métricas para o teste baseado em riscos em seu estudo de caso de uma instituição financeira, como: número de testes planejados, executados e completos; número de defeitos por função; número de horas utilizadas para se testar por defeito encontrado; número de horas para corrigir um defeito, dentre outras. Além disso, Konda [Konda 2008] apresenta um conjunto de métricas com o objetivo de medir precisamente a remoção de defeitos que também pode ser aplicado ao teste baseado em riscos. A Tabela 4.5 enumera métricas recomendadas para o controle e medição de casos de teste baseado em riscos. A linha Gn contém o objetivo da medição, que é a informação que nós queremos adquirir. A linha Qn.m é a pergunta que nos ajuda a planejar, controlar e medir o progresso dos objetivos. Finalmente, Mn.m é a métrica que temos que coletar para responder às questões. Exemplos de utilização das métricas são fornecidos na Seção Métricas para Controle e Medição das Atividades do Processo de Teste de Software baseado em Riscos Esta Seção apresenta métricas que podem ser utilizadas para monitorar a situação (progresso) das atividades de teste de software baseado em riscos. Elas são utilizadas principalmente para encontrar gargalos e/ou problemas e melhorar as atividades. Estão enumeradas na Tabela

86 Tabela 4.5. Métrica para casos de teste baseado em riscos. G1. Verificar se um nível aceitável de mitigação dos riscos foi atingido. Verificar se um nível aceitável de mitigação dos riscos por funcionalidade ou requisito foi atingido. Q1.1. Quantos riscos foram mitigados? M *(Número de casos de Teste baseado em Riscos que Q1.2. Quantos riscos foram mitigados por requisito ou funcionalidade? Q1.3 Quantos riscos foram mitigados por importância? passaram/ Número de casos de Teste baseado em Riscos planejados) M *(Número de casos de Teste baseado em Riscos que passaram por requisito/número de casos de Teste baseado em Riscos planejados por requisito) M *(Número de casos de Teste baseado em Riscos que passaram por importância/número de casos de Teste baseado em Riscos planejados por importância) G2. Verificar os requisitos mais importantes ou prioritários. Um intervalo pode ser definido a partir do valor de exposição ao risco para identificar requisitos com alta, média ou baixa prioridade. Q2.1. Qual o percentual de requisitos M *(Número de requisitos com exposição ao risco alta/ com prioridade alta? Número de requisitos) G3. Saber quais as categorias de riscos que apresentam o maior número de riscos. Alguns exemplos de categorias apresentadas pelo SEI para requisitos são: estabilidade, completude e claridade e outras. Q3.1. Qual o percentual de riscos M *(Número de riscos por categoria/número total de riscos) identificados por categoria? G4. Verificar o quanto que os riscos estão diminuindo a cada iteração ou ciclo de teste. Q4.1. Quantos riscos foram encontrados M *Número de riscos identificados/número de reuniões por reunião e questionário baseado em taxonomia? G5. Verificar se o nível de redução está adequado e se justifica o uso da técnica. Caso contrário, outras técnicas mais efetivas devem ser utilizadas. Q5.1. O custo da técnica de redução está M5.1 (Cálculo de exposição riscos antes da redução - Cálculo de de acordo com o valor de limite? exposição riscos após da redução)/custo da redução do risco. G6. Obter informações necessárias para o planejamento de esforços. Bastante útil, uma vez que os funcionários são pagos por hora. Q6.1. Quanto tempo foi gasto para identificar riscos M6.1 Tempo gasto para responder o TQB/Número de utilizando o TBQ por funcionalidade? requisitos Q6.2. Quanto tempo foi gasto para identificar riscos na M6.2. Duração da reunião/número de requisitos reunião de brainstorm por funcionalidade? Q6.3. Quanto tempo foi gasto para analisar riscos por M6.3. Tempo gasto para analisar riscos/número de funcionalidade? requisitos G7. Obter indicativos de qualidade do Teste baseado em Riscos. Q7.1. Qual a quantidade de defeitos encontrados por M7.1 Número de defeitos por severidade/número total severidade? de defeitos G8. Obter informações sobre a eficiência do Teste baseado em Riscos. Q8.1. Qual percentual de defeitos encontrados com M *(Número de casos de teste que falham Teste baseado em Riscos? (porque um defeito foi encontrado)/número de casos Q8.2. Quantas solicitações de mudança são criadas por requisito / riscos? de teste executado) M8.2. Número de solicitações de mudança/número de requisitos Número de solicitações de mudança/número de riscos G9. Obter informações sobre defeitos que não foram capturados com Teste baseado em Riscos. Q9.1. Quantos defeitos foram encontrados por M9.1 Número de solicitações de mudança criadas pelo cliente/usuário utilizando teste baseado em riscos? cliente/usuário por severidade G10. Obter informações do tempo requerido para encontrar um defeito com casos de Teste baseado em Riscos. Q10.1. Qual o tempo gasto para encontrar um defeito M10.1 Total de horas gasta na execução/número de utilizando casos de Teste baseado em Riscos? defeitos encontrados durante esse período. 71

87 Tabela 4.6 Métricas para atividade de teste baseado em riscos. G1. Obter o tempo médio gasto para identificar e analisar riscos por requisito (número de linhas). Q1.1. Qual o tempo médio gasto para analisar M1.1 (Soma (duração da análise de riscos de um riscos por linha de requisito? requisito/número linhas do requisito))/ Número de requisitos Q1.2. Qual o tempo médio gasto para M1.1 (Soma (duração da identificação de riscos de um identificar riscos por linha de requisito? requisito/número linhas do requisito))/número de requisitos G2. Obter Informações de produtividade das reuniões de identificação de riscos. Q2.1. Quantos riscos são encontrados por M2.1 Número de riscos/número de reuniões reunião? Q2.2. Quantos riscos são encontrados por M2.2 (Número de riscos/número de reuniões)/número de reunião por funcionário? funcionários G3. Como saber se os riscos identificados no TQB são úteis para o Teste baseado em Riscos ou pertinentes para o domínio do produto de software. Se uma quantidade grande de riscos está sendo descartada, significa que a identificação está muito abrangente e que ela precisa focar mais nos cenários do projeto para que os riscos relevantes sejam encontrados de forma mais rápida Também, se um número grande de riscos é descartado, pode indicar que os requisitos estão confusos, ambíguos ou com informações desnecessárias. Se certo tipo de risco é sempre descartado, este não deve ser identificado. Q3.1. Quantos riscos foram descartados durante a M3.1 Número de riscos descartados/número total de reunião de brainstorm? Q3.2. Quantos riscos foram descartados durante a reunião de brainstorm por tipo? riscos M3.2 Número de riscos descartados/número total de riscos por tipo G4. Obter Informações sobre a eficiência do cálculo de exposição ao risco. Se muitos requisitos compartilham o mesmo valor de exposição ao risco, a abordagem RBT fica sem sentido já que os requisitos não são priorizados adequadamente. Neste caso, uma métrica diferente deve utilizada para calcular a exposição ao risco. Q4.1. Qual o percentual de casos de teste que compartilham o mesmo valor de exposição aos riscos (RE)? M *(Número de casos de teste com o mesmo valor de RE/Número total de casos de teste) G5. Avaliar se os riscos identificados são úteis para criação dos casos de testes. Q5.1.Qual o percentual de casos de teste que foram M *(Número de riscos utilizados para projetar projetados com os riscos identificados? casos de teste/número de riscos identificados 4.6 Avaliação do Modelo de Processo O RBTProcess foi avaliado através de simulações de uso do processo e estudo de caso. A simulação consiste na execução das atividades do RBTProcess e na produção dos artefatos com dados de projetos de desenvolvimento de software já concluídos ou fictícios. Quatro simulações foram realizadas com o objetivo de validar e ajustar atividades, artefatos, papéis, guias e métricas do processo e também coletar o tempo gasto para as atividades de identificação e análise dos riscos técnicos associados aos requisitos. O estudo de caso foi realizado com o objetivo de avaliar a hipótese de que o teste baseado em risco, através do RBTProcess, encontra os defeitos de forma mais rápida do que outros tipos de teste apresentados no Capítulo 2. 72

88 4.6.1 Simulações Realizadas pela Autora Foram utilizados documentos de dois projetos de manutenção evolutiva de uma grande empresa de informática que possui equipe de teste independente. Cada projeto é responsável pela manutenção de um módulo do mesmo software. Para a simulação, foram necessários os documentos de requisitos do sistema, o plano do projeto e o número de defeitos encontrados nas últimas duas versões do software, com o intuito de avaliar a estabilidade e qualidade das funcionalidades. O primeiro projeto contém o módulo formado por aproximadamente vinte requisitos, enquanto que o segundo contém o módulo formando por apenas seis requisitos. A simulação foi realizada somente pela autora e os projetos de manutenções evolutivas já haviam sido concluídos. Resultados Obtidos A atividade de identificação dos riscos se mostrou totalmente viável para o segundo projeto, enquanto que, para o primeiro, se mostrou um gargalo, preenchendo a maior parte do tempo, pois foi necessária a releitura de todos os documentos de requisito para responder, com mais confiança, o questionário baseado em taxonomia de riscos. Isso reforça a necessidade de automação desta atividade, principalmente para grandes projetos. A atividade de análise de riscos foi realizada sem problemas e de forma rápida para ambos os projetos. As métricas de custo foram identificadas a partir do documento de requisitos que continha informações sobre a importância e prioridade do requisito para o cliente. Os valores para as métricas de probabilidade (nova funcionalidade, tamanho e complexidade) foram extraídas do plano de projeto que informava se a funcionalidade a ser desenvolvida era nova, seu tamanho e esforço. A empresa realiza análise por ponto de função, que pode ser utilizada para determinar a complexidade e o tamanho das funcionalidades. A métrica Projeto/Qualidade (Tabela 3.5) foi definida de acordo com o número de falhas encontradas por requisito nas duas últimas versões do software. Em projetos de manutenção evolutiva, as empresas, sempre que possível, testam, primeiramente, as funcionalidades incluídas e alteradas e, quando há tempo disponível, realizam testes de regressão nas demais funcionalidades. Ao concluir esta atividade, foi identificado que a fórmula proposta por Amland [Amland 1999] e explicada na Seção não se adéqua a este cenário. Quando uma funcionalidade é nova, se os valores de custo para o cliente e o vendedor, ou seja, o impacto desta funcionalidade for baixa, esta, muito possivelmente, não será testada no RBTProcess, pois o seu cálculo de exposição ao risco 73

89 resultará em um valor muito baixo. Além disso, esta fórmula não considera o impacto de alterações em uma funcionalidade nas demais. Como exemplo, tivemos uma funcionalidade que sofreu alteração e foi classificada como de baixa prioridade, porém uma falha nessa funcionalidade impediria o usuário de realizar, pelo menos, cinqüenta por cento das operações disponíveis pelo software. Para resolver este problema, o RBTProcess sugere que, para os casos em que o desenvolvimento é de manutenções corretivas ou evolutivas, os fluxos ou cenários do requisitos que foram incluídos ou alterados devem ser testados nas primeiras iterações, independente do resultado da análise dos riscos. Também, uma nova métrica foi proposta para tratar do problema de dependência entre as funcionalidades. A atividade de planejamento dos testes foi realizada seguindo as definições propostas no processo e explicadas na Seção Os requisitos a serem testados são os que foram classificados como de alta e média prioridade. Os requisitos classificados como de baixa prioridade não fizeram parte do planejamento. Foi também elaborado um cronograma tomando como base a análise dos riscos. Na atividade de projeto de teste, foram identificados os testes apenas para a primeira iteração definida no plano de testes. A estratégia para identificação dos testes utilizada foi a descrita na Seção e resultou num conjunto menor de casos de teste. Os riscos identificados no questionário baseado em taxonomia não foram muito úteis para a criação dos casos de teste. Para alguns riscos, ficou difícil imaginar cenários que garantissem a mitigação dos mesmos. Como possível solução, o questionário baseado em taxonomia de riscos foi revisado e algumas perguntas foram excluídas. A atividade de execução dos testes não foi realizada, pois não foram criados os procedimentos de teste. Para simulação das atividades de avaliação e controle dos testes foram utilizados dados fictícios e foi percebido que o documento de identificação e análise dos riscos não guardava o histórico dos riscos mitigados na iteração anterior, uma informação importante para avaliar a qualidade e evolução do software. Considerações e Dificuldades Encontradas Além dos problemas relatados em cada um dos conjuntos de trabalho, não foi possível avaliar o impacto das atividades durante o desenvolvimento das funcionalidades - onde os requisitos podem sofrer mudanças - pois ambas as simulações foram realizadas com projetos já concluídos. Também, como a simulação foi realizada pela autora, que tem todas as atividades 74

90 do processo em mente, não foi possível afirmar a qualidade dos artefatos e a descrição do processo. Concluímos que, antes de partir para um estudo de caso, onde seriam avaliados, por exemplo, tempo de realização das atividades e qualidade do produto final, se faz necessária a simulação do processo por outra pessoa, que não a autora. Também, é importante validar o processo para projetos de desenvolvimento de software em andamento Simulações Realizadas por Engenheiro de Teste com Experiência em Teste de Software A versão utilizada nesta simulação inclui a correção dos problemas identificados na simulação realizada pela autora. As características desta simulação foram similares às da simulação realizada pela autora. O engenheiro de teste utilizou os documentos do módulo formado por aproximadamente vinte requisitos. O processo foi instanciado e o engenheiro dividiu a execução do processo em duas iterações: (i) a primeira contendo os requisitos novos ou alterados e a (ii) segunda contendo os requisitos que não sofreram alterações, com o intuito de realizar testes de regressão. A simulação também foi realizada quando o projeto de manutenção evolutiva já havia sido concluído. Resultados Obtidos O engenheiro de teste apresentou dificuldades já no momento da instanciação do modelo de processo, pois ele não sabia de onde extrair, nos documentos do software, as informações necessárias para a identificação e análise dos riscos, indicando a necessidade de um guia para instanciação do RBTProcess. O engenheiro precisou estudar todos os documentos de requisitos e regras de negócio do sistema para conhecer as funcionalidades, o que tomou um tempo considerável. Diante dessa situação, o engenheiro sugeriu que as atividades de identificação e análise ocorressem imediatamente após a revisão dos requisitos a serem desenvolvidos, mantidos ou evoluídos, pois os participantes estão com praticamente todas as informações das funcionalidades em mente. Com relação ao questionário baseado em taxonomia fornecido pelo processo, o engenheiro identificou que algumas perguntas não estavam claras e necessitavam ser revisadas. Além disso, sugeriu a remoção de questões que aparentemente estavam repetidas e questões que necessitavam da participação do cliente, por não serem viáveis para a maioria 75

91 dos projetos. Ele apresentou dificuldade para responder as questões não objetivas do questionário, entretanto, estas foram essenciais para a etapa de criação dos casos de teste. Com relação à análise dos riscos, para a primeira iteração, a métrica de nova funcionalidade apresentou um único valor para todos os requisitos, indicando necessidade de revisão do guia. Considerações e Dificuldades Encontradas Apesar de o engenheiro de testes não ter tido tempo para simular as atividades do processo de teste de software, suas considerações se transformaram em melhorias no questionário baseado em taxonomia, nas métricas de análise dos riscos, na forma e momento de execução das atividades de identificação e análise e na criação de guia para instanciação do modelo de processo. Também não foi possível avaliar o impacto das atividades durante o desenvolvimento das funcionalidades ou requisitos Simulações Realizadas para Avaliar Métricas e Coletar Tempo de Atividades de Identificação e Análise de Riscos A versão utilizada nesta simulação inclui a correção dos problemas identificados na simulação realizada pela autora e pelo engenheiro de testes. Esta simulação foi realizada com o propósito de avaliar as métricas propostas no processo e coletar os tempos para identificação e análise dos riscos. Três estudantes do curso de Engenharia da Computação, com conhecimentos básicos de teste de software participaram como voluntários, realizando as atividades do modelo de processo e coletando o tempo gasto em cada uma delas. Eles receberam treinamento do RBTProcess e tiveram um tempo para ler o documento de requisitos do software, o plano de projeto fictício e o histórico de defeitos reportados por funcionalidade, também fictícios. O documento de requisitos utilizado foi o do sistema Health-Watcher, definido por [Soares 2002], que é um sistema de informações disponibilizado via web que oferece aos usuários serviços relacionados ao sistema público de saúde, como o suporte ao registro de reclamações e guia de saúde para o usuário. O documento contém nove requisitos funcionais e nove requisitos não funcionais. Para esta simulação foram utilizados os requisitos funcionais. 76

92 Resultados Obtidos Para a identificação dos riscos, foi utilizado um questionário baseado em taxonomia de riscos com oito perguntas relacionadas a quatro categorias de riscos de requisito. A Tabela 4.7 apresenta os valores de algumas métricas que podem ser obtidos com a realização desta atividade. A métrica M3.1 indica que 45% dos riscos identificados referem-se à estabilidade do sistema. M1.1 indica que os voluntários gastaram 6.35 minutos para identificar riscos de requisitos com, aproximadamente, quarenta linhas. Vinte e quatro riscos foram identificados na reunião de brainstorm (M2.1) e oito riscos foram identificados por participante (M2.2). Tabela 4.7 Métricas da atividade de identificação de riscos. CASOS DE TESTE BASEADO EM RISCOS M3.1 Estabilidade: 11 / 24 = 45% Completude: 7 / 24 = 29% Claridade: 3 / 24 = 12% Validade: 3 / 24 = 12% ATIVIDADES DO TESTE BASEADO EM RISCOS M minutos por requisito com 40 linhas. M riscos por reunião M / 3 (voluntários) = 8 riscos Para a análise dos riscos, os voluntários forneceram valores para as métricas propostas na equação de Amland [Amland 1999] e adaptada neste processo. A Tabela 4.8 apresenta a exposição ao risco das funcionalidades analisadas. Tabela 4.8 Cálculo de exposição ao risco para o sistema Health-Watcher. REQUISITO/FUNCIONALIDADE EXPOSIÇÃO AO RISCO (RE) PRIORIDADE FR14. Update employee 0.75 Baixa FR13. Register new employee 0.83 Baixa FR10. Login 1.00 Média FR16. Change logged employee 1.00 Média FR11. Register tables 1.07 Média FR02. Specify complaint 1.13 Média FR12. Update complaint 1.13 Média FR15. Update health unit 1.19 Alta FR01. Query information 1.40 Alta A Tabela 4.9 apresenta os valores de algumas métricas obtidos com a realização desta atividade. A métrica M6.3 indica que os voluntários gastaram menos que 2.5 minutos para analisar cada funcionalidade. A métrica M4.1 indica um percentual baixo de funcionalidades com o mesmo valor de exposição ao risco (RE), indicando que a análise realizada é suficiente para priorização das funcionalidades. Tabela 4.9 Métricas da atividade de análise de riscos. CASOS DE TESTE BASEADO EM RISCOS M6.3 < 2.5 minutos por requisito ATIVIDADES DO TESTE BASEADO EM RISCOS M4.1 2 / 9 = 22 % 77

93 As informações resultantes destas atividades são os principais insumos para o planejamento dos testes. A definição de prioridade para as funcionalidades auxilia o Gerente de Testes a decidir quando, quais e como as funcionalidades serão testadas. A Tabela 4.10 apresenta os resultados para o projeto de casos de teste funcionais e baseado em riscos, utilizando a estratégia proposta pelo RBTProcess na Seção e assumindo que: Para cada risco identificado, um caso de teste baseado em riscos foi projetado; Para cada um dos requisitos foi criado um teste funcional para o fluxo principal; Para requisitos com baixa prioridade, foram executados apenas casos de teste baseado em riscos; FUNC. PRIORIDADE NÚMERO DE FLUXOS Tabela 4.10 Número de casos de teste por funcionalidade. NÚMERO DE CASOS DE TESTE BASEADO EM RISCOS NÚMERO DE CASOS DE TESTE PROPOSTOS PELO RBTProcess FR01 Alta (fluxo) + 1 (risco) = 6 FR15 Alta (fluxo) + 1 (risco) = 7 FR02 Média 6 5 1(fluxo principal) + 5 (riscos) = 6 FR12 Média 6 4 1(fluxo principal) + 4 (riscos) = 5 FR11 Média 1 4 1(fluxo principal) + 4 (riscos) = 5 FR10 Média 5 4 1(fluxo principal) + 4 (riscos) = 5 FR16 Média 1 3 1(fluxo principal) + 3 (riscos) = 4 FR13 Baixa (riscos) FR14 Baixa (riscos) TOTAL As Tabelas 4.11 e 4.12 apresentam valores fictícios para exemplificar o uso das métricas extraídas das atividades de execução de casos de teste e controle dos riscos. As métricas M1.1 e M1.2 apresentam o percentual de execução dos casos de teste baseado em riscos. A métrica M7.1 indica um número alto de defeitos com severidade muito alta. M8.1 indica a efetividade dos testes baseado em riscos e M8.2 a concentração dos defeitos reportados. Tabela 4.11 Resultado da execução dos casos teste baseado em riscos. FUNC. NÚM. DE CASOS DE TESTE BASEADO EM RISCOS NÚM. DE CASOS DE TESTE BASEADO EM NÚM. DE CASOS DE TESTE QUE PASSARAM NÚM. DE DEFEITOS ENCONTRADOS PLANEJADOS RISCOS EXECUTADOS FR FR FR FR FR FR FR FR TOTAL

94 Resultados Obtidos Tabela 4.12 Métricas da atividade de análise de riscos. CASOS DE TESTE BASEADO EM RISCOS M / 24 = 45 % Executado M1.2 FR % Executado FR % Executado M7.1 Severidade: Muito Alta. 40%, Alta. 20%, Média. 10% Baixa. 25%, Muito Baixa. 5 % M / 11 = 54 % M8.2 FR % FR % FR % FR % A grande maioria das métricas propostas pôde ser validada com a simulação realizada. Os tempos coletados para atividades de identificação e análise foram relativamente baixos, como já era esperado, indicando a viabilidade do uso do RBTProcess. A métrica de número de casos de teste não foi considerada uma boa métrica, pois este número dependente da forma de escrita dos casos de teste, ou seja, pode-se escrever um caso de teste que cubra unicamente um cenário, assim como se pode escrever um caso de teste que cobre mais de um cenário. Para o teste baseado em risco, a métrica que coleta o número de defeitos encontrados num determinado tempo aplica-se melhor, pois a idéia da abordagem é explorar, primeiro, as funcionalidades mais críticas, com o objetivo de encontrar defeitos, com maior severidade, mais cedo Estudo de Caso A versão do RBTProcess utilizada neste estudo de caso contém a correção dos problemas identificados durante as quatro simulações apresentadas anteriormente. A Figura 4.16 apresenta uma visão geral dos passos executados para a realização do estudo de caso. Passo 1: toda equipe do experimento participou de treinamentos sobre conceitos básicos de teste de software e sobre o RBTProcess. Após este treinamento, o Gerente de Teste, juntamente com o Gerente de Projeto da equipe da ferramenta em teste (MPhyScas) fizeram a instanciação do processo, criaram o questionário baseado em taxonomia de riscos e definiram os papéis da equipe. 79

95 (1) Treinamento sobre conceitos básicos de teste e RBTProcess (2) Treinamento da ferramenta MPhyScas (3) Identificação de Riscos (5) Planejamento dos Testes (4) Análise dos Riscos (6) Projeto dos Testes Casos de Teste Não baseado em Riscos Casos de Teste baseado em Riscos (7) Cycle 1 Execução dos Testes Baseado Em Riscos Cycle 2 Não baseado em Riscos Abordagem Híbrida Não baseado em Riscos Abordagem Híbrida Baseado Em Riscos (8) Avaliação dos Testes e Controle dos Riscos Figura 4.16 Visão geral do fluxo de execução do estudo de caso. Passo 2: a equipe de teste particiou de um treinamento sobre a ferramenta MPhyScas, que será explicada a seguir. Passo 3: após a reunião de validação dos requisitos a serem desenvolvidos, a equipe MPhyScas executou a atividade de identificação de riscos do RBTProcess. Ao final, o Analista de Riscos sumarizou os dados de todos os participantes, removendo insconsistênias e produzindo o documento de identificação de riscos. Passo 4: após a identificação dos riscos, a equipe da ferramenta MPhyScas forneceu valores para as métricas apresentadas na Seção 4.3.2, com o objetivo de definir o valor do cálculo de exposição ao risco para cada uma das funcionalidades. Passo 5: a partir do valor de exposição ao risco, o Gerente de Teste definiu a quantidade de casos teste necessária para mitigar os riscos identificados, bem como a ordem e a suíte de execução dos testes. Passo 6: dois tipos de casos de teste foram projetados neste estudo de caso: 80

96 o Teste baseado em riscos: o Projetista de Teste projetou casos de teste baseado em riscos para cada um dos riscos identificados, de acordo com o que foi apresentado na Seção o Teste não baseado em riscos: um membro da equipe da ferramenta MPhyScas, com treinamento intermediário sobre teste de software, projetou um caso de teste para cada uma das funcionalidade da ferramenta. Passo 7: na execução, foram definidos dois ciclos de execução e três grupos de testadores que executaram abordagens diferentes de teste em cada um dos ciclos. Três abordagens de execução foram definidas: o Abordagem baseada em risco (Riscos): casos de teste baseado em riscos foram executados na ordem do valor do cálculo de exposição ao risco, seguindo as atividades do RBTProcess. o Abordagem não baseada em risco (Funcional): casos de teste funcional foram executados na ordem de utilização do software definida pelo usuário. o Abordagem híbrida (Funcional RE): casos de teste funcionais foram executados na ordem do valor do cálculo de exposição ao risco. Passo 8: depois da execução dos casos de teste, os Analista de Riscos e o Gerente de Projeto analisaram os resultados, removendo inconsistências, defeitos dulicados e falso defeitos, sumarizando o resultado. Nas subseções a seguir, são fornecidas as características e os resultados obtidos com a execução do estudo de caso, de forma detalhada. Característica O RBTProcess foi aplicado no desenvolvimento da ferramenta Multi-Physics and Multi- Scales Solver Environment (MPhyScaS), que é um ambiente para o desenvolvimento automático de simuladores multi-físicos baseados no Método do Elemento Finito (FEM) [MPhyScas 2007]. A ferramenta MPhyScas tem como motivação: Potencializar o reuso de algoritmos e componentes de software em geral já implementados e validados. Manter componentes de software em uma base de dados única para fácil localização. Automatizar tarefas repetitivas na construção de simuladores. A ferramenta MPhyScaS está sendo desenvolvida pelo Departamento de Sistema e Computação da Universidade de Pernambuco (UPE), em parceria com o Departamento de 81

97 Engenharia Mecânica da Universidade Federal de Pernambuco (UFPE) com o apoio do Finep, Cenpes/Petrobras e CNPq. A equipe conta com sete pessoas, duas contratadas recentemente, trabalhando no desenvolvimento da ferramenta. O objetivo deste estudo de caso foi avaliar a hipótese de que a abordagem de teste baseado em risco, definida no RBTProcess, encontra mais rapidamente os defeitos mais importantes. Para isto, o processo foi instanciado para a realidade do projeto e voluntários participaram da atividade de execução dos testes, realizando três diferentes abordagens de teste, apresentadas na Figura A ferramenta MPhyScas está dividida em quatro módulos: (i) repositório de componentes de software científicos; (ii) interface para modelagem e geração de simuladores; (iii) interface para entrada de dados e execução de simulação; (iv) framework de simulação. O módulo de interface para modelagem e geração de simuladores foi testado através do RBTProcess. Os papéis definidos e utilizados no RBTProcess foram organizados da seguinte forma: Analista de Riscos: autora. Gerente de Teste: autora. Projetista de Teste: autora e um membro da equipe MPhyScaS. Testadores: cinco voluntários, estudantes do curso de Engenharia da Computação Gerente de Projeto: membro da equipe MPhyScaS. Analista de Sistema: quatro membros da equipe MPhyScaS. Um dos membros da equipe não participou, pois havia integrado o grupo há pouco tempo. Analista de Requisito: este e outros papéis não existem na equipe MPhyScaS, pois todos realizam todas as etapas de desenvolvimento, inclusive a de teste. A Tabela 4.13 apresenta as atividades necessárias para a realização do estudo de caso, destacando os participantes e o momento em que cada uma delas foi executada. Ao final de cada atividade, os participantes responderam questionários, informando as dificuldades encontradas e oportunidades de melhoria. Os participantes receberam treinamento sobre os conceitos básicos de teste de software, sobre o RBTProcess e sobre a ferramenta MPhyScaS. A Tabela 4.14 apresenta as atividades do RBTProcess realizadas no estudo de caso com seus respectivos responsáveis e participantes. A equipe MPhyScaS participou das atividades de identificação e análise dos riscos, que não levaram mais que duas horas para serem concluídas. A reunião de Brainstorm não foi realizada, por falta de tempo e as dúvidas e conflitos resultantes da identificação foram resolvidos pelo Gerente de Projeto da equipe. 82

98 As atividades do processo de teste foram realizadas pela autora, por falta de recurso humano, com exceção da atividade de execução dos testes, que foi realizada pelos voluntários e a atividade de projeto dos casos de teste funcionais que foi realizada por um membro da equipe MPhyScaS. Tabela 4.13 Atividades de preparação para realização do estudo de caso. ATIVIDADES RESPON- PARTICI- OBSERVAÇÕES SÁVEL PANTES Treinamento RBT Process Apresentar RBTProcess Gerente de Teste Duração de 1 hora Ocorreu antes do início da Apresentar página do RBTProcess iteração Instanciação do Modelo de Processo Treinamento sobre o MPhyScaS Treinamento Teste de Software Definir atividades, artefatos e papéis do processo Identificar recursos necessários Registro de resultado dos testes Registro de Solicitações de mudança Apresentação dos templates Analista de Riscos Gerente do Projeto Gerente de Testes Gerente do Projeto, Analista de Sistemas, Gerente de Testes, Projetista de Testes, Testadores Gerente do Projeto Com exceção do Gerente, a equipe MPhyScaS não pôde participar desta atividade, por conta da incompatibilidade de horários. Duração de 2 horas Ocorreu durante o planejamento da iteração Analista de Riscos, Gerente de Testes, Projetista de Testes, Testadores Duração de 1 hora Testadores Duração 1 hora ATIVIDADES Atividade Identificar Riscos Revisar Fontes e Categoria dos Riscos Responder Questionário Tabela 4.14 Atividades do RBTProcess. RESPON- PARTICI- OBSERVAÇÕES SÁVEL PANTES Analista de Gerente do Duração de 1h Riscos Projeto Analista de Riscos Gerente do Projeto, Analista de Sistemas, Gerente de Testes, Projetista de Testes, Questionário foi adaptado para o projeto de acordo com as funcionalidades a serem testadas Durou menos que uma hora por pessoas Não ocorreu após a reunião de revisão O questionário foi respondido no final do desenvolvimento Apenas equipe MPhyScaS 83

99 Atividade Analisar Riscos Atividade Planejar Testes Atividade Projetar Testes Atividade Executar Testes Atividade Avaliar Testes Atividade Controlar Riscos Realizar Reunião de Brainstorm Calcular Exposição aos Riscos Priorizar Riscos/Requisitos Executar Testes e Reportar Resultados Avaliar Resultado Geral Avaliar Resultado Geral dos Riscos Analista de Riscos Analista de Riscos Analista de Riscos Gerente de Testes Projetista de Testes Testadores Gerente do Projeto, Analista de Sistemas, Gerente de Testes, Projetista de Testes, Testadores Gerente do Projeto, Analista de Sistemas, Gerente de Testes, Projetista de Testes, Testadores Gerente do Projeto Gerente do Projeto, Gerente de Testes, Analista de Riscos respondeu ao questionário Não houve tempo para realizar essa reunião, pois a equipe estava concluindo o desenvolvimento Analista levou em torno de 2 horas para consolidar os dados e remover ambigüidades com a ajuda do Gerente Durou menos que uma hora por pessoa Apenas equipe MPhyScaS informou valores para as métricas Durou em torno de 2h para consolidar os dados e criar o relatório com as métricas para equipe O tempo desta atividade não foi coletado Não houve tempo para produzir todos os artefatos, pois a ferramenta MPhyScaS necessitava ser entregue aos clientes O tempo desta atividade não foi coletado Um membro da equipe MPhyScaS projetou os casos de teste funcionais Testadores Testadores Os testes foram executados em dois encontros com duração média de 1,5 horas Projetista de Testes Analista de Riscos Cada testador executou duas diferentes abordagens de teste O tempo desta atividade não foi coletado Foi elaborado relatório com o resultado dos testes para cada abordagem O tempo desta atividade não foi coletado Foi atualizado o documento de priorização dos riscos Resultados Obtidos Os resultados apresentados a seguir foram extraídos dos relatórios produzidos para equipe MPhyScaS, para cada atividade do RBTProcess realizada. 84

100 A Tabela 4.15 apresenta os tempos gastos para identificação dos riscos utilizando o questionário baseado em taxonomia. O tempo foi ainda menor que o do sistema Health- Watcher e isso se deve ao fato de que os membros da equipe MPhyScaS têm bastante conhecimento sobre os requisitos, não necessitando a leitura da documentação. Tabela 4.15 Tempo gasto na atividade de identificação de riscos. TEMPO PARA IDENTIFICAR RISCOS POR FUNCIONALIDADE 2.41 Tempo médio gasto para responder todas as perguntas do questionário para uma funcionalidade em minutos TEMPO PARA IDENTIFICAR RISCOS POR PESSOA Tempo médio para responder todas as perguntas do questionário para todas as funcionalidades em minutos 2.41 x 11 (número de funcionalidades) TEMPO TOTAL PARA IDENTIFICAR RISCOS 106 Tempo gasto por todas as pessoas da equipe na identificação de riscos em minutos x 4 (pessoas) As Tabelas 4.16 e 4.17 apresentam, respectivamente, a concentração dos riscos por tipo e por funcionalidade e os tempos gastos para análise dos riscos. Tabela 4.16 Características dos riscos identificados. QUANTIDADE DE RISCOS IDENTIFICADOS 49 Quantidade de riscos identificados por toda equipe QUANTIDADE DE RISCOS DIFERENTES IDENTIFICADOS 30 Quantidade de riscos diferentes identificados por toda equipe (riscos repetidos) QUANTIDADE DE RISCOS DIFERENTES IDENTIFICADOS POR FUNCIONALIDADE 30 Quantidade de riscos diferentes identificados por funcionalidade FUNC01-Simulator Properties 3 FUNC02-Kernel Configuration 3 FUNC03-Global States 0 FUNC04-Blocks 1 FUNC05-Create Group 1 FUNC06-Local States 0 FUNC07-Create Phenomenon 7 FUNC08-Phenomenon-State Relation 1 FUNC09-Quantity Tasks 1 FUNC10-Group Tasks 5 FUNC11-Search 8 QUANTIDADE DE RISCOS IDENTIFICADOS POR PESSOA 7.5 Quantidade de riscos diferentes identificados por toda equipe QUANTIDADE DE RISCOS IDENTIFICADOS POR TIPO 30 Stability 2 Completeness 11 Validity 8 Feasibility 2 Clarity 1 Feasibility 6. É interessante notar que nem sempre as funcionalidades que apresentam mais riscos são as mais importantes, este comportamento foi também observado na simulação com o sistema Health-Watcher. As funcionalidades classificadas como de alta prioridade levam em 85

101 conta o impacto de falhas no software em produção. Assim, apesar de uma funcionalidade ser classificada como muito importante para software ela pode não possui um risco alto, porque está muito bem especificada, com requisito estável ou não vem apresentado falhas durante utilização. Este, de fato, é o objetivo do teste baseado em riscos: identificar funcionalidades que são igualmente importantes e que possuem alta probabilidade de apresentar falhas. Além disto, a análise indicou um problema de completude dos requisitos, que foi, posteriormente, confirmado pela equipe, por conta da ausência de documento de requisitos. O tempo gasto para análise dos riscos foi muito pequeno, confirmando a viabilidade de utilização desta atividade no processo de teste de software. Tabela 4.17 Tempo gasto para análise dos riscos. TEMPO PARA ANALISAR RISCOS POR FUNCIONALIDADE 1.05 Tempo médio gasto para informar valores para as métricas de análise para uma funcionalidade em minutos TEMPO PARA ANALISAR RISCOS POR PESSOA Tempo médio para informar valores para as métricas de análise para todas as funcionalidades em minutos 1.05 x 11 (número de funcionalidades) TEMPO TOTAL PARA ANALISAR 46.2 Tempo gasto por todas as pessoas da equipe na análise de riscos em minutos x 4 (pessoas) A Tabela 4.18 apresenta os valores de exposição ao risco para o sistema MPhyScaS. O planejamento e o projeto seguiram as definições do RBTProcess e foram criados casos de teste para as funcionalidades classificadas com prioridade alta e média. Para as funcionalidades com baixa prioridade, só foram criados casos de teste para as que tiveram algum risco identificado. Os casos de teste baseado em riscos foram executado na ordem de exposição ao risco, do maior para o menor valor. Tabela 4.18 Valores de exposição ao risco das funcionalidades do MPhyScaS. CÁLCULO DE EXPOSIÇÃO AO RISCO FUNC10-Group Tasks 1.74 FUNC02-Kernel Configuration 1.64 FUNC11-Search 1.44 FUNC07-Create Phenomenon 1.21 FUNC04-Blocks 1.10 FUNC05-Create Group 1.10 FUNC03-Global States 1.04 FUNC09-Quantity Tasks 0.84 FUNC08-Phenomenon-State Relation 0.81 FUNC06-Local States 0.75 FUNC01-Simulator Properties

102 A Tabela 4.19 apresenta o resultado da execução dos casos de teste funcionais, casos de teste baseado em riscos e casos de teste funcionais executados seguindo a ordem de exposição ao risco (RE). Foram realizados dois ciclos de execução com duração média de 1,5 horas. Sendo que, para o primeiro ciclo, os testadores gastaram trinta minutos utilizando a ferramenta MPhyScaS e esclarecendo dúvidas. Cada testador executou uma abordagem de teste diferente por ciclo, ou seja, um mesmo testador executou duas abordagens diferentes o que pode ter influenciado no resultado. Entretanto, é sabido que alguns testadores encontram mais defeitos que outros, mesmo quando executando o mesmo conjunto de teste, o que também acaba influenciando o resultado de uma determinada abordagem. Assim, quando um testador executa abordagens diferentes de teste, o resultado fica melhor balanceado. Como exemplo, neste estudo de caso, um testador reportou 8 defeitos, equanto que um outro testador, que executou o mesmo conjunto de casos de teste, reportou apenas 1 defeito. Se o primeiro testador tivesse executado apenas uma abordagem de teste, esta abordagem acabaria tendo um resultado melhor, por conta da habilidade do testeador. Pode-se perceber um número considerável de defeitos encontrados utilizando a abordagem baseada em riscos. Um ponto que merece destaque é que, apenas mudando a ordem de execução, os testes funcionais (RE) encontraram o dobro de defeitos da abordagem Funcional, onde os testes foram executados na ordem de utilização definida pelo usuário. Além disso, a abordagem baseada em riscos encontrou um maior número de defeitos com alta severidade que as demais abordagens. A Tabela 4.20 apresenta a concentração de defeitos por caso de teste executado. A abordagem Funcional concentrou a maioria dos defeitos nos últimos casos de teste, enquanto que nas demais, os defeitos se concentraram nos primeiros casos de teste. É interessante destacar que o caso de teste funcional número 11 explora a mesma funcionalidade do caso de baseado em risco número 1. A Tabela 4.21 complementa a informação da Tabela 4.20, onde a abordagem funcional concentrou a maioria dos defeitos após 30 minutos de execução dos testes. A abordagem baseada em riscos concentrou um maior número de defeitos antes dos 30 minutos de execução. 87

103 Tabela 4.19 Número e severidade dos defeitos encontrados por abordagem. TESTADOR CICLO ABORDAGEM QTD. CASOS DE TESTE QTD. DEFEITOS SEVERI- DADE EXECUTADOS REPORTADOS A M B Testador 1 Ciclo 1 Funcional Testador 3 Ciclo 2 Funcional Testador 4 Ciclo 1 Funcional TOTAL Testador 2 Ciclo 1 Riscos Testador 3 Ciclo 1 Riscos Testador 5 Ciclo 2 Riscos TOTAL Testador 5 Ciclo 1 Funcional (RE) Testador 1 Ciclo 2 Funcional (RE) Testador 4 Ciclo 2 Funcional (RE) TOTAL Tabela 4.20 Concentração dos defeitos por caso de teste. TESTADOR CICLO ABORDAGEM Testador 3 Ciclo 2 Funcional Testador 1 Ciclo 1 Funcional 1 1 Testador 4 Ciclo 1 Funcional 1 TOTAL Testador 5 Ciclo 2 Riscos 8 2 Testador 2 Ciclo 1 Riscos 4 Testador 3 Ciclo 1 Riscos 4 TOTAL Testador 4 Ciclo 2 Funcional (RE) Testador 5 Ciclo 1 Funcional (RE) Testador 1 Ciclo 2 Funcional (RE) 1 TOTAL Tabela 4.21 Concentração dos defeitos por tempo de execução. TESTADOR CICLO ABORDAGEM 10min 20min 30min 40min 50min Testador 3 Ciclo 2 Funcional Testador 1 Ciclo 1 Funcional 1 1 Testador 4 Ciclo 1 Funcional 1 TOTAL Testador 2 Ciclo 1 Riscos Testador 3 Ciclo 1 Riscos Testador 5 Ciclo 2 Riscos TOTAL Testador 5 Ciclo 1 Funcional (RE) Testador 1 Ciclo 2 Funcional (RE) 1 Testador 4 Ciclo 2 Funcional (RE) TOTAL

104 A Tabela 4.22 apresenta a concentração dos defeitos por funcionalidade. Independente da abordagem utilizada, a maioria dos defeitos estão concentrados nas funcionalidades com maior exposição ao risco apresentadas na Tabela Tabela 4.22 Concentração dos defeitos por funcionalidade. TESTADOR CICLO ABORDAGEM LOCAL STATES CREATE PHENOMENON PHENOMENON STATERELATION QUANTITY TAKS GROUP TASK SEARCH Testador 1 Ciclo 1 Funcional 1 1 Testador 3 Ciclo 2 Funcional Testador 4 Ciclo 1 Funcional 1 TOTAL Testador 5 Ciclo 2 Riscos 8 2 Testador 2 Ciclo 1 Riscos 4 Testador 3 Ciclo 1 Riscos 4 TOTAL Testador 5 Ciclo 1 Funcional (RE) Testador 1 Ciclo 2 Funcional (RE) 1 Testador 4 Ciclo 2 Funcional (RE) TOTAL Considerações e Dificuldades Encontradas Neste estudo de caso, praticamente todas as atividades do RBTProcess puderam ser executadas, porém, algumas delas ainda foram executadas pela autora, tendo em vista a dificuldade de encontrar estudos de caso que a equipe pudesse assimilar e realizar o processo como um todo. Como foi apresentado, o tempo gasto nas atividades de gerência de riscos é relativamente baixo não gerando uma sobrecarga no processo de teste. Com relação aos resultados, ainda não é possível afirmar que a abordagem baseada em riscos, representada pelo RBTProcess, é melhor que a abordagem funcional, que não considera riscos, pois são necessários mais estudos de caso, para diferentes domínios de software. O que podemos afirmar é que, para este estudo de caso, a abordagem baseada em riscos se mostrou mais eficiente, confirmando que encontra os defeitos mais rápido que as demais, tendo em vista a priorização das funcionalidades. De acordo com a equipe MPhyScaS, as atividades realizadas não foram difíceis de serem realizadas, auxiliaram no conhecimento do software e os testes focaram em 89

105 funcionalidade realmente importantes. A equipe demonstrou interesse em adotar o RBTProcess e indica o uso do modelo de processo, inclusive para grandes projetos. Como melhoria do modelo de processo, a equipe sugeriu revisão do guia para atribuição de valores das métricas do cálculo de exposição ao risco. 4.7 Resumo do Capítulo Neste Capítulo, foi apresentado o RBTProcess, um Modelo de Processo de Teste de Software baseado em Riscos com atividade, artefatos e guias. O detalhes de cada atividade do RBTProcess, bem como os templates estão disponíveis em [RBTProcess 2008] e no Apêndice C. Além do modelo, métricas são propostas com o objetivo de medir e controlar a execução dos casos de teste baseado em riscos, bem como o esforço gasto em cada atividade do processo, o progresso da execução dos testes e a eficiência das atividades de identificação e análise dos riscos. O RBTProcess foi avaliado através de simulações de uso do processo e estudo de caso. As simulações serviram para refinar as atividades e artefatos do modelo de processo, enquanto que o estudo de caso possibilitou avaliar o RBTProcess com relação ao número e severidade dos defeitos encontrado, tempo gasto para encontrar cada defeito e concentração dos defeitos por funcionalidade. Vale destacar que, no planejamento inicial deste estudo de caso, estava previsto o uso da RBTTool, ferramenta de apoio ao teste de software baseado em riscos. No entanto, a ferramenta não foi concluída a tempo e a consolidação dos dados das atividades de identificação e análise e todos os artefatos foram produzidos manualmente. 90

106 Capítulo 5 RBTTool: Ferramenta de apoio ao Teste de Software baseado em Riscos Com a necessidade de aumentar a produtividade e qualidade, ferramentas de apoio a Engenharia de Software ou Computer-Aided Software Engineering (CASE) estão se tornando imprescindíveis nos ambientes de desenvolvimento de software (ADS). Uma ferramenta CASE é qualquer software que auxilia as pessoas que trabalham em um ADS (análise, projeto, implementação e teste) [Loh 1996]. Nesse contexto, apresentamos a RBTTool, uma ferramenta CASE para o teste de software baseado em riscos. Assim como as demais ferramentas CASE, a RBTTool tem como objetivo fornecer uma maior qualidade e produtividade nas atividade do teste baseado em riscos, através da automação de tarefas repetitivas, diminuindo a possibilidade de erros e inconsistência nos resultados. Vale salientar que não foram encontradas referências sobre ferramentas de apoio a abordagem RBT. Apenas [Jorgensen 2004], em seu trabalho de graduação, levantou os requisitos necessários para a construção de uma ferramenta de apoio à abordagem e construiu protótipos de interface gráfica para cada funcionalidade, mas, segundo o autor, não houve tempo suficiente para implementá-las. Além disso, o autor não contemplou, em seu documento de requisitos, atividades como identificação de riscos, cadastro de diferentes cálculos de exposição ao risco, planejamento e projeto de teste. Atividades estas que são de suma importância para o processo de teste de software baseado em riscos. Os requisitos necessários para a construção da RBTTool foram levantados a partir de estudo detalhado das principais abordagens RBT, apresentadas no Capítulo 3. É importante destacar que a RBTTool pode ser utilizada independente do RBTProcess. 91

107 5.1 Requisitos A RBTTool está dividia em dois grandes módulos: O módulo de apoio às atividades da gerência de riscos, que compreende as atividade de identificação, análise e controle dos riscos, e o módulo de apoio ao processo de teste de software que compreende as atividades de planejamento, projeto, execução e avaliação dos testes. O módulo de apoio à gerência de riscos foi priorizado e está em desenvolvimento para a primeira versão da ferramenta. Este módulo é o que fornece um maior ganho para atividade RBT, pois contempla atividades que não são de domínio dos engenheiros de teste e que não são apoiadas pelas ferramentas de teste de software. A Figura 5.1 apresenta os principais casos de uso para cada um dos módulos apresentados. O Analista de Riscos é ator principal das atividades de Gerência de Riscos, porém participam também destas atividades, o Gerente de Teste, Projetista, Testador e membros da equipe do software que será testado. Figura 5.1 Diagrama de caso de uso da RBTTool. 92

108 A seguir, será apresentada uma breve descrição dos casos de uso em desenvolvimento para a primeira versão. Os detalhes e descrição dos demais casos de uso estão disponíveis na página da ferramenta em [RBTTool 2008]. Manter Projetos RBT: permite ao Gerente de Teste incluir, excluir e alterar projetos de teste de software baseado em riscos. Dentre outras informações, o Gerente informa os requisitos que fazem parte do projeto, a versão do software que será testado, os recursos necessários e datas de início e fim da atividade de teste. Manter Requisitos: o Gerente de Teste cadastra os requisitos que estão no escopo dos testes. É possível cadastrar os fluxos de cada requisito informando, inclusive, o seu tipo (principal, alternativo e de exceção). Nas próximas versões, será possível importar requisitos de ferramentas de gerenciamento de requisitos disponíveis no mercado. Manter Riscos: o Analista de Riscos inclui na ferramenta riscos que podem ser identificados no produto de software. O sistema permite que os riscos cadastrados sejam classificados. Manter Questionário: o Analista de Riscos cadastra questionários que podem ser utilizados na etapa de identificação. Ele cadastra uma ou mais perguntas no questionário e associa estas perguntas a um risco cadastrado na ferramenta. Identificar Riscos: o Analista de Riscos cadastra o questionário utilizando a ferramenta, exporta para um documento e envia para os participantes da identificação. Após respondidos, os questionários são importados pela ferramenta, os dados são processados e sumarizados, resultando em uma lista de riscos identificados para cada requisito do software em teste. Analisar Riscos: o Analista de Riscos define as métricas que serão utilizadas no cálculo de exposição ao risco, exporta para documento e envia para os participantes da análise. Quando concluídas, os valores das métricas são processados e sumarizados, resultando na lista de priorização dos requisitos. 5.2 Material e Método Nesta seção, são descritas as tecnologias, ambiente de desenvolvimento e processos utilizados no desenvolvimento da RBTTool. 93

109 5.2.1 Tecnologias A seguir, apresentamos uma breve descrição das principais tecnologias utilizadas para construção da RBTTool. Java Java é uma linguagem de programação orientada a objetos, desenvolvida pela Sun Microsystems. Inicialmente, elaborada para ser a linguagem-base de projetos de software para produtos eletrônicos, Java teve seu grande reconhecimento em 1995, com o crescimento da web [Cornell et al 2000]. Java foi escolhida para desenvolvimento da RBTTool por ser livre, amplamente utilizada, multiplataforma e apoiada por diversas ferramentas, também livres. XML XML - extensible Markup Language é uma recomendação da World Wide Web Consortium (W3C) [XML 2008] para gerar linguagens de marcação para diferentes necessidades. É um subtipo da Standard Generalized Markup Language (SGML) ou Linguagem Padronizada de Marcação Genérica capaz de descrever diversos tipos de dados. Seu propósito principal é a facilidade de compartilhamento de informações. O formato XML foi escolhido para persistência dos dados da RBTTool por ser um padrão, de fácil manipulação, evitando a necessidade de bibliotecas, instalação de ferramentas, necessários para os bancos de dados Ambiente de Desenvolvimento e Frameworks Nesta Seção, apresentamos o ambiente de desenvolvimento da RBTTool e os frameworks utilizados. Eclipse Eclipse é uma plataforma IDE - Integrated Development Environment focada no desenvolvimento de ferramentas e aplicações de software. É a IDE Java mais utilizada no mundo [Eclipse 2008], possui orientação ao desenvolvimento baseado em plug-ins e amplo suporte ao desenvolvedor com centenas de plug-ins desenvolvidos que procuram atender às diferentes necessidades. A Eclipse Foundation [Eclipse 2008] mantém vários projetos envolvendo a sua IDE Eclipse, tornando-a extremamente adaptável às necessidades de cada cliente. 94

110 RCP RCP - Rich Cliente Plataform [RCP 2008] é uma poderosa plataforma de desenvolvimento que fornece suporte para criação de aplicações com interfaces gráficas, beneficiando-se de todas as vantagens do Eclipse. A RCP permite aos programadores desenvolver aplicações sem reescrever as classes do framework, criando, assim, aplicações com rápido desenvolvimento e integração, utilizando a linguagem Java. A Figura 5.2 apresenta os componentes da arquitetura da plataforma RCP, onde a RBTTool aparece como um plug-ins que se integra ao Eclipse. Figura 5.2 Componentes da Arquitetura RCP (2008). XStream O framework XStream [Xstream 2008] está sendo utilizado para persistência dos dados da RBTTool. Ele nada mais é que uma biblioteca para serialização de objetos através de XML, de fácil utilização, pois não necessita de mapeamento para serialização dos objetos. Ferramentas CASE A ferramenta REM - Requirement Management, desenvolvida por [Duran 2000], foi utilizada para documentação, gerenciamento e publicação dos casos de uso. O Jude - Java and UML Developer Environment [JUDE 2008] foi utilizada para criação dos diagramas de casos de uso e os modelos de análise e projeto da RBTTool. A ferramenta SVN (SubVersioN) [SNV 2008] foi utilizada para controle de versão dos artefatos. 95

111 5.2.3 Processos de Desenvolvimento e Gerência de Riscos O processo de desenvolvimento adotado é uma instância do RUP (2003), já apresentado no Capítulo 2. O desenvolvimento da RBTTool é iterativo, incremental e orientado por casos de uso. A cada iteração, os requisitos são detalhados e revisados, são criados diagramas de análise e projeto e os casos de uso são implementados e testados. Para a gerência de riscos, adotamos o processo Ágil de Gestão de Riscos em Ambientes de Múltiplos Projetos (GARA) proposto por [Ribeiro e Gusmão 2008]. Esse processo está sendo desenvolvido, em um trabalho de mestrado do DSC (Departamento de Sistemas e Computação) da Universidade de Pernambuco, pelo aluno Lúcio Ribeiro. O processo consiste em apenas quatro etapas, como apresenta a Figura 5.3 produz um único artefato, a Matriz de Impedimento. Visão: consiste na apresentação dos conceitos e objetivos da gerência de riscos. Realizada apenas uma vez, no início do projeto. Especulação: consiste em reuniões de brainstorm, onde a equipe levanta riscos que podem impedir o andamento das atividades e os prioriza. Também são estabelecidas estratégias de tratamento de resposta aos riscos. O resultado desta atividade é a matriz de impedimentos. Exploração: consiste na implemetação de ações para os riscos identificados. Adaptação: consiste no acompanhamento dos riscos, revendo tratamento de repostas e comunicando lições aprendidas. Figura 5.3 Processo Ágil de Gestão de Riscos GARA. 96

112 5.3 Estágio Atual de Desenvolvimento Encontra-se em desenvolvimento a primeira versão da RBTTool que contemplará o módulo de gerenciamento de riscos. Na primeira iteração, foram implementados e testados os casos de uso Manter Projeto RBT e Manter Requisito. Na segunda iteração, foram desenvolvidos os casos de uso relacionados à atividade de Identificação de Riscos. Nesta terceira iteração, estão em desenvolvimento os casos de uso relacionados à atividade de Análise de Riscos. O Apêndice B apresenta as telas da RBTTool, com um exemplo de utilização. A equipe RBTTool é composta, atualmente, por quatros membros do DSC da Universidade de Pernambuco: A orientadora desta dissertação, responsável pela coordenação da equipe. A mestranda que apresenta este trabalho, responsável pela definição dos requisitos e testes da RBTTool. Um estudante de graduação em fase de conclusão de curso, responsável pelo estudo e implementação das atividades de identificaçao de riscos. Um bolsista de iniciação científica, responsável pelo estudo e implementação das atividades de análise de riscos e processo de teste. Nas primeiras iterações, trabalhou junto com estudante de graduação em fase de conclusão de curso no desenvolvimento da ferramenta. A Tabela 5.1 apresenta o cronograma de atividades realizadas e a concluir neste ano. Tabela 5.1 Cronograma de atividades do ano de Mês/Atividade Estudo das principais Abordagens RBT Levantamento dos Requisitos para Construção da RBTTool Definição e Estudo das Tecnologias e Ferramentas CASE Configuração do Ambiente de Desenvolvimento Definição da Arquitetura da RBTTool Desenvolvimento 1ª Iteração Desenvolvimento 2ª Iteração Desenvolvimento 3ª Iteração Julho Agosto Setembro Outubro Novembro Dezembro 5.4 Resumo do Capítulo Este capítulo forneceu uma visão da RBTTool, uma ferramenta de apoio à abordagem de teste baseado em riscos. Para a definição dos requisitos necessários para a construção da RBTTool, 97

113 foram estudadas diversas abordagens RBT, não restringindo o seu escopo apenas a atividades do RBTProcess. A primeira versão da ferramenta contempla atividades da gerência de riscos como identificação e análise de riscos, considerando que estas são essenciais para a abordagem RBT e, em geral, desconhecidas para os engenheiros de teste. Os grandes desafios enfrentados pela equipe foram (i) identificar os requisitos que atendessem às principais abordagens disponíveis na literatura e (ii) definir arquitetura, levando em consideração a plataforma RCP, que possui uma curva de aprendizado inicial bastante alta. 98

114 Capítulo 6 Conclusões Este Capítulo relata as conclusões obtidas através da realização deste trabalho. A Seção 6.1 destaca as principais contribuições e resultados alcançados fornecidos para a área de teste de software. A Seção 6.2 apresenta algumas dificuldades e limitações encontradas no decorrer deste trabalho. A Seção 6.3 fornece uma comparação do RBTProcess com os trabalhos apresentados no Capítulo 3. Por fim, a Seção 6.4 apresenta trabalhos futuros e em andamento. 6.1 Contribuições e Resultados Alcançados O RBTProcess é um modelo de processo iterativo, orientado a riscos, modelado no nível M1 do SPEM - Software Process Engineering Metamodel e descrito utilizando o EPF - Eclipse Process Framework. As disciplinas Identificar, Analisar e Controlar Riscos são provenientes do gerenciamento de riscos e baseadas no RUP [RUP 2003], Guia PMBOK [PMI 2004] e CMMI [CMMI 2006]. As disciplinas Planejar, Projetar, Executar e Avaliar Testes são provenientes de processos de teste, baseadas no IEEE Std : Standard for Software Test Documentation [IEEE ], IEEE Std : Standard for Software Verification and Validation [IEEE ], TMM [Veenendaal 2006] e RUP [RUP 2003]. Apesar das diversas abordagens de teste baseado em riscos apresentadas no Capítulo 3, os engenheiros de teste ainda encontram dificuldade em aplicar RBT na prática. A finalidade do RBTProcess é fornecer conhecimento e recursos necessários para que os engenheiros de teste possam utilizar a abordagem RBT, beneficiando-se de todas as vantagens que ela fornece, apresentadas no Capítulo 3. 99

115 Além da definição do RBTProcess, outra grande contribuição é a RBTTool, ferramenta de apoio ao teste de Software baseada em riscos. A RBTTool é independente de processo ou abordagem, uma vez que ela permite realizar diversas formas de identificação e análise de riscos disponíveis na literatura. As simulações de uso de processo e o estudo de caso serviram, respectivamente, para refinar os componentes do RBTProcess e mostrar que a abordagem RBT, através do RBTProcess, concentra os esforços de teste nos requisitos de software que possuem maior probabilidade de apresentar falhas. Os resultados obtidos no estudo de caso fornecem uma forte indicação de que a abordagem RBT permite: Concentrar os esforços de teste nos requisitos de software que possuem maior probabilidade de apresentar falhas; Mostrar que os defeitos, com maior severidade, podem ser descobertos mais cedo, tendo em vista que os requisitos mais problemáticos são testados prioritariamente; Mostrar que a qualidade do produto final é melhorada, como conseqüência de uma atividade de testes bem planejada; Mostrar que as atividades da gerência de riscos de software, incluídas no processo de teste de software, não exigem muitos recursos e tempo para execução e, por fim, Fornecer ao gerente de testes subsidios para tomada de decisão. No entanto, mais estudos de casos, para diferentes domínios de software, necessitam ser realizados para que os benefícios constatados possam ser generalizados. 6.2 Limitações Encontradas O modelo de processo proposto neste trabalho, RBTProcess, possui algumas limitações que se espera reduzir com trabalhos futuros. A atividade de implementação de casos de teste, ou seja, a automatização de casos de teste não foi tratada em nenhuma versão do RBTProcess. Sabemos que os riscos técnicos podem aparecer tanto nos requisitos funcionais, como nos requisitos não funcionais. O RBTProcess considera apenas atividades para os requisitos funcionais, não fornecendo formas de tratamento para os requisitos não funcionais que, em geral, são mais difíceis de testar. 100

116 Por fim, diversas limitações foram identificadas no estudo de caso. (i) algumas atividades importantes do processo não puderam ser executadas por falta de disponibilidade da equipe; (ii) muitas das atividades do processo ainda foram realizadas pela autora; (iii) o estudo de caso realizado, considerou apenas os requisitos funcionais para a execução das atividades do processo e (iv) o tempo para realização da atividade de projeto de casos de teste baseado em riscos e casos de teste funcionais não foram coletadas para comparação. 6.3 Trabalhos Relacionados Comparando o modelo de processo proposto, o RBTProcess, com as demais abordagens apresentadas no Capítulo 3, tem-se: Descrição completa das atividades necessárias para execução de testes funcionais baseados em riscos, fornecendo uma separação clara das atividades de teste e de riscos de software, de forma a facilitar a adoção por empresas que ainda não possuem um processo de teste de software definido, como também para aquelas que já possuem e estão em constante evolução; Utilização e adaptação de questionário baseado em taxonomia de riscos, proposto pelo SEI [Carr et al 1993], com o propósito de auxiliar a identificação dos riscos associados aos requisitos do produdo de software e fornecer subsídio para o projeto dos casos de teste; Adaptação e validação do cálculo de exposição a risco, proposto por [Amland 1999], para considerar o impacto de alterações em uma funcionalidade nas demais; Fornecimento de guias, templates e métricas para as atividades do processo de teste de software baseado em riscos; Documentação e publicação do modelo de processo na web, utilizando ferramenta open source que permite instanciação e criação de novos processo. 6.4 Trabalhos Futuros Abaixo segue uma lista de trabalhos futuros, dentre os quais, alguns já estão em desenvolvimento. Com relação ao RBTProcess podemos citar como trabalhos futuros: 101

117 Realização de estudos de caso, sem a participação da autora, para diferentes domínios de software utilizando a RBTTool. A equipe MPhyScas, inclusive, demonstrou interesse em utilizar novamente o processo. Definição de métricas para controle e medição do impacto da adoção do RBTProcess em uma organização. Essas, apesar de serem muito importantes, não foram tratadas neste trabalho. Fornecer questionário baseado em taxonomia para os diferentes domínios de software, ou seja, criar um banco de dados de questionários baseado em taxonomia. Realização de estudos sobre padrões de teste de software com o objetivo de pesquisar os padrões existentes e identificar novos padrões para alguns domínios de software, verificando a possibilidade da utilização de padrões para projeto de testes baseados em riscos. Com relação à RBTTool podemos citar como trabalhos futuros: Conclusão da implementação das atividades de Análise de Riscos. Atividade em andamento. Implementação das atividades do processo de teste de software. Implementação de arquitetura distribuída para que as atividades sejam realizadas online pelos participantes e os resultados contabilizados automaticamente pela ferramenta. Implementar técnicas de inteligência artificial para automatizar atividades do processo de teste baseado em riscos, especialmente as atividades pertencentes ao gerenciamento de riscos. 102

118 Bibliografia [Amland 1999] Amland, S. Risk Based Testing and Metrics: Risk analysis fundamentals and metrics for software testing including a financial application case study. In: 5o International Conference EuroSTAR 99, [Bach 1995] Bach, J. The Challenge of Good Enough Software. In: American Programmer, [Bach 1999] Bach, J. James Bach on Risk-Based Testing: How to conduct heuristic risk analysis. In: Software Testing & Quality Engineering Magazine, p.23-28, [Bach 2003] Bach, J. Troubleshooting Risk-Based testing. In: Software Testing & Quality Engineering Magazine, [Besson 2004] Besson, S. A Strategy for Risk-Based Testing. Disponível em <StickyMinds.com>. Acesso em agosto de [Boehm 1991] Boehm, B. W. Software Risk Management: Principles and Practices. In: IEEE Software, v.8, p.32-40, [Burnstein et al 1999] Burnstein, I.; Homyen, A.; Suwanassart, T.; Saxena, G.; Grom, R. A Testing Maturity Model for Software Test Process Assessment and Improvement. In: Software Quality Professional Magazine, v.1, n.4, [Carr et al 1993] Carr, M. J.; Konda, S.L.; Monarch, I.; Ulrich, F. C.; Walker, C. Taxonomy Based Risk Identification. Technical Report CMU/SEI-93-TR-6. Software Engineering Institute, Carnegie Mellon University/USA, [Chen 2002] Chen, Y. Specification-based Regression Testing Measurement with Risk Analysis. Dissertação de Mestrado, University of Ottawa/Canada, [CMMI 2006] CMMI for Development, Version 1.2. Disponível em < Acesso em Janeiro de [Cornell et al 2000] Cornell, G.; horstman, S.; Core Java 2: Fundamentos. 1a edição, Makron Books,

119 [Delamaro et al 2007] Delamaro, M.; Maldonado, J.; Jino M. Introdução ao Teste de Software. 1a edição, Elsevier, [Duran 2000] Duran, A. A Methodological Framework for Requirements Engineering of Information Systems. Tese de Doutorado, University of Serville/Spain, [Eclipse 2008] Projeto Eclipse. Disponível em < Acesso em Julho de [EPF 2007] Eclipse Process Framework. Disponível em < Acesso em Agosto de [Fontoura et al 2004] Fontoura, L.; Price, R. Usando GQM para Gerenciar Riscos em Projetos de Software. In: 18º Simpósio Brasileiro de Engenharia de Software, [Graig e Jaskiel 2005] Graig, R. D.; Jaskiel S. P. Systematic software testing. Artech House Publishers, [Goldsmith 2006] Goldsmith, R. Early and Effective: The Perks of Risk-based Testing. In: Software Test and Performance Magazine, v.3, p.24-30, [GQM 2008] Goal Question Metric Approach (GQM), Disponível em < Acesso em Maio de [Graham et al 2007] Graham, D.; van Veenendaal, E.; Evans, I.; Black, R. Foundations of Software Testing: ISTQB Certification. Thomson Learning, [Gusmão 2007] Gusmão, C. Um Modelo de Processo de Gestão de Riscos para Ambientes de Múltiplos Projetos de Desenvolvimento de Software. Teste de Doutorado, Universidade Federal de Pernambuco/Brasil, [IEEE ] IEEE Std. 829, Standard for Software Test Documentation, [IEEE ] IEEE Std. 1012, Standard for Software Verification and Validation, [Jorgensen 2004] Jørgensen, L. A Software Tool for Risk-Based Testing. Trabalho de Graduação, Norwegian University of Science and Technology/Norway, [JUDE 2008] Java and UML Developer Environment. Disponível em < Acesso em Janeiro de [Kaner et al 1999] Kaner, C.; Falk, J.; Nguyen, H. Q. Testing computer software. 2a edição, Wiley, [Konda 2008] Konda, R. Measuring Defect Removal Accurately. Disponível em < Acesso em Setembro de

120 [Lins 2007] Lins, F. Modelagem da mprime Ontology em Lógica Descritiva e Implementação. Trabalho de Graduação, Universidade Federal de Pernambuco/Brasil, [Loh 1996] Loh, S. Ambientes de Desenvolvimento de Software e Ferramentas CASE. Disponível em < Acesso em Julho de [Meyers 1979] Meyers, G. J. The Art of Software Testing. John Wiley and Sons, [MPhyScas 2007] Multi-Physics and Multi-Scales Solver Environment. Disponível em < Acesso em Setembro de [PMI 2004] PMI Project Management Institute. A Guide to the Project Management Body of Knowledge. ANSI/PMI Project Management Institute, [RBTProcess 2008] RBTProcess Modelo de Processo de Teste de Software baseado em Riscos. Disponível em < Acesso em Outubro de [RBTTool 2008] RBTTool Ferramenta de Apoio ao Teste de Software baseado em Riscos. Disponível em < Acesso em Novembro de [RCP 2008] Rich Client Platform Wikipedia. Disponível em < Acesso em Junho de [Redmill 2004] Redmill, F. Exploring risk-based testing and its implications. In: Software Testing, Verification and Reliability, v.14, p.3-15, [Reffson et al 2006] Reffson, A.; Bezerra, C.; Coutinho, E,; Façanha, F. Análise da Aderência de um Processo de Teste ao TMM. In: 1o Simpósio Brasileiro de Testes de Software, SBTS, [Ribeiro e Gusmão 2008] Ribeiro, L.; Gusmão, C.; Definição de um Processo Ágil de Gestão de Riscos em Ambientes de Múltiplos Projetos. In: Hífen Magazine (Uruguaiana), [Rios 2005] Rios, E. Análise de Riscos em Projetos de Teste de Software. Alta books, [Rosenberg et al 1999] Rosenberg, L. H.; Stapko, R.; Gallo, A. Risk-based Object Oriented Testing. In: 24o Annual Software Engineering Workshop, NASA SEW24, [RUP 2003] Rational Unified Process. Versão Disponível em < Acesso em Janeiro de [RUP 2008] IBM Rational Unified Process Wikipedia. Disponível em < Acesso em Janeiro de

121 [Sartori 2005] Sartori, L. Melhoria de Processo para Pequenas Empresas. Dissertação de Mestrado, Universidade de Marília/Brasil, [Schaefer 2002] Schaefer H. Strategies for Prioritizing Tests Against Deadlines Risk Based Testing. Disponível em < Acesso em Agosto de [SEI 2006] Risk Management. Disponível em < Acesso em janeiro de [SMG 2001] Software Metrics Guide, Disponível em < Acesso em Janeiro de [SPEM 2005] Software Process Engineering Metamodel. Versão 1.1, [Stallbaum et al 2008] Stallbaum, H.; Metzger, A.; Pohl, K. An Automated Technique for Risk-based Test Case Generation and Prioritization. In: 3rd Workshop on Automation of Software Test, AST, [Soares et al 2002] Soares, S.; Laureano, E.; Borba, P. Implementing Distribution and Persistence Aspects with AspectJ. In: 17o ACM conference on OOPSLA 02, ACM Press, p , [Sommerville 2003] Sommerville, I. Engenharia de Software, Addison Wesley, [SVN 2008] Subversion. Disponível em < Acesso em Agosto de [Vasconcelos 2007] Modelos de Maturidade para Teste de Software. Disponível em < AM.pdf>. Acesso em Janeiro de [Veenendaal 2006] van Veenendaal, E. Guidelines for Testing Maturity, STEN Journal, v.4, [XML 2008] Extensible Markup Language. Disponível em < Acesso em Julho de [Xstream 2008] Xstream. Disponível em < Acesso em Janeiro de

122 Apêndice A Pesquisa sobre a Abordagem de Teste baseado em Riscos Tem como objetivo principal, investigar o conhecimento dos engenheiros de teste sobre a abordagem de teste baseado em riscos. Também, identificar possíveis utilizações da abordagem e o grau de satisfação das pessoas que a estão utilizando. O Questionário foi respondido por profissionais de tecnologia da informação que trabalham com teste de software, como, por exemplo, Gerentes de Testes, Analistas de Testes, Arquitetos de Testes, Projetistas de Testes e Testadores. Questionário 1. Como você classifica o seu conhecimento sobre a abordagem de Teste Baseado em Riscos (RBT - Risk-based Testing)? (selecione apenas uma opção) Desconheço. Já li ou ouvi falar, mas não conheço sua aplicação. Conheço e entendo sua aplicação. Conheço e já utilizei a abordagem. 1.1 Caso conheça ou já tenha utilizado a abordagem, como você a classifica? (selecione apenas uma opção) Ruim. Razoável. Boa. Ótima. 107

123 Justifique sua resposta da Questão Qual o seu conhecimento sobre Identificação e Análise de Riscos de Software? (mais de uma opção pode ser selecionada) Não tenho conhecimento. Conhecimento acadêmico. Conhecimento adquirido através de cursos de aperfeiçoamento. Conhecimento adquirido através de prática (no trabalho). 2.1 Como você classifica o seu conhecimento sobre Identificação e Análise de Riscos de Software? (selecione apenas uma opção) Básico. Intermediário. Avançado. 3. Como você classifica a equipe de teste da empresa onde você trabalha? (selecione apenas uma opção) A empresa não possui equipe de teste independente. A empresa possui equipe de teste independente. Para alguns projetos, a empresa possui equipe de teste independente. 4. Qual o tamanho da equipe de teste da empresa onde você trabalha? (selecione apenas uma opção) Até 5 pessoas. Entre 5 e 10 pessoas. Entre 10 e 20 pessoas. Mais que 20 pessoas. 5. Qual a localização da empresa onde você trabalha? (selecione apenas uma opção) Recife - Porto Digital. Recife - RMR. Outro Estado. 6. Qual a principal abordagem utilizada na empresa onde você trabalha? (selecione apenas uma opção) Funcional ou Caixa preta Estrutural ou Caixa branca 7. Você possui alguma certificação da área de teste? (selecione apenas uma opção) Sim. 108

124 Não. 7.1 Se possui certificação, informe o(s) nome(s)? 8. Selecione abaixo a sua última formação completa: (selecione apenas uma opção) Graduação. Especialização. Metrado. Doutorado. 9. Informe quanto tempo você trabalha com testes de software: (em anos) Resultados Perfil dos participantes No total, 80 pessoas participaram da pesquisa. Com relação a localização geográfica, 39% dos entrevistados estão localizados no estado de Pernambuco, sendo que destes, 15% estão localizados no Porto Digital. Os outros 61% estão localizados nos demais estados do país. Com relação à formação, 53% dos entrevistados possuem graduação, 26% especialização, 16% mestrado e 5% doutorado. Organizações que realizam Atividade de Teste de Software Apenas 17% dos entrevistados afirmaram que a empresa, na qual trabalham, não possui equipe independe de teste de software. 47% afirmaram que a empresa possui, normalmente, equipe de teste independe e 13% afirmaram que, para alguns projetos, a empresa possui equipe independente. Essa informação é bastante relevante, pois o RBTProcess necessita de uma equipe de teste independente e bem estruturada. De acordo com os entrevistados, a maioria das empresas (39%) possui equipes pequenas para a atividade de teste, com até cinco pessoas. No entanto, quase 30% das empresas possuem equipes grandes, com mais de 20 pessoas. 31% possuem equipes medianas entre 5 e 20 pessoas. Além disto, 90% dos entrevistados afirmaram que as empresas, na qual trabalham, realizam teste caixa-preta. Apenas 10% informaram a realização de teste caixa-branca. Conhecimento sobre Riscos de Software Sobre a gerência de riscos, 24% dos entrevistados informaram não possuir conhecimento sobre esta área. 28% possuem conhecimento acadêmico, enquanto que 10% fizeram cursos de 109

125 aperfeiçoamento na área e 38% adquiriam conhecimento no trabalho. Isto indica que, nos cursos de graduação, o investimento na área de gerência de riscos deixa a desejar. Com relação ao nível de conhecimento sobre riscos de software, 10%, 40% e 50%, dos entrevistados classificam, respectivamente, os seus conhecimentos como avançado, intermediário e básico. Ou seja, um número muito grande de engenheiros de teste tem conhecimento básico sobre riscos de software. Conhecimento sobre Teste de Software A maioria dos entrevistados (49%) possui entre 2 e 5 anos de experiência na área. Outros 42% possuem até 2 anos de experiência na área. O restante (9%) possui experiência de mais de 5 anos na área. Apenas 15% dos entrevistados informaram possuir certificações na área de teste de software. Sendo a certificação do ISTQB, e sua versão em português (BSTQB), as mais comuns. Conhecimento sobre Teste de Software baseado em Riscos Sobre a abordagem RBT, um número bastante alto (40%) de entrevistados afirmou não conhecer e nem ter ouvido falar sobre a abordagem. Apenas 8.5% dos entrevistados afirmaram ter utilizado a abordagem RBT. Destes, 30% e 50% a classificaram, respectivamente, como boa e ótima. A principal justificativa dos que a classificaram como razoável (15%) é a falta de conhecimento das atividades da gerência de riscos, que compromete a precisão dos resultados da identificação e análise dos riscos associados aos requisitos. Uma característica encontrada nas pessoas que já utilizaram a abordagem é o conhecimento intermediário ou avançado sobre atividades de gerência de riscos de software. 21.5% dos entrevistados afirmaram conhecer a abordagem e entender a sua aplicação na área. Destes, 13% e 67% a classificaram, respectivamente, como boa e ótima. 110

126 Apêndice B RBTTool: Telas Tela de Criação de Projeto RBT 111

127 Tela de Inclusão de Requisitos Tela de Visualização dos Requisitos adicionados a um Projeto RBT 112

128 Tela de Inclusão de Questionário em um Projeto RBT Tela de Inclusão de Perguntas em um Questionário Tela de Visualização das Perguntas do Questionário 113

129 Tela de Identificação de Riscos através de Questionário. 114

130 Tela de Relatório de Resultado da Identificação de Riscos 115