Requisitos para ferramentas de registro de defeitos de software

Transcrição

1 Requisitos para ferramentas de registro de defeitos de software Alessandro Liebmam Departamento de Ciência da Computação Instituto de Ciências Exatas Universidade Federal de Minas Gerais (UFMG) CEP: Belo Horizonte MG Brasil Abstract: XXXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX. Resumo: PXXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX. 1. Introdução Segundo Cândido [Cândido, 2004], no início desse século, fatores como a globalização da economia e a maior competitividade do mercado têm gerado inúmeros desafios para as empresas. Ainda segundo o autor, no caso das empresas baseadas em desenvolvimento de software, construir sistemas em tempo hábil, com custos razoáveis e qualidade adequada tornou-se fundamental. Atento a essas exigências, as organizações de software vêm utilizando as atividades de teste de software para evitar e reparar os problemas e as deficiências contidas no software desenvolvido antes que esse seja entregue ao cliente. Teste de software é uma das técnicas utilizadas para obtenção da qualidade do software, tornando-se indispensável para a identificação e eliminação de problemas que possam vir a ocorrer durante este processo [Pressman, 2002]. Determinar a qualidade de um software produzido não é uma tarefa simples, já que, mesmo atendendo a todas as suas especificações, os usuários ainda podem não considerá-lo como um produto de alta qualidade. Embora não sendo uma tarefa trivial, segundo Software Engineering Institute [SEI, 1992], é possível perceber que quanto maior o número de defeitos encontrados em um software, menor será a qualidade do mesmo, ou seja, a qualidade é inversamente proporcional ao número de defeitos encontrados. Um dos fatores importantes para um bom trabalho de testes e qualidade são o registro e acompanhamento dos defeitos encontrados durante o processo de desenvolvimento. Conforme o SWEBOK [SWEBOK, 2004], esse monitoramento pode ser utilizado para analisar quais os aspectos no processo de desenvolvimento de software da organização podem ser melhorados, qual tipo de erro causou o defeito e em que momento os defeitos poderiam ter sido identificados no processo de desenvolvimento do software. Entretanto, para um efetivo aproveitamento de tais registros, devem ser definidos padrões, procedimentos e um conjunto de informações mínimas. Para projetos pequenos e com pouco volume de dados, talvez seja possível registrar os defeitos encontrados, no software sob teste, em planilhas ou documentos e com pouca formalidade e padronização. Entretanto quando a quantidade de informações cresce e o tamanho do projeto é grande, o uso de uma ferramenta torna-se imprescindível para gerenciar essa massa de dados. Além disso, os defeitos encontrados devem ser registrados de forma a facilitar a recuperação das informações pelos vários envolvidos no desenvolvimento do software: desenvolvedores que serão os responsáveis pela correção do defeito; gerentes, para acompanhamento do produto testado;

2 testadores, que deverão verificar a correção do defeito; equipe da qualidade e processo, responsáveis pelo levantamento de métricas e melhorias no processo. A adoção de ferramentas que dêem suporte aos diversos processos da engenharia de software já é bastante consolidada em organizações desenvolvedoras de software, entretanto, ferramentas envolvem benefícios potenciais e riscos. Benefícios tais como: reduzir trabalhos repetitivos, facilidade de acesso a informações sobre o teste. Em contrapartida, existem os riscos como as falsas expectativas referentes à ferramenta (incluindo funcionalidades e falibilidades de uso). Esse artigo irá apresentar uma lista de requisitos necessários e essenciais para uma ferramenta de registro de defeitos de software, ou seja, um catálogo dos requisitos para esse tipo de ferramenta, também conhecida como bug tracking. Espera-se, com este trabalho, diminuir os riscos da utilização de ferramentas no processo de teste, apoiar organizações desenvolvedoras de software que desejem adquirir esse tipo de ferramenta, bem como, organizações que desenvolvam ferramentas de registro de defeitos aumentando, assim, os benefícios potenciais das mesmas. Os requisitos levantados nesse artigo considerarão a perspectiva de diversos profissionais que utilizam o registro de defeito ou o conjunto deles ao longo do desenvolvimento do software. Por exemplo, o testador necessita de alguns requisitos na ferramenta para facilitar o cadastro e verificação do defeito encontrado, por outro lado, o gerente do projeto necessita de outros requisitos para avaliação geral dos defeitos encontrados para o projeto ou para um módulo específico. 2. Modelos e Características de Ferramentas de Registro de Defeitos O padrão IEEE número [IEEE, 1990] define defeito como sendo um passo, processo ou definição de dados incorretos; como, por exemplo, uma instrução ou comando incorreto. Segundo Software Engineering Institute [SEI, 1992], defeito é qualquer característica não intencional que prejudica a utilidade ou valor de um item, ou qualquer tipo de falha, imperfeição ou deficiência. Considerando que um dos objetivos de teste é encontrar defeitos, as discrepâncias entre o resultado esperado e o atual precisam ser registradas. Defeitos podem ser encontrados durante o desenvolvimento, o teste e a utilização do software. Eles podem se revelar por problemas no código, por funções do sistema, documentação do desenvolvimento, documentação de teste, manual de instalação ou manual do usuário. Conforme Paula Filho [Paula Filho, 2003], os defeitos decorrem de limitações humanas: erros lógicos, erros de interpretação, desconhecimento de técnicas, falta de atenção ou falta de motivação. Defeito deve ser rastreável desde a descoberta, a classificação até a correção e a confirmação da solução. Ferramentas de registro de defeitos possuem como objetivos: Prover aos desenvolvedores e outros envolvidos um retorno sobre o problema para permitir a identificação, isolamento e correção, se necessário; Prover aos gerentes um meio de rastrear a qualidade do sistema sob teste e o progresso do teste; Prover idéias para aprimorar o processo de desenvolvimento de software. O registro dos defeitos encontrados ao longo do desenvolvimento de software pode ser usado como base de dados para medir e controlar o desenvolvimento e manutenção de um software. Segundo o Software Engineering Institute [SEI, 1992], a principal razão para medir software ou o processo de software é para se obter dados que auxiliem o controle do cronograma do projeto, os custos e a qualidade do produto desenvolvido. Ainda segundo o Software Engineering Institute

3 [SEI, 1992], algumas entidades tais como tamanho, defeitos, esforço e tempo (cronograma) são mensuráveis e provêem dados para: Expressar, quantitativamente, requisitos, objetivos e critérios de aceitação; Monitorar o progresso e antecipar os problemas; Quantificar o recurso a ser alocado; Prodiagnosticar os atributos de software como qualidade, custo e cronograma. Dados e medições extraídos de ferramentas de registro de defeitos são importantes para determinar ações corretivas, medir e melhorar o processo de desenvolvimento de software e fazer predições dos defeitos restantes ou taxas de fracasso do projeto. 3. Requisitos Nessa seção são enumerados alguns requisitos para ferramentas de registro de defeitos, esses requisitos foram baseados em trabalhos existentes na literatura tais como Sanyal (1992), SEI (1992) e na experiência de profissionais envolvidos no desenvolvimento de software. Requisito 1 Classificar defeitos Durante os testes, revisões e inspeções realizadas nos produtos de software em desenvolvimento, diversos defeitos podem ser encontrados. Entretanto, nem todos os defeitos são sérios ou, então, a probabilidade do defeito ser encontrado pelo cliente é remota. Assim, torna-se necessário classificar os defeitos encontrados de acordo com o quanto aquele defeito afetará o cliente. Segundo o Software Engineering Institute [SEI, 1992], a severidade é a medida do impacto que um defeito proporciona quando os usuários encontram-no; e essa severidade deve ser habitualmente medida em vários níveis, onde o mais crítico corresponde a um impacto catastrófico e o menos crítico, ao nível de impacto considerado aceitável. Conforme Sanyal [Sanyal et. al., 1992], uma forma de classificação dos defeitos sugerida por Humphrey é feita em quatro níveis: Severidade 1: Indica resultados incorretos ou falhas críticas do programa em execução. Severidade 2: Indica resultados incorretos mas não são considerados críticos para o programa em execução. Severidade 3: Indica que o programa em execução teve um comportamento inesperado. Severidade 4: Indica uma sugestão ou pedido de melhoria. Existem outras abordagens diferentes da sugerida por Humphrey para a classificação dos defeitos. A forma como essa classificação deve ser feita, ou seja, a quantidade de níveis, o que cada um indica e o nome do nível, podem variar bastante nas ferramentas de registro de defeitos. Requisito 2 Priorizar defeitos Conforme o Software Engineering Institute [SEI, 1992], a prioridade de um defeito determina a ordem na qual os defeitos são avaliados, resolvidos e fechados. Essa prioridade normalmente está relacionada com a classificação do defeito, ou seja, defeitos com alta severidade são classificados freqüentemente com alta prioridade.

4 4. Aspectos Práticos e Operacionais Atualmente existem diversas ferramentas que dão suporte a diferentes aspectos de teste, entre elas, ferramentas de registro de defeitos. A aquisição e/ou o desenvolvimento de uma ferramenta de registro de defeitos deverá levar em consideração o processo de desenvolvimento da organização, bem como, os benefícios esperados com a utilização da ferramenta. Devem ser listados os requisitos essenciais para atender às necessidades dos envolvidos no processo de desenvolvimento de software. A seleção ou implementação de ferramentas de registro de defeitos deve levar em consideração as necessidades dos gerentes do projeto, dos testadores, dos desenvolvedores e dos gerentes de qualidade. 5. Conclusão O processo de desenvolvimento de software envolve uma série de atividades nas quais, apesar das técnicas, métodos e ferramentas empregados, defeitos são introduzidos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo de desenvolvimento do software são dois possíveis fatores que aumentam a complexidade dessa tarefa, e conseqüentemente aumentam a probabilidade de defeitos. A utilização de ferramentas que apoiem o registro dos defeitos durante o ciclo de desenvolvimento de software facilita, através de medições realizadas, a tomada de decisão acerca do projeto, bem como, possibilita o levantamento de melhorias em todo o processo de desenvolvimento de software. 6. Referências Bibliográficas Cândido, E.J.D. (2004) Uma simplificação da técnica análise de pontos de função para estimar tamanho de aplicativos web. Dissertação de Mestrado, USP, D'Ambros, M. Lanza, M. Pinzger, M. (2007) "A Bug's Life" Visualizing a Bug Database. In: Visualizing Software for Understanding and Analysis, VISSOFT th IEEE International Workshop on page D'Ambros, M.; Lanza, M. (2006) Software Bugs and Evolution: A Visual Approach to Uncover Their Relationship. In: Software Maintenance and Reengineering, CSMR Proceedings of the 10th European Conference; Vol. 00 on page Francisco M. P.; Peres P. B; Robles G, (2007) Correlation between bug notifications, messages and participants in Debian s bug tracking system. In: Proceedings of the First International Symposium on Empirical Software Engineering and Measurement on page Harry S. Delugach (2007) An evaluation of the pragmatics of web-based bug tracking tools. In: ACM International Conference Proceeding Series; Vol. 280 on page IEEE, (1990) IEEE Standard glossary of software engineering terminology, Stantard IEEE Press, 1990 Paula Filho, W. P. (2003) Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, Pressman, R. S. (2002) Engenharia de Software, 5 ed. Rio de Janeiro: McGraw-Hill. SEI (1992) CMU/SEI-92-TR-22 - Software Quality Measurement: A Framework for Counting Problems and Defects Sanyal, S.; Aida, K.; Gaitanos, K.; Wowk G.; Lahiri S, (1992) Defect tracking and reliability modeling for a new product release. In: CASCON '92: Proceedings of the 1992 conference of the Centre for Advanced Studies on Collaborative research - Volume 1

5 Serrano, N.; Ciordia, I. (2005) Bugzilla, ITracker, and Other Bug Trackers. In: Software, IEEE on page SWEBOK (2004) Guide to the software engineering Body of Knowledge