UNIVERSIDADE ANHEMBI MORUMBI ANDRÉ CORSINI FELIPE LIGIA AFFONSO ANDRÉ DE ALMEIDA RODRIGO SEIXAS SISNANDO FELIPE MALTA DA COSTA

UNIVERSIDADE ANHEMBI MORUMBI ANDRÉ CORSINI FELIPE LIGIA AFFONSO ANDRÉ DE ALMEIDA RODRIGO SEIXAS SISNANDO FELIPE MALTA DA COSTA ESPECIFICAÇÃO E DESENVOLVIMENTO DE MELHORIAS PARA A FERRAMENTA DE GESTÃO DE OCORRÊNCIAS DE SOFTWARE MANTIS São Paulo 2010

ANDRÉ CORSINI FELIPE LIGIA AFFONSO ANDRÉ DE ALMEIDA RODRIGO SEIXAS SISNANDO FELIPE MALTA DA COSTA ESPECIFICAÇÃO E DESENVOLVIMENTO DE MELHORIAS PARA A FERRAMENTA DE GESTÃO DE OCORRÊNCIAS DE SOFTWARE MANTIS Monografia apresentada como exigência para a obtenção do certificado de Bacharelado do curso de Ciência da Computação da Universidade Anhembi Morumbi. Orientador: Professora Roberta Beatriz Aragon Bento São Paulo 2010

ANDRÉ CORSINI FELIPE LIGIA AFFONSO ANDRÉ DE ALMEIDA RODRIGO SEIXAS SISNANDO FELIPE MALTA DA COSTA ESPECIFICAÇÃO E DESENVOLVIMENTO DE MELHORIAS PARA A FERRAMENTA DE GESTÃO DE OCORRÊNCIAS DE SOFTWARE MANTIS Monografia apresentada como exigência para a obtenção do certificado de Bacharelado do curso de Ciência da Computação da Universidade Anhembi Morumbi. Aprovado em Professor Universidade Anhembi Morumbi Professor Universidade Anhembi Morumbi Professor Universidade Anhembi Morumbi

AGRADECIMENTOS Gostaríamos de agradecer inicialmente à Prof.ª Roberta Aragon, pela grande ajuda, empenho e dedicação ao grupo, pelas fervorosas cobranças, sem as quais este trabalho não viraria realidade e por ter se mostrado uma ótima orientadora, professora e pessoa. Agradecemos também a nossos familiares, em especial nossos pais, pela ajuda que nos foi dada ao longo deste caminho e pela paciência demonstrada nesses meses de trabalho. Dedicamos este trabalho também, à avó de um de seus autores, que infelizmente faleceu durante o projeto. Agradecemos aos nossos colegas da Universidade Anhembi Morumbi e aos profissionais da área de TI que participaram da nossa pesquisa, colaborando para a confecção deste trabalho. Muito obrigado.

O único lugar em que sucesso vem antes do trabalho, é no dicionário Albert Einstein

RESUMO A área de desenvolvimento de sistemas cresce rapidamente a cada dia e isso leva as empresas deste ramo, tanto pequenas quanto grandes, a buscar simplificações em seus serviços e mais qualidade em seus resultados. Estas empresas sabem que para garantir a qualidade de seus sistemas e assim obter maiores lucros, é necessário ter presente uma área de qualidade, ou seja, uma equipe de testes junto à equipe de desenvolvimento. Para facilitar a comunicação entre estas duas equipes, existem ferramentas específicas, os gerenciadores de ocorrências. Geralmente, grandes empresas adquirem gerenciadores pagos, que se apresentam ricos em funcionalidades, porém são caros. Já as pequenas e médias empresas utilizam ferramentas open source, que são gratuitas, porem são pobres em funcionalidades ou contém funcionalidades limitadas e problemáticas. Através do estudo de uma dessas ferramentas open source, chamada Mantis, que se apresenta como a ferramenta mais utilizada por pequenas e médias empresas, e de uma pesquisa de satisfação realizada via Web com analistas de teste e desenvolvedores que a utilizam, foram levantadas e implementadas melhorias, buscando aperfeiçoar a comunicação entre as equipes e tornar a ferramenta mais completa. Palavras-chave: Teste de Software, Gerenciadores de Ocorrência, Ferramenta Mantis, Qualidade de Software.

ABSTRACT The systems development area is growing rapidly every day and it takes the companies in this industry, both small and large, to seek simplifications in its services and more quality in their results. These companies know that to ensure the quality of their systems and thus higher profits, they must have one area of quality, ie a "test team" working with the development team. To facilitate the communication between these two teams, there are specific tools, occurrence`s manager. Usually big companies can afford paid managers (sharewares), which have rich features, but are expensive. Small and medium enterprises can only use open source tools, which are free, but are poor in functionality or contain limited functionalities and problems. Through the study of one of these open source tools, called Mantis, which is presented as the most used tool by small and medium enterprises, and a satisfaction survey conducted via Web with analysts and test developers who use it, have been raised and implemented improvements, seeking to improve communication between teams and make the product more complete. Keywords: Software Test, Event Managers, Mantis Tool, Software Quality.

LISTA DE FIGURAS Figura 1 - Verificação e Validação... 21 Figura 2 - Modelo V... 22 Figura 3 - Projeto de Teste... 24 Figura 4 - Fluxo de Erro... 27 Figura 5 - Fluxo de Dúvida... 28 Figura 6 - Caso de Teste com falha... 29 Figura 7 - Gerando Número da Ocorrência... 29 Figura 8 - Ocorrencia do Mantis... 29

LISTA DE TABELAS Tabela 1 - Estágios de Teste... 18 Tabela 2 - Extensões Aceitas para Exportação... 25 Tabela 3 - Extensões de Arquivo para Importação... 26 Tabela 4 - Melhorias para o Mantis... 33

LISTA DE SIGLAS CSV GPL HP HTML IBM IBQTS PHP TI XML XLS Comma Separated Values General Public License Hewlett-Packard HyperText Markup Language International Business Machines Instituto Brasileiro de Qualidade de Software Hypertext Preprocessor Tecnologia da Informação Extensible Markup Language Microsoft Office Excel Spreadsheet

SUMÁRIO 1 INTRODUÇÃO...ERRO! INDICADOR NÃO DEFINIDO. 1.1 Objetivo... 122 1.2 Justificativa... 13 1.3 Abrangência... 13 1.4 Estrutura do Trabalho... 13 2 TESTE DE SOFTWARE...ERRO! INDICADOR NÃO DEFINIDO. 2.1 Surgimento do Teste de Software... 15 2.2 Técnicas, Estágios e Tipos de Teste... 16 2.2.1 Técnicas de Teste... 16 2.2.2 Estágios de Teste... 17 2.2.3 Principais Tipos de Teste... 17 2.3 Técnicas de Validação de Requisitos... 19 2.3.1 Teste de Requisitos... 19 2.4 Processo de Verificação e Validação... 19 3 GERENCIAMENTO DE OCORRÊNCIAS...ERRO! INDICADOR NÃO DEFINIDO. 3.1 Testlink... 23 3.1.1 Projeto de Teste... 24 3.2 Mantis... 26 3.3 Integração entre Testlink e Mantis... 28 4 PROPOSTA DE MELHORIAS... 30 4.1 Pesquisa de Satisfação da Ferramenta Mantis... 30 4.2 Resultados da Pesquisa... 30 4.3 Descrição das Melhorias... 32 4.4 Soluções de Melhorias... 32 5. CONCLUSÃO... 33 6. TRABALHOS FUTUROS... 38 REFERÊNCIAS BIBLIOGRÁFICAS... 39 APÊNDICE A PESQUISA DE SATISFAÇÃO... 41 1 INTRODUÇÃO... 12 1.1 Objetivo... 12 1.2 Justificativa... 13 1.3 Abrangência... 13 1.4 Estrutura do Trabalho... 13 2 TESTE DE SOFTWARE... 15

2.1 Surgimento do Teste de Software... 15 2.2 Técnicas, Estágios e Tipos de Teste... 16 2.2.1 Técnicas de teste... 17 2.2.2 Estágios de teste... 17 2.2.3 Principais tipos de teste... 17 2.3 Técnicas de Validação de Requisitos... 19 2.3.1 Teste de requisitos... 19 2.4 Processo de Verificação e Validação... 20 3 GERENCIAMENTO DE OCORRÊNCIAS... 23 3.1 Testlink... 23 3.2 MANTIS... 26 3.3 Integração entre Testlink e Mantis... 28 4 LEVANTAMENTO DE MELHORIAS... 30 4.3 Descrição das Melhorias... 32 FONTE: (O AUTOR, 2010)... 34 4.4 Implementação das Melhorias... 34 5 CONCLUSÃO... 37 5.1 TRABALHOS FUTUROS... 37 REFERÊNCIAS BIBLIOGRAFICAS... 39 APÊNDICE A PESQUISA... 41 APÊNDICE B QUESTÕES DISSERTATIVAS... 42 APÊNDICE D MELHORAR INTEGRAÇÃO ENTRE AS FERRAMENTAS... 45 APÊNDICE E CUSTOMIZAR CAMPOS DA TELA DESCRIÇÃO... 46 APÊNDICE G MELHORAR A DESCRIÇÃO DA OCORRÊNCIA... 48

... 48 APÊNDICE H OBRIGAR INFORMAR VERSÃO DA APLICAÇÃO... 49 APÊNDICE I NUMERAR AS OCORRÊNCIAS POR PROJETO... 50

APÊNDICE M... 54 APÊNDICE N CRIAR CAMPO AMBIENTE... 55 APÊNDICE O CRIAR CAMPO NAVEGADOR... 56

12 1 INTRODUÇÃO O mercado na área de TI (Tecnologia da Informação) apresentou um crescimento considerável nas últimas décadas. De acordo com o Ministério da Ciência e Tecnologia (COMPUTERWORD, 2008), estima-se que o crescimento dessa área no Brasil será de 10% ao ano na próxima década e paralelo a esse crescimento está a necessidade de softwares de qualidade. Obter qualidade e agilidade nos processos e produtos de engenharia de software não é uma tarefa fácil. Existem vários fatores que dificultam atingir esses objetivos, como processo mal planejado, falta de organização, equipe desqualificada ou até mesmo falta de atenção para acompanhar a evolução dos requisitos. Além disso, a homologação do software com muitas indicações de ocorrências, ou até mesmo funcionalidades que não correspondem ao que foi solicitado pelo cliente, geram softwares de baixa qualidade. Atualmente, existem ferramentas com o propósito de apoiar o analista de qualidade com a modelagem e a execução do plano de testes e o gerenciamento de ocorrências. Esta última também com a finalidade de garantir o gerenciamento do desenvolvedor nas ocorrências e na qualidade do sistema. Essas ferramentas trazem várias vantagens, tais como: simplificação das atividades de teste, a dinamização da execução e uma melhor visibilidade sobre os projetos e métricas de qualidade estratégica. Existem excelentes ferramentas pagas (sharewares) no mercado, como o Rational TestManager da IBM (International Business Machines) e o Quality Center da HP (Hewlett-Packard). Porém, sabe-se que nem todas as empresas possuem um orçamento suficiente para adquirir tais ferramentas e buscam a solução em ferramentas não pagas (freewares) tais como Testlink e Mantis, que mesmo possuindo algumas carências em relação às sharewares, podem ser uma excelente escolha. 1.1 Objetivo O presente trabalho tem como objetivo propor melhorias na ferramenta de gestão de ocorrências de software Mantis, a partir de uma análise de usabilidade e

13 uma pesquisa com analistas de teste, buscando aperfeiçoar suas funcionalidades e simplificar seu uso. Junto às melhorias, são apresentados alguns modelos de qualidade de software, técnicas de teste e metodologias de desenvolvimento, proporcionando uma visão de como a qualidade é aplicada aos diferentes papéis do ciclo de desenvolvimento de software e como as ferramentas de gerenciamento de testes apóiam os desenvolvedores. 1.2 Justificativa Ao analisar o mercado e as ferramentas de gerenciamento de ocorrências disponíveis, principalmente as ferramentas não pagas (freewares), percebe-se algumas carências nessa área. Este trabalho visa suprir tais carências por meio da identificação e implementação de melhorias na ferramenta Mantis. 1.3 Abrangência O trabalho abrange a qualidade de software, mostrando o que é teste, tipos de testes e os processos dessa área. Ao longo do trabalho são especificados alguns modelos de testes, mas sem aprofundamento, pois o foco será o gerenciamento de ocorrências. Este trabalho não visa propor melhorias para a ferramenta Mantis mediante a análise de outras ferramentas de gerenciamento de ocorrências, mas sim com base em uma pesquisa realizada com testadores e desenvolvedores de softwares. O trabalho abrange o estudo da ferramenta Testlink, porém não especifica suas funcionalidades, mostrando apenas sua integração com o Mantis. 1.4 Estrutura do Trabalho O trabalho está estruturado em quatro capítulos. O capítulo dois reúne alguns conceitos do que é teste, descreve a história de como surgiram e a evolução das técnicas. Nesse capítulo será possível verificar também níveis, tipos e fases de

14 teste. O capítulo três discorre sobre as ferramentas de estudo deste trabalho, suas funcionalidades, maneiras de utilização, carências e qualidades. O quarto capítulo apresenta as melhorias identificadas por meio de uma pesquisa realizada com usuários da ferramenta e sua implementação. Por fim, o capítulo cinco apresenta os resultados deste trabalho, mostrando todas as dificuldades, aprendizados e conclusões.

15 2 TESTE DE SOFTWARE Conforme Myers (2004, p.36), o teste de software consiste em executar o programa de diversas maneiras com a intenção de encontrar ocorrências e defeitos. De acordo com o dicionário Michaelis, um teste é um exame crítico ou prova das qualidades, natureza ou comportamento de uma pessoa ou coisa. É exercitar ou simular a operação de um programa ou sistema. É confiar que um sistema faz o que se espera que ele faça. Testar é medir a qualidade e funcionalidade de um sistema. O teste não prova nada, mas deve reduzir o risco percebido de não trabalhar dentro de normas e valores aceitáveis (IBQTS, 2008, p.37) Tem-se uma série de regras definidas por Myers (2004) que servem como base dos objetivos de teste: executar um programa para descobrir ocorrências; projetar casos de testes com elevada probabilidade de revelar um erro ainda não descoberto; projetar testes que descobrirão sistematicamente diferentes classes de ocorrências com uma quantidade de tempo, esforço e custo mínimo; proporcionar uma boa indicação da qualidade e da confiabilidade do software; entregar um software de qualidade no menor tempo, com menor custo, para maiores lucros de negócios e satisfação de seus clientes. Deve demonstrar que as funções do software estão trabalhando de acordo com as especificações e que os requisitos de desempenho foram cumpridos. Além disso, os dados compilados quando a atividade de teste é executada proporcionam uma boa indicação da qualidade e confiabilidade do software como um todo. O teste de software busca reduzir os defeitos e ocorrências das aplicações testadas antes de finalizadas, evitando assim o retrabalho e custos adicionais. Uma metodologia de testes bem aplicada aumenta o índice de atendimento aos requisitos do cliente e melhora a qualidade dos sistemas entregues. Todo o processo de teste de softwares, em resumo, visa diminuir os custos e maximizar os lucros (IBQTS, 2008). 2.1 Surgimento do Teste de Software No início da era do computador, décadas de 1950 e 1960, a administração era responsável pelo desenvolvimento de sistemas, e estes eram orientados ao

16 hardware, visto que era o maior item do orçamento de projetos. O processo para determinar onde as melhorias poderiam ser implementadas era cuidadosamente analisado mediante controles, métodos e ferramentas que são conhecidos atualmente como engenharia de software. Nessa época, os projetos de desenvolvimento de software eram feitos com um vago indício das exigências do cliente e assim, a insatisfação deste com o sistema final era freqüente (PRESSMAN, 1995). Nos dias de hoje, a distribuição dos custos no desenvolvimento de sistemas computacionais mudou fortemente, sendo que o software passou a ser o item de maior custo e de maior importância (PRESSMAN, 1995). Muitas perguntas eram feitas na década passada como o porquê da demora da conclusão de um sistema, o motivo dos custos serem tão elevados, ou até mesmo o porquê de não se descobrir todos os erros antes de entregarem o software aos clientes. Essas questões, que mostraram uma manifestação de preocupação relativa ao software e a maneira pela qual ele era desenvolvido, levaram à adoção das práticas de engenharia de software. A busca pela qualidade dos sistemas computacionais foi evoluindo assim como a concorrência no mercado nas últimas décadas vem aumentando a cada dia. Assim, o entendimento da importância dos testes de software pelos gerentes surgiu e o investimento nessa etapa do desenvolvimento de sistemas passou a ser uma necessidade para o lucro da empresa (PRESSMAN, 1995). 2.2 Técnicas, Estágios e Tipos de Teste O teste de software consiste em avaliar as funções, características, tempos de resposta e interfaces dos sistemas. Para conseguir isso, os testes são implementados e executados com o seu objetivo e sua técnica de suporte específica. O foco de cada técnica está em testar uma ou mais características ou atributos do objetivo do teste (RIOS & MOREIRA, 2006).

17 2.2.1 Técnicas de teste Basicamente, as técnicas de testes podem ser classificadas como: Teste de Caixa-Preta: também chamado de teste funcional orientado a dado ou a entrada e saída. A técnica de caixa-preta avalia o comportamento externo do componente de software sem considerar o comportamento interno. Testa todas as entradas e saídas desejadas e não se preocupa com o código. Cada saída indesejada é visto como um erro (MYERS, 2004). Teste Caixa-Branca: também chamado de teste estrutural ou orientado à lógica. A técnica de caixa-branca avalia o comportamento interno do componente de software. O objetivo é testar o código (MYERS, 2004). Teste Caixa-Cinza: é a mistura das técnicas de caixa-preta com os de caixabranca. O analista de teste projeta os casos de teste a partir das estruturas de dados internos e algoritmos, avaliando o comportamento externo do software (MYERS, 2004). 2.2.2 Estágios de teste Segundo Rios & Moreira (2006) os estágios de teste podem ser classificados em três estágios distintos: Teste Geral: praticamente indispensável para o teste de qualquer aplicação em ambientes de grande porte. Teste Especializado: fundamental quando alguns testes específicos forem necessários, por exemplo, uma aplicação Web. Teste do Usuário: grupos de testes formados pelos usuários da aplicação. 2.2.3 Principais tipos de teste No mercado atual, existem vários tipos de testes: Unitário, Integração, Sistema, Regressão, Performance, Estresse, Segurança, Recuperação, Usabilidade,

18 Beta, Alpha, Aceitação, entre outros. A seguir são apresentados brevemente alguns dos principais tipos de teste e suas descrições (RIOS & MOREIRA, 2006): Teste de Unidade: também conhecido como teste unitário. Tem por objetivo explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de lógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Teste de Integração: visa buscar falhas associadas às interfaces entre os módulos quando estes são integrados para construir a estrutura do software que foi estabelecida na fase de projeto. Teste de Sistema: avalia o software em busca de falhas por meio de sua utilização, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos. Teste de Aceitação: são realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Conforme mostra a tabela 1, para cada estágio de teste existem tipos específicos de testes: Tabela 1 Estágios de Testes. Teste Geral Teste Especializado Teste do Usuário Unitário Performance Usabilidade Integração Estresse Beta Sistema Segurança Alfa Regressão Recuperação Aceitação FONTE: (RIOS & MOREIRA, 2006).

19 2.3 Técnicas de Validação de Requisitos De acordo com a visão de um analista de testes, ''um requisito é algo que o produto deve fazer ou alguma qualidade que deve apresentar'' (IBQTS, 2008, p.15). Para um testador um requisito é algo verificável que o produto deve fazer ou alguma qualidade mensurável que deve apresentar e que pelo seu risco de comprometer o sucesso do projeto compensa ser testado (IBQTS, 2008, p.15). Os requisitos se compõem de especificações, denominadas instrumentos, que se classificam em (IBQTS, 2008): Contratuais: configuram um compromisso quanto ao que o escopo alcança e a forma do produto a ser desenvolvido. De Gerência de Configuração: uma especificação deve definir uma configuração específica de um produto/sistema. De Engenharia de Softwares: comunicação entre cliente, produto, TI, fábrica de softwares, testes e produção; descrição e compreensão das necessidades operacionais, repositório das soluções técnicas empregadas, definição da arquitetura do produto, verificação e validação dos elementos do produto e verificação da completude do produto. 2.3.1 Teste de requisitos Por meio de um requisito funcional deve ser possível definir um ou mais testes a serem realizados no sistema final para verificar se o mesmo cumpre os requisitos na íntegra. Um requisito necessita ser classificado, pois irá criar problemas no desenvolvimento do produto IBQTS (2008). A validação de requisitos diz respeito à sua verificação quanto à consistência, completude e precisão. Deve demonstrar que estes definem o sistema que o cliente realmente deseja.

20 2.4 Processo de Verificação e Validação Um software de qualidade não pode ser construído sem a utilização de técnicas de teste e análise de software (PEZZÈ & YOUNG, 2008). O processo de planejamento de testes estabelece uma estrutura de padronização para esses procedimentos com a finalidade de melhor definir o que testar e como testar, quais as atividades a serem realizadas, quais artefatos devem ser usados, qual o papel de cada envolvido e as suas respectivas responsabilidades (SOMMERVILLE, 2003). O planejamento detalha os passos a serem tomados em um determinado projeto e esse plano deve responder às seguintes questões: quais atividades de qualidade devem ser executadas? Quais são as dependências entre as atividades de qualidade e as de desenvolvimento? Quais são os recursos necessários e como eles serão alocados? Como o produto e o processo serão monitorados para manter uma avaliação adequada da qualidade e avisar com antecedência sobre os problemas de qualidade e de cronograma? (PEZZÈ & YOUNG, 2008). Verificação e Validação, conhecidas como V&V ou modelo V, trata de processos que asseguram o cumprimento do software quanto à realização de suas atividades que foram designadas pelo cliente, ou seja, suas especificações. O processo V&V está presente em cada estágio do desenvolvimento do software, desde a revisão dos requisitos até os testes do produto final. Ambas as palavras se distinguem pelo fato de que, verificação está voltada para a checagem do software, quanto as suas especificações e requisitos (funcionais e não funcionais), e validação se o sistema funciona como o cliente solicitou, atendendo assim suas expectativas (SOMMERVILLE, 2003). De acordo com Boehm (apud SOMMERVILLE, 2003), duas perguntas descrevem simplificadamente a diferença entre essas palavras: Verificação: Estamos construindo certo o produto? Validação: Estamos construindo o produto certo?

21 A figura 1 responde de uma maneira simples essas duas perguntas. Figura 1 - Verificação e Validação. FONTE: (O Autor, 2010) Duas técnicas de checagem e análise de sistemas podem ser utilizadas no modelo V: Inspeções do Software, que pode ser aplicada em todos os estágios do processo do software e diz respeito à análise e à verificação de documentos de requisitos, diagramas e o próprio código-fonte do sistema; e Testes de Software, que trata da parte executável do sistema, com dados de teste para verificar se está sendo executado como o esperado. A finalidade definitiva do processo V&V está voltada para a confiança de que o software está adequado ao seu propósito, não significando que este deva estar inteiramente livre de defeitos. A função do sistema, as expectativas dos usuários e o atual ambiente de mercado definem o nível de confiança. A função do sistema descreve o quanto o software é importante na organização. As expectativas do usuário tratam de seu aceite quanto às falhas do sistema, mas atualmente sistemas não confiáveis estão deixando de ser aceitos, ou seja, as empresas estão se dedicando mais às atividades de verificação e validação. O ambiente de mercado leva em conta o preço, a concorrência e o cronograma para entrega do sistema, e esses fatores decidem quanto esforço se deve dedicar para a verificação e validação do software. As empresas que não estão dispostas a pagar um valor alto pelo sistema ficam sujeitas a ter que tolerar mais defeitos deste, visto que esse processo é dispendioso e que, em alguns casos, chega a ser metade do orçamento do desenvolvimento do software (SOMMERVILLE, 2003). A figura 2 demonstra o processo V&V, descreve o paralelismo entre as atividades de desenvolvimento e teste de software:

22 Figura 2 - Modelo V. FONTE: (CRAIG & JASKIEL, 2002). O planejamento e o projeto dos testes devem ocorrer de cima para baixo, ou seja, inicialmente é planejado o teste de aceitação com base no documento de requisitos, logo após, o teste de sistema é planejado a partir do projeto de alto nível do software, em seguida, ocorre o planejamento dos testes de integração junto ao projeto detalhado, e por fim, o planejamento dos testes baseado na codificação. (NETO, 2007).

23 3 GERENCIAMENTO DE OCORRÊNCIAS Para garantir que uma aplicação está de acordo com os requisitos definidos juntamente com cliente, se o software é considerado seguro, antes mesmo de entrar na linha de produção, é necessário realizar uma bateria de testes rigorosa. Conforme foi visto no capítulo anterior, há vários tipos de testes. A qualidade nos testes se tornou importante tanto para garantir se o que foi solicitado pelo cliente realmente está de acordo, quanto para assegurar a integridade dos dados. A relação custo/benefício é extremamente significante, na questão de retrabalho e manutenção de softwares, essa comparação fica em média para cada dólar investido em qualidade, as empresas economizam cinco dólares (GOMES, 2010). Como a qualidade se tornou tão importante, foram desenvolvidas várias ferramentas para auxiliar na gestão dos testes. Essas ferramentas têm como principal objetivo gerir os processos, casos de testes, modelar e acompanhar os testes. A seguir, serão consideradas duas ferramentas, o Mantis e o Testlink. 3.1 Testlink O Testlink é uma ferramenta Opensource, ou seja, tem o código fonte aberto, é acessado via browser e mantido pela Open Comunity Testers. Essa ferramenta tem como principal objetivo auxiliar todo o processo que engloba as fases de produção de um sistema, dependendo da metodologia de desenvolvimento utilizada. Porém, o Testlink é mais utilizado para criação e gerenciamento de casos de uso, bem como para organizá-los em planos de teste. A partir desses planos as pessoas responsáveis poderão executar casos de teste e consultar resultados de testes dinamicamente, gerar relatórios, rastreamento de requisitos de software, priorizar e atribuir tarefas (Testlink, 2010). Por ter uma interface extremante simples, o Testlink se integra facilmente com outras ferramentas que auxiliam no rastreamento de ocorrências e ainda possibilita que usuários possam adaptá-lo de acordo com suas necessidades. Por ser Opensource, os desenvolvedores podem adicionar, excluir ou alterar suas funcionalidades. No site da Testlink (www.testlink.org) são disponibilizadas

24 atualizações constantemente, junto com novas versões. Isso é muito importante, pois o usuário só irá atualizar o que for necessário para cada projeto. 3.1.1 Projeto de teste A ferramenta de gerenciamento Testlink tem uma estrutura para projetos bem completa. No momento que é criado um novo projeto de testes, a ferramenta automaticamente cria uma estrutura para deixar padronizado todo o projeto. Esse padrão pode ser bem visualizado na Figura 3. Figura 3 - Projeto de Teste. FONTE: (Testlink, 2010) Os componentes do projeto apresentados na figura 3 são descritos a seguir (Testlink, 2010): Test Project: é a unidade básica de organização do Testlink. Os Test Projets incluem Especificação de Teste, Requerimentos e Planejamento de Teste. Test Specification: A especificação de testes é a segunda fase no ciclo de vida da criação dos testes. Ela é criada a partir do plano de teste e tem como principal objetivo explicar como implementar os casos de teste descritos no plano de teste.

25 Requirements: para confirmar que um sistema está de acordo com o esperado pelo cliente, uma combinação de risco e uma análise baseada em requisitos para assegurar que um sistema é construído como especificado a partir da perspectiva do cliente e as partes interessadas. Test Plan: é a base para atividade de execução de teste. O plano de teste disponibilizado pelo Testlink possui várias informações de extrema importância para um analista de qualidade. Custom fields: no Testlink é possível atribuir campos personalizados, informando tamanho, tipo e se é obrigatório. A partir disso, o sistema automaticamente gera testes de máscara/limite para os mesmos. Users: os criadores do Plano de Testes poderão criar usuários dando as devidas permissões. Attachments: pode inserir um documento externo juntamente ao plano de teste. Reports: a aplicação disponibiliza ao usuário, relatórios ou gráficos. Esses relatórios têm como base de dados o plano de teste. Os relatórios podem ser gerados de várias formas, conforme a Tabela 2. Tabela 2 - Extensões aceitas para exportação. Tipo Modo de apresentação HTML (HyperText Markup Language) Apresentado numa página da internet (HTML) OpenOffice Writer Em modo texto OpenOffice Calc Em modo de tabela Microsoft Word Em modo texto Microsoft Excel Em modo tabela E-mail HTML Envia um HTML para o e-mail do usuário FONTE: (Testlink, 2010) Import/Export: existe a opção de importar ou exportar um projeto já existente ou

26 separadamente itens do projeto. Na Tabela 3 é possível visualizar o que pode ser importado e exportado nos formatos XML (Extensible Markup Language) e CSV (Comma Separated Values): Tabela 3 - Extensões de arquivo para importação. Item Formato Imp. Exp. Test Project XML X X Test Suíte XML X X Test Case XML X X Keyword CSV, XML X X Requeriments CSV, XML X X Result XML X FONTE: (Testlink, 2010) 3.2 Mantis Mantis é um sistema de gerenciamento de ocorrências baseado na web, desenvolvido inicialmente por Kenzaburo Ito, que criou uma ferramenta para controle de ocorrências, direcionada ao controle de animais, porém depois de uma adequação foi disponibilizado ao público por meio da GPL (General Public License). Em Novembro de 2002, Kenzaburo Ito se uniu com Jereon Latour, Victor Boctor e Julian Fitzell formando assim um núcleo de administradores e desenvolvedores (MANTIS, 2010). Com o tempo, ele amadureceu e ganhou popularidade, tornando-se a ferramenta Opensource para gerenciamento de ocorrências mais popular. O Mantis é desenvolvido em PHP (Hypertext Preprocessor) e utiliza banco de dados com suporte para múltiplos backends. Como possui o seu código aberto, permite aos usuários uma grande variedade de customizações, que inclusive, são incentivadas no arquivo principal do sistema. Um grande diferencial é sua disponibilidade em vários idiomas. Atualmente, o Mantis dispõe de seis níveis de usuário: Visualizador, Relator, Atualizador, Desenvolvedor, Gerente e Administrador. Cada qual possui diferentes

27 tipos de permissões. O Visualizador, por exemplo, possui a permissão de somente visualizar os registros de ocorrências efetuados. Os registros de ocorrências efetuados são delegados para um usuário. Automaticamente o sistema envia um e-mail para esse usuário informando que esse registro se encontra em sua responsabilidade. Após solucionar o problema, o usuário responsável deverá informar ao remetente para que o mesmo possa averiguar se o problema foi resolvido e assim atualizar o status. A figura 4 mostra o Fluxo de Erro, na visão do analista de teste (Relator) e do desenvolvedor (Desenvolvimento): Figura 4 Fluxo de erro. FONTE: (O autor, 2010) A figura 4 representa o caminho percorrido pelo relator e o desenvolvedor utilizando a ferramenta Mantis. O Relator deve cadastrar o erro, informando a descrição com o anexo da ocorrência encontrada, deve atribuir a ocorrência aberta ao desenvolvedor que está cadastrado na ferramenta. Após o desenvolvedor corrigir a ocorrência que foi aberta, o relator deve realizar reteste da ocorrência informando isso no Mantis, colocando como caso resolvido ou atribuindo novamente ao desenvolvedor informando que a ocorrência permanece. O desenvolvedor deve receber a ocorrência que foi aberta pelo relator, confirmar que isso é de fato um erro, confirmando e solucionando o problema aberto pelo analista de teste. Após a solução do problema que foi aberto pelo relator o desenvolvedor deve atribuir ao relator informando que a mesma está solucionada e disponível para teste. A figura 5 mostra o Fluxo de Dúvida, na visão do analista de teste e do

28 analista funcional: Figura 5 Fluxo de Dúvida. FONTE: (O Autor, 2010) A figura 5 representa o relator encontrando uma dúvida no caso de uso que foi disponibilizado, abrindo a ocorrência e informando o que ocorreu, atribuindo a um analista funcional que está cadastrado na ferramenta Mantis. Após o analista de negócio ver a dúvida que foi aberta, ele deve verificar e corrigir roteiro de teste caso necessário. O analista funcional deve receber a ocorrência que foi aberta pelo relator e verificar a dúvida e solucioná-la. Após solucionar a dúvida, ele deve atribuir novamente ao relator informando, no campo descrição, o problema que foi solucionado. 3.3 Integração entre Testlink e Mantis Como visto no item 3.2, o Testlink foi desenvolvido para gestão de casos de teste, uma visão para o analista de testes, que necessita de relatórios, andamento dos fluxos, controle dos testes executados e dos que serão executados. Já o Mantis, que foi criado basicamente para desenvolvedores, possui uma visão extremamente simples, somente com o que precisa ser corrigido. Para ter um sistema completo é necessária uma integração entre essas duas ferramentas. Primeiro o analista de testes insere o caso de teste no Testlink, preenche o campo Observação e clica na opção com falha, conforme a figura 6: