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

Transcrição

1 RBTProcess - Modelo de Processo de Teste de Software baseado em Riscos Aluna Ellen Polliana Ramos Souza Orientadora Profª Dra. Cristine Martins Gomes de Gusmão Mestrado Acadêmico em Engenharia da Computação Departamento de Sistemas e Computação Universidade de Pernambuco (UPE) Rua Benfica, 455 Madalena, , Recife, PE Brasil {eprs,cristine}@dsc.upe.br Nível: Mestrado Ano de Ingresso: Julho de 2006 Previsão de Conclusão: Dezembro de 2008 Aprovação da Proposta: Outubro de 2007 Resumo. A busca pela qualidade de software é um fator crítico que tem crescido com a complexidade das tecnologias e a competitividade entre as empresas. O processo de teste exerce um importante papel dentro da garantia de qualidade de software assegurando que os requisitos satisfazem as necessidades das partes envolvidas. No entanto, o processo de teste requer bastante esforço, pois é grande o domínio de entradas e saídas de um software, bem como são muitas as possibilidades de caminhos possíveis a serem testados dentro de restrições de custo e prazo. Teste baseado em riscos (risk-based testing) consiste num 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 testes, por sua vez, são projetados com base nas estratégias para tratamento dos fatores de riscos identificados. O controle da execução dos casos de testes permite uma mitigação dos fatores de riscos associados. Dessa forma, o uso da abordagem permite priorizar esforços e alocar recursos para os componentes de software que necessitam ser testados cuidadosamente. Este trabalho tem como objetivo a construção de um modelo de processo de teste de software baseado em riscos com artefatos, guias, métricas e atividades, apoiado por ferramenta e avaliado através de estudos de casos. Palavras-chave. Teste de Software, Teste baseado em Riscos, Modelo de Processo, Riscos Técnicos. 7

2 1. Caracterização do Problema A atividade de teste de software tem se mostrado fundamental no desenvolvimento de software evitando, principalmente, que falhas cheguem aos clientes, deixando-os insatisfeitos e causando prejuízos. No entanto, esta atividade é 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 e demais autores (1999), a atividade de teste é bastante cara, chegando a custar até 45% do valor inicial de um produto em desenvolvimento. 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. A técnica de teste baseada em análise de riscos Risk-based Testing (RBT) surgiu como uma abordagem para minimizar alguns dos problemas relacionados ao esforço da atividade de teste e da gerência de riscos. O teste baseado em riscos, em resumo, consiste em atividades para identificação, análise e mitigação de fatores de riscos associados aos requisitos do produto de software, priorizando esforços e alocando recursos para os componentes de software que necessitam ser testados mais cuidadosamente. Assim, a atividade de testes é melhorada a partir da gerência dos riscos técnicos de software que podem ser mitigados através da realização de teste de software. Apesar da abordagem RBT se mostrar simples, a comunidade de teste de software ainda encontra 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. 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. Dentro deste contexto, este trabalho apresenta o RBTProcess Modelo de Processo de Teste de Software baseado em Riscos. Após esta Seção introdutória, a Seção 2 apresenta a fundamentação teórica da abordagem RBT. Na Seção 3 é descrito o modelo de processo proposto, protótipo, simulações e estudos de caso. A Seção 4 apresenta o estado atual do trabalho. Na Seção 5 é apresentada uma comparação das principais abordagens RBT citadas na Seção 2. Finalmente, na Seção 6, são apresentados os resultados esperados. 2. Fundamentação Teórica Ao analisar as abordagens existentes, três atividades distintas foram identificadas: i. Elaborar uma lista de riscos priorizada; ii. Realizar testes que exploram cada risco e iii. Acompanhar e controlar os riscos. A primeira atividade consiste na identificação de requisitos com alto grau de risco associado. A segunda atividade consiste na criação e execução de testes que verificam a existência ou não do risco identificado. As abordagens encontradas na literatura não fornecem metodologias para a atividade de criação dos casos de teste. No entanto, para a execução, diversas estratégias foram encontradas. Na terceira atividade, 8

3 assim que um risco for eliminado, um novo risco surge e os esforços de testes devem ser ajustados para que foquem sempre nos riscos mais importantes. Bach (1999) define duas abordagens 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. Para cada risco, é identificado se o mesmo se aplica ou não a um determinado componente. São atribuídos valores através de uma escala de interesse e os riscos com maior valor são testados primeiramente. Amland (1999) desenvolveu um conjunto de métricas para a análise de riscos com o objetivo de subsidiar um processo de teste. Três fontes de análise de riscos são utilizadas: i. Qualidade da área a ser testada; ii. Conseqüências de uma falha em uma função do ponto de vista de um cliente em situação de produção e iii. Conseqüências de uma falha em uma função do ponto de vista do vendedor do serviço. Besson (2004) define uma abordagem baseada em uso. Segundo o autor, qualquer atividade de teste implica numa diminuição de riscos. A idéia é investir o mínimo de esforço em teste possível para maximizar a redução dos riscos. O autor controla o esforço de teste baseado na utilização do software, seguindo a teoria de Pareto, que afirma que 20% das funcionalidades permitem ao usuário realizar 80% do seu trabalho. Chen (2002) define uma estratégia para execução de testes de regressão baseada em especificação. A autora define teste de regressão para os componentes que foram alterados e teste de regressão, baseado em riscos, para os componentes que aparentemente não sofreram modificações. Rosenberg e demais autores (1999) fornecem uma abordagem 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, pode-se chegar a classes que possuam maior probabilidade de apresentar falhas. 3. Caracterização da Contribuição O objetivo geral desse trabalho é a criação de um Modelo de Processo de de Software baseado em Riscos. A Figura 1 esboça uma visão inicial do modelo de processo proposto que será, também, apoiado por um protótipo Modelo de Processo O RBTProcess 1 é um modelo de processo baseado no RUP (2003), iterativo, orientado a riscos, modelado no nível M1 do Software Process Engineering Metamodel (SPEM 2 ) e descrito utilizando o Eclipse Process Framework (EPF 3 ). O modelo de processo possui quatro fases distintas: i. Planejamento: Planejamento inicial dos testes com base na análise dos riscos. Tem como marco a priorização dos requisitos através da 1 Versão inicial do RBTProcess na web: 2 SPEM na web: 3 EPF na web: 9

4 identificação e análise dos riscos; ii. Projeto: Os casos de testes planejados são projetados com base na análise dos riscos. O marco desta fase é a criação de casos de testes que verificam a existência ou não dos riscos identificados; iii. Execução: Os casos de testes planejados e projetados são executados e iv. Controle: Os resultados da execução dos testes são coletados, avaliados e os ricos são controlados. Figura 1. Proposta do Modelo de Processo de Teste de Software baseado em Riscos e Relacionamento dos Artefatos em cada Fase. Os artefatos com borda pontilhada na Figura 1 são originados do processo de teste baseado em riscos. Os artefatos com sombra fazem parte do processo de teste padrão. Os demais são alguns dos artefatos criados durante o processo de desenvolvimento de software. Os papéis identificados são os mesmos de um processo de testes padrão com exceção do Analista de Riscos que é um papel da gerência de riscos, essencial para identificação, análise e controle dos riscos. As atividades Identificar Riscos, Analisar Riscos e Controlar Riscos são provenientes do gerenciamento de riscos e baseadas no Guia PMBOK (Project Management Body of Knowledge) (2004) e no CMMI (Capability Maturity Model Integration) nível três (2004). As atividades Elaborar Plano de Teste, Projetar, Executar e Avaliar são provenientes de processo de teste padrão e baseadas no TMM (Test Maturity Model) nível três (2005) e nos padrões IEEE 829 e 1012 (1998). Para identificação dos riscos são utilizadas técnicas como listas de verificação, reuniões de brainstorm e questionário baseado em taxonomia de riscos adaptado, pela autora, para teste de software. Para a análise, métricas definidas por Amland (1999) e utilizadas por Chen (2002) são adotadas com algumas adaptações. O planejamento dos testes, definição de estratégias e escopo são realizados com base na avaliação de riscos. Os casos de teste são projetados para mitigar os riscos identificados e também, de acordo com o grau de exposição ao risco, casos de teste são projetados para explorar os fluxos principais, alternativos e de exceção. Os casos de testes são executados de acordo com o cálculo de exposição ao risco e os riscos são avaliados em cada iteração. 10

5 3.2. Protótipo Além do processo, um protótipo está em desenvolvimento para atender às atividades da abordagem RBT, auxiliando os engenheiros de testes, principalmente, nas atividades de identificação, análise e controle dos riscos técnicos de software. É importante registrar que os requisitos para a construção do protótipo estão sendo avaliados através das simulações e que se espera realizar os estudos de casos com o apoio do mesmo, conforme trata a seção a seguir Simulações e Estudos de caso Simulações estão sendo realizadas com o objetivo de ajustar as atividades, artefatos e papéis do processo, identificando oportunidades de melhorias. Estudos de caso estão sendo planejados e servirão para avaliar o uso do RBTProcess com o propósito de caracterizar o impacto da sua adoção em empresas de desenvolvimento de software, com respeito ao número de defeitos encontrados e tempo para realização das atividades definidas no processo. 4. Estado Atual do Trabalho Nesse momento, a segunda versão do modelo de processo está sendo ajustada de acordo com os problemas apontados nas primeiras simulações e um protótipo está em desenvolvimento para fornecer suporte às atividades definidas na abordagem RBT. Dois estudos de caso serão planejados com o intuito de avaliar o resultado geral do processo sob o ponto de vista, principalmente, da qualidade do produto final. Uma pesquisa 4 sobre a abordagem RBT foi elaborada com o intuito de capturar, dentre outras informações, a formação dos engenheiros de testes com relação a riscos, quem utiliza e formas de utilização. 5. Trabalhos Relacionados (Visão Comparativa) A Tabela 1 apresenta um resumo das atividades incluídas nas principais abordagens encontradas na literatura e apresentadas na Seção 2. Com exceção da abordagem de Rosenberg e demais autores (1999), todas as outras utilizam a abordagem funcional ou caixa-preta para construção dos casos de testes no nível de sistema. Apenas o RBTProcess fornece o artefatos, guias, métricas, papéis e fluxos para todas as atividades. Tabela 1. Atividades Incluídas nas Abordagens ou Processos RBT. Abordagens / Processo Identificar Riscos Analisar Riscos Planejar Projetar Executar Avaliar Controlar Riscos Baseada em Heurística [Bach 1999] SIM SIM NÃO NÃO SIM NÃO SIM Baseada em Métricas [Amland 1999] NÃO SIM NÃO NÃO SIM NÃO SIM Baseada em Uso [Besson 2004] SIM NÃO SIM NÃO SIM NÃO SIM de Regressão [Chen 2002] NÃO SIM SIM SIM SIM NÃO SIM Código Fonte Orientado a Objetos [Rosenberg et al 1999] SIM SIM NÃO NÃO NÃO NÃO NÃO Processo de [RBTProcess] SIM SIM SIM SIM SIM SIM SIM 4 Questionário está disponível em: 11

6 6. Avaliação dos Resultados tradicionais sempre utilizam a idéia de teste baseado em riscos, mas de uma forma ad hoc e baseado em julgamento pessoal [Chen 2002]. De acordo com os resultados das diversas abordagens encontradas na literatura, a técnica de teste baseado em riscos permite reduzir tempo e esforço para verificar o software, uma vez que o universo de testes é menor como resultado da priorização dos cenários e, como conseqüência, minimizar custos da atividade de testes como um todo. Com relação ao RBTProcess, apoiado pelo protótipo, espera-se confirmar, com a realização de estudos de casos, que: i. As atividades da gerência de risco não tragam um esforço maior para o processo de teste padrão já que as atividades de projeto e execução de testes devem ser realizadas com menor esforço por conta da priorização dos requisitos e casos de testes; ii. Os esforços sejam alocados para os componentes de software que necessitam ser, de fato, testados mais cuidadosamente; iii. A qualidade do produto final seja melhorada como conseqüência de uma atividade de testes bem planejada. Referências Amland, S. (1999) Risk Based Testing and Metrics: Risk analysis fundamentals and metrics for software testing. In 5th International Conference EuroSTAR 99. Bach, J. (1999) James Bach on Risk-Based Testing: How to conduct heuristic risk analysis. In Software Testing & Quality Engineering Magazine. Besson, S. (2004) A Strategy for Risk-Based Testing. Disponível em < stickyminds.com>. Acesso em agosto de Chen, Y. (2002) Specification-based Regression Testing Measurement with Risk Analysis. Dissertação de mestrado, University of Ottawa, Canada. CMMI Capability Maturity Model Integration (2006), Software Engineering Institute, Carnegie Mellon University. Disponível em < Acesso em fevereiro de Goldsmith, R. (2006) Early and Effective: The Perks of Risk-based Testing. In Software Test & Performance Magazine. IEEE Std. 829 (1998) Standard for Software Test Documentation. IEEE Std (1998) Standard for Software Verification and Validation. Kaner, C., Falk, J., Nguyen, H. Q. (1999) Testing computer software, 2a edição. PMBOK - Project Management Institute (2004) A Guide to the Project Management Body of Knowledge. Rosenberg, L. H.; Stapko, R.; Gallo, A. (1999) Risk-based object oriented testing: In 24th Annual Software Engineering Workshop, NASA SEW24. RUP - Rational Unified Process (2003) Disponível em < Acesso em janeiro de TMM - Test Maturity Model (2005), Illinois Institute of Technology. Disponível em < Acesso em fevereiro de