FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE TESTE DE SOFTWARE

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE TESTE DE SOFTWARE BRUNA TATIANE BONECHER BLUMENAU /2-05

2 BRUNA TATIANE BONECHER FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE TESTE DE SOFTWARE Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação Bacharelado. Profª. Fabiane Barreto Vavassori Benitti, Drª - Orientadora BLUMENAU /2-05

3 FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE TESTE DE SOFTWARE Por BRUNA TATIANE BONECHER Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Profª. Fabiane Barreto Vavassori Benitti, Drª Orientadora, FURB Prof. Everaldo Artur Grahl FURB Prof. Marcel Hugo FURB Blumenau, 11 de fevereiro de 2009

4 AGRADECIMENTOS A Deus, pela graça de chegar até aqui. A meus pais e minha irmã, pelo exemplo de família, pelo apoio e confiança e por me fazer entender a importância de prosseguir nos estudos. Ao meu noivo, por entender minha ausência durante a confecção deste trabalho, também pelo carinho e companheirismo ao longo desses anos todos. Aos meus amigos que me ajudaram, mesmo que indiretamente, na realização deste trabalho incentivando e apoiando sempre. À minha orientadora Fabiane, por ter acreditado na conclusão deste trabalho, por todo conhecimento transmitido ao longo desses meses e também pela dedicação com que me orientou. À empresa Dynamix Software, em especial Charles e Claumir, por apoiar desde o início este trabalho e por entender minhas ausências da empresa quando se fez necessário. A todos, meu muito obrigada!

5 RESUMO O presente trabalho faz um estudo sobre teste de software, abordando uma alternativa de processo de testes para utilização em empresas da região. O processo é baseado em outros processos existentes na literatura, como o OpenUP. Ele utiliza o padrão de documentação sugerido pela norma internacional IEEE-829. Diante deste foco é desenvolvida uma ferramenta WEB para automatizar as atividades e os artefatos do processo proposto, contemplando as etapas de planejamento e controle dos testes. Palavras-chave: Teste de software. Gerência. Planejamento. Processo de teste. Padrão IEEE- 829.

6 ABSTRACT This work is a study of test software, addressing an alternative process of testing for use in businesses in the region. The process is based on other processes in the literature, such as OpenUP. It uses the standard of documentation suggested by the International Standard IEEE In this outbreak is developed a web tool to automate activities and artifacts of the proposed process, including the stages of planning and control of the tests. Key-words: Software testing. Management. Planning. Process test. IEEE-829 standard.

7 LISTA DE ILUSTRAÇÕES Figura 1 Estágios de teste Figura 2 Modelo do ciclo de vida do processo de testes Quadro 1 Distribuição dos testes por etapas Figura 3 Modelo de integração entre os processos de desenvolvimento e teste Figura 4 Áreas de conteúdo Figura 5 Tarefas da disciplina de teste Figura 6 Papel do testador Figura 7 Relação entre os documentos de teste Figura 8 Notação e definição dos objetos Quadro 2 Comparativo entre as fases do processo Figura 9 Processo de testes na visão geral Figura 11 Subprocesso de execução de testes Figura 12 Layout do plano de testes Figura 13 Layout do caso de testes Figura 14 Layout do artefato de resultados dos testes Quadro 3 Requisitos funcionais Quadro 4 Requisitos não funcionais gerais Figura 15 Diagrama de caso de uso módulo administrativo Figura 16 Diagrama de caso de uso módulo operacional Figura 17 Modelo conceitual do sistema Figura 18 Modelo Entidade-Relacionamento Figura 19 Trecho do arquivo XML gerado Figura 20 Trecho do arquivo JSP com a estrutura da tela caso de teste Figura 21 Trecho do arquivo JSP com os eventos da tela Figura 22 Rotina de geração do relatório Figura 23 Parte do formulário de cadastro de pessoas no AGI Figura 24 Módulo administrativo com listagem de pessoas cadastradas Figura 25 Formulário de cadastro de pessoas Figura 26 Formulário de cadastro de sistemas Figura 27 Tela principal do módulo Operacional Figura 28 Formulário de cadastro de projeto... 54

8 Figura 29 Tela de cadastramento de plano de teste Figura 30 Listagem de pendências Figura 31 Planejamento de caso de teste Figura 32 Cadastramento do resultado da execução do teste Quadro 5 Tabela comparativa de artefatos Quadro 6 UC Quadro 7 UC Quadro 8 UC Quadro 9 UC Quadro 10 UC Quadro 11 UC Quadro 12 UC Quadro 13 UC Quadro 14 UC Quadro 15 UC Quadro 16 UC Quadro 17 Dicionário de dados Figura 33 Página 1 do relatório plano de teste Figura 34 Página 2 do relatório plano de teste Figura 35 Relatório de resultados da execução dos testes... 83

9 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA TESTE DE SOFTWARE Estágios de teste de software PROCESSO DE TESTE DE SOFTWARE Ciclo de vida do processo de teste OpenUP Metodologia de testes do CenPRA PADRÃO DE DOCUMENTAÇÃO IEEE Plano de testes Especificação do projeto de teste Especificação de caso de teste Especificação do procedimento de teste Diário de teste Relatório de incidentes de teste Relatório de sumário Relatório de encaminhamento de item de teste NOTAÇÃO PARA MODELAGEM DE PROCESSOS ORGANIZACIONAIS TRABALHOS CORRELATOS Infra-estrutura Maraká TestCen Sistema de gerenciamento de teste de software baseado na norma ISO/IEC DESENVOLVIMENTO DEFINIÇÃO DO PROCESSO Processo de testes atual da empresa Elaboração de um novo processo de testes Artefatos propostos para o processo REQUISITOS PRINCIPAIS ESPECIFICAÇÃO... 42

10 3.3.1 Diagramas de casos de uso Modelagem conceitual Modelo Entidade-Relacionamento IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Operacionalidade da implementação RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Detalhamento dos casos de uso APÊNDICE B Dicionário de dados do modelo entidade-relacionamento APÊNDICE C Relatórios finais de plano de testes e resultados de execução... 80

11 10 1 INTRODUÇÃO O teste, da maneira como é executado na maioria das empresas, é feito pelos próprios desenvolvedores de software, como sendo uma etapa dentro do processo de desenvolvimento, servindo apenas para garantir que as especificações ou os requisitos foram de fato implementados. Diante disso, como é possível garantir que o software testado pelos próprios desenvolvedores está corretamente testado? (BASTOS et al., 2007, p. 17). Para obter êxito na etapa de testes do software é preciso ter um processo de testes claramente definido, uma equipe de pessoas treinadas e qualificadas para assumir este papel e dispor de recursos e ferramentas adequadas para exercer a função. Nos dias atuais ainda existe uma deficiência muito grande no processo de teste de software nas organizações, tendo em vista que é ainda uma prática muito recente. Segundo Mats (2001 apud DIAS NETO; TRAVASSOS, 2006), os principais problemas nas atividades de teste de software são: a) atrasos no cronograma do projeto, deixando a equipe de teste impossibilitada de completar os testes planejados devido à redução de recursos e tempo; b) carência na rastreabilidade de casos de teste entre diferentes versões do sistema, dificultando o reuso e repetição dos testes após modificações dos requisitos; c) teste manual ou não-padronizado, resultando em um grande esforço a cada início de uma nova atividade de teste; d) incerteza sobre o que está sendo testado, devido à falta de definições dos objetivos e escopo para as atividades de teste; e) ausência de critérios para seleção dos casos de teste, definição de sua completude e estabelecimento de um ponto de parada, dentre outros, dificultando a revelação das falhas no produto. Dias Neto e Travassos (2006) afirmam que estes cinco problemas estão diretamente relacionados à ausência ou limitação das atividades de planejamento e controle dos testes de software. Para um bom planejamento de testes é preciso antes de tudo obter um processo bem definido, com objetivos claros, papéis e atividades estabelecidas de acordo com as necessidades. Diante disso, este trabalho propõe a elaboração de um processo e uma ferramenta com a finalidade de auxiliar no planejamento e controle de testes de software tais como testes de unidade, integração, sistema e de regressão. Desta forma, com a ferramenta desenvolvida, é

12 11 possível automatizar grande parte deste processo, facilitando e organizando o trabalho de gerentes de teste, desenvolvedores e testadores. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho é desenvolver uma ferramenta visando auxiliar no planejamento e controle dos testes de integração, sistema e regressão. Os objetivos específicos do trabalho são: a) definir um processo de testes observando o processo OpenUP, a metodologia desenvolvida por Crespo et al. (2004) e a real necessidade do setor de qualidade de uma empresa local de desenvolvimento de software; b) gerar artefatos de teste baseados no padrão IEEE ; c) disponibilizar funcionalidades para automatizar as atividades e artefatos do processo proposto, contemplando as etapas de planejamento e controle. 1.2 ESTRUTURA DO TRABALHO No segundo capítulo é feita uma revisão bibliográfica abordando os temas teste de software bem como suas fases, o conceito de processo de testes e os processos que servirão como base para o desenvolvimento deste trabalho, o padrão de documentação IEEE 829, uma notação utilizada para modelagem de processos e, por fim, descritas algumas ferramentas acadêmicas com funcionalidades semelhantes à ferramenta desenvolvida. O terceiro capítulo apresenta os requisitos do problema tratado no presente trabalho, assim como as especificações do software desenvolvido e a operacionalidade do mesmo demonstrando o seu uso prático. O quarto capítulo apresenta as conclusões e sugestões de extensão deste trabalho para trabalhos futuros. 1 IEEE é um padrão internacional de documentação de teste de software.

13 12 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são abordados temas como teste de software e o processo de testes, detalhando os processos OpenUP e o definido por Crespo et al. (2004), bem como as fases de teste existentes. Também é explorado o padrão de documentação IEEE bem como a notação utilizada para modelagem de processos definida por Villela, Travassos e Rocha (2004). Por fim, são descritas algumas ferramentas acadêmicas com funcionalidades semelhantes à ferramenta proposta. 2.1 TESTE DE SOFTWARE Segundo Myers (1979, p. 5), teste é o processo de executar um programa com o objetivo de encontrar erros. Um teste bem-sucedido identifica erros que ainda não foram descobertos, e que podem ser corrigidos ao longo do processo de desenvolvimento. Os defeitos existentes nos softwares, na maior parte das vezes, constituem-se em riscos tanto para o negócio quanto para a imagem da empresa. O objetivo do teste é minimizar os riscos causados por defeitos provenientes do processo de desenvolvimento (BASTOS et al., 2007, p. 17). Quando se trata de testes também está se referindo à qualidade do software. Não que sejam sinônimos, mas certamente o nível de qualidade dos testes de um software é um fator importante, entre outros, para definir a qualidade do produto final, que depende do processo de desenvolvimento deste software (MOREIRA FILHO; RIOS, 2003, p. 2). As atividades do processo de testes fazem parte do processo de desenvolvimento e influenciam a qualidade dos softwares, porém devido a pressões crescentes para liberações destes sistemas, estas atividades nem sempre são executadas com a eficiência que seria requerida. Além disso, tradicionalmente, os responsáveis por quase todos os estágios de teste são os próprios desenvolvedores e os usuários, ocultando o papel dos testadores no processo e assim fazendo com que, pela pouca experiência na área de testes, sistemas mal testados sejam liberados para o mercado (MOREIRA FILHO; RIOS, 2003, p. 2). Diante disso, o prejuízo final para as empresas torna-se exponencial. Conforme Black (1999 apud BASTOS et al., 2007), existe uma progressão do tipo dez, cem, mil se comparar

14 13 os custos dos defeitos encontrados na fase de projeto, codificação e produção respectivamente. Ainda que os testes iniciem na fase de projeto, mesmo assim não é possível garantir que todos os defeitos sejam encontrados, pois é impossível testar todas as possibilidades, devido a entrada de dados ser muito grande ou até mesmo infinita. No entanto, para garantir que o sistema funcione adequadamente ao entregá-lo ao cliente, é preciso passar por alguns estágios fundamentais de teste que, geralmente, ocorrem em paralelo com o processo de desenvolvimento Estágios de teste de software Conforme mencionado, o teste é executado em vários estágios ao longo do processo de desenvolvimento. Existem diversas literaturas que tratam estes estágios com nomenclaturas diferentes, porém, neste trabalho será utilizada a nomenclatura definida por Pfleeger (2004, p. 275), que trata os testes como sendo uma seqüência de estágios. O primeiro deles é o teste de unidade, que tem como foco as menores unidades de um programa, que podem ser funções, procedimentos, métodos ou classes. Neste contexto, identifica-se erros relacionados a algoritmos mal implementados, estruturas de dados incorretas ou simples erros de programação. Nesta fase, os testes são realizados pelos próprios desenvolvedores. (DELAMARO; MALDONADO; JINO, 2007, p. 4). Quando as menores unidades já tiverem sido testadas isoladas, o próximo estágio é o teste de integração, que consiste em verificar se os componentes do sistema, juntos, trabalham conforme está descrito nas especificações do sistema e do projeto do programa. Existem diversas estratégias para fazer a integração dos componentes, podendo citar a integração bottom-up 2, top-down 3, big-bang 4, entre outras. A estratégia de integração é escolhida geralmente dependendo das características e do tamanho do sistema a ser testado (PFLEEGER, 2004, p. 275). 2 Bottom-up: cada componente do nível inferior é testado sozinho e em seqüência, são testados os componentes chamados pelos que já foram testados (PFLEEGER, 2004, p.291). 3 Top-down: cada componente do nível superior é testado sozinho e em seqüência, são testados os componentes chamados pelos que já foram testados (PFLEEGER, 2004, p. 292). 4 Big-bang: combinação de todos os componentes, programas, módulos ou subsistemas de uma só vez (MOREIRA FILHO; RIOS, 2003, p. 14).

15 14 O próximo teste a ser feito é o teste de sistema, que tem como objetivo assegurar que o sistema faça o que o cliente quer que ele faça (PFLEEGER, 2004, p. 313). Tem como etapas o teste funcional, de desempenho, de aceitação e de instalação, embora em algumas literaturas o teste de aceitação e instalação sejam considerados à parte do teste de sistemas. O teste funcional avalia o sistema assegurando que ele tem a funcionalidade desejada, que as funções descritas nas especificações dos requisitos feitas pelo desenvolvedor são realmente realizadas pelo sistema integrado. Portanto, o resultado deverá ser um sistema em funcionamento de acordo com os requisitos especificados. O teste de desempenho visa garantir que o sistema atende aos níveis de desempenho e tempo de resposta acordados com o usuário e definidos nos requisitos. São também chamados de teste de performance (MOREIRA FILHO; RIOS, 2004, p. 16). O próximo estágio é chamado teste de aceitação, onde são realizados pelos usuários, visando verificar se a solução atende aos objetivos do negócio e a seus requisitos, no qual diz respeito a funcionalidade e usabilidade, antes da utilização no ambiente de produção (MOREIRA FILHO; RIOS, 2004, p. 15). Assim que o sistema é aceito, ele é instalado no ambiente em que será utilizado. Um teste de instalação final é, então, executado para assegurar que o sistema ainda funciona como devido (PFLEEGER, 2004, p. 276). A figura 1 ilustra a relação entre os estágios de teste dentro do processo de desenvolvimento de um software. Fonte: Pfleeger (2004, p. 276). Figura 1 Estágios de teste Ao final do processo de desenvolvimento podem surgir futuras manutenções no software que já está em cliente. Diante dessas correções é realizado o teste de regressão, que garante que os demais componentes do sistema continuam funcionando corretamente após as alterações realizadas.

16 PROCESSO DE TESTE DE SOFTWARE O processo de teste de software representa uma estruturação de etapas, atividades, artefatos, papéis e responsabilidades que buscam a padronização dos trabalhos e ampliar a organização e controle dos projetos de teste (BARTIÉ, 2007). Ao desenvolver um software, deve-se ter em mente a importância de uma metodologia de testes bem definida e estruturada. Desta maneira, têm-se os objetivos claros e, por conseqüência, uma visão das melhores técnicas para executar os testes. No entanto, o processo de testes deve executar em paralelo com o processo de desenvolvimento, garantindo desde o início a qualidade do software Ciclo de vida do processo de teste Para que os testes possam ser executados o quanto antes a fim de encontrar erros precocemente, eles precisam de um ciclo de vida. Este ciclo tem basicamente cinco fases principais: planejamento, preparação, especificação, execução e entrega, conforme mostrado na figura 2 a relação entre elas. Fonte: Moreira Filho e Rios (2003, p. 9). Figura 2 Modelo do ciclo de vida do processo de testes Cada fase demonstrada na figura 2 consome um percentual de tempo dentro do processo total. Este percentual foi retirado em função das experiências de mercado dos autores com a execução de testes, conforme mostra o quadro 1.

17 16 Etapas Planejamento Preparação 10% Especificação 40% Execução 45% Distribuição de tempo Calculado à parte e depois ajustado Entrega 5% Fonte: Bastos et al. (2007, p. 28). Quadro 1 Distribuição dos testes por etapas A definição das etapas apresentadas por Bastos et al. (2007, p ) é a seguinte: a) etapa de planejamento: consiste em elaborar uma estratégia de testes e o plano de teste a ser utilizado de modo a minimizar os riscos do negócio e fornecer os caminhos para as próximas etapas. Deve ser executado junto com a fase de captação dos requisitos e do planejamento do sistema a ser testado; b) etapa de preparação: o objetivo básico é preparar o ambiente de testes, com equipamentos, pessoal, ferramentas de automação, hardware e software, para que os testes sejam executados corretamente. É necessário em alguns casos que seja avaliado a necessidade de treinamento da equipe de testes sobre o projeto que se inicia; c) etapa de especificação: consiste basicamente em elaborar e revisar os casos de teste e os roteiros de teste. Isto deve ser feito dinamicamente durante o decorrer do projeto de teste, ou seja, na medida em que vão sendo liberados os recursos pelo desenvolvimento; d) etapa de execução: pode ser considerada a mais importante de todo o processo, pois é onde são executados os testes que foram planejados e registrados os resultados obtidos. Estes testes deverão ser executados de acordo com os casos de teste e os roteiros de teste. Deverão ser usados scripts caso seja utilizada alguma ferramenta de automação de testes. Os testes deverão ser executados sempre que surge alguma mudança de versão do programa que está em teste; e) etapa de entrega: é onde o projeto de testes é finalizado. Nesta fase se arquiva todos os artefatos produzidos e são relatadas todas as ocorrências que forem relevantes para a melhoria do processo, gerando assim um relatório de conformidades e não-conformidades. Para um melhor entendimento, na figura 3 é demonstrado como o processo de testes executa em paralelo com o processo de desenvolvimento e onde é executada cada fase desse processo.

18 17 Fonte: Moreira Filho e Rios (2003, p. 15). Figura 3 Modelo de integração entre os processos de desenvolvimento e teste Na seqüência, são apontados os dois processos que servem como base para o desenvolvimento deste trabalho OpenUP O OpenUP é um processo de desenvolvimento de software open source que tem como objetivo cobrir um grande conjunto de necessidades de desenvolvimento. Contém o conjunto mínimo de práticas que ajudam as equipes a serem mais eficazes no desenvolvimento de software (PEDRI, 2008, p. 27). Ele é uma versão otimizada da junção das metodologias Rational Unified Process (RUP) e extreme Programming (XP), sendo viável para aplicação

19 18 em projetos pequenos. A versão estudada do OpenUP é a 1.0, também chamada de OpenUP/Basic. Nela é definido um conjunto compacto de atores, tarefas e artefatos, onde atores realizam tarefas que utilizam e produzem artefatos. Este processo é dividido em princípios, áreas de conteúdo, disciplinas, atores e atividades. Ele é dirigido por quatro princípios centrais, que definem o processo por completo através da participação dos atores envolvidos, dos artefatos a serem produzidos e das tarefas a serem cumpridas no decorrer do ciclo de vida de desenvolvimento (BALDUINO, 2007, p. 1-2). De acordo com Balduino (2007, p. 2), os quatro princípios são: a) colaboração para alinhar interesses e compartilhar conhecimento; b) equilíbrio entre prioridades para maximizar o valor de stakeholders; c) foco na arquitetura antecipada para minimizar riscos e organizar o desenvolvimento; d) evolução de um contínuo feedback para aperfeiçoamento. As áreas de conteúdo são organizadas em quatro grandes grupos, também conhecidos como subprocessos: colaboração e comunicação, propósito, gerenciamento e solução. Essas áreas estão entrelaçadas entre as diferentes fases do desenvolvimento, suas atividades e tarefas, e são influenciadas pelos diferentes princípios anteriormente definidos. Cada área de conteúdo define aspectos importantes da participação dos atores no processo de desenvolvimento (CUNHA, 2007, p 35). Na figura 4 são relacionadas as áreas de conteúdo com os atores envolvidos.

20 19 Fonte: Pedri (2008, p. 51). Figura 4 Áreas de conteúdo De acordo com Balduinho (2007, p. 4), o OpenUP é focado nas seguintes disciplinas: análise e projeto, implementação, gerenciamento de projeto, gerenciamento de configurações e alterações, requisitos e teste. A disciplina de análise e projeto tem como principais objetivos transformar requisitos em projeto de software do futuro sistema, desenvolver uma arquitetura robusta para a solução e adaptar o projeto às características do ambiente de desenvolvimento. A disciplina de gerenciamento de configurações e alterações possui como objetivos manter um conjunto consistente dos produtos dos trabalhos realizados através de sua evolução, manter builds consistentes do software, prover maneiras eficientes de adaptar-se a mudanças e problemas e replanejar trabalhos e, por fim, prover dados para avaliação de progresso (CUNHA, 2007, p ). A disciplina de implementação está associada ao desenvolvimento das iterações do sistema cujos objetivos são verificar se as unidades técnicas utilizadas na construção do sistema funcionam como especificadas e desenvolver o produto final. A disciplina de gerenciamento de projeto tem como objetivos principais manter o foco da equipe no desenvolvimento do sistema e entrega do mesmo para avaliação dos stakeholders, criar um ambiente de alta produtividade, manter informados os stakeholders e equipe de projeto, prover framework para acompanhamento dos riscos e adaptação do projeto aos mesmos e priorizar a seqüencia de trabalhos (CUNHA, 2007, p ).

21 20 A disciplina de testes, foco deste trabalho, define um conjunto de atividades necessárias para planejamento, implementação, execução e avaliação de testes do sistema. Os principais objetivos são encontrar e documentar defeitos, validar que o software desenvolvido funciona como detalha seu projeto e validar que a implementação dos requisitos está de acordo com a definição dos mesmos. Conforme Cunha (2007, p ) esta disciplina está relacionada com as outras da seguinte maneira: a) requisitos: relaciona os requisitos do projeto para saber quais testes serão realizados; b) análise e projeto: relaciona o design do projeto, o que ajuda na definição dos tipos de testes que serão realizados; c) implementação: disponibiliza as builds para efetuar os testes; d) gerenciamento de projetos: descreve o artefato plano de iteração. Este artefato define a missão correta para avaliação da iteração; e) gerenciamento de configurações e alterações: os testes verificam se as mudanças efetuadas foram finalizadas apropriadamente. As propriedades dos testes são gerenciadas pela disciplina de gerenciamento de configurações. A figura 5 demonstra as tarefas da disciplina de testes, bem como os artefatos relacionados com a mesma. Fonte: OpenUP (2008). Figura 5 Tarefas da disciplina de teste Na fase de criação são analisados os casos de teste e gerados os scripts para testes automatizados. Na fase de executar os testes, as entradas são os scripts gerados e como saída

22 21 são obtidos os resultados dos scripts e a lista de itens trabalhados. Conforme Balduino (2007, p. 3-4), a habilidade necessária para pequenas equipes são representados pelos seguintes atores: analista, any role, arquiteto, desenvolvedor, gerente de projeto, stakeholder e testador. O analista tem como objetivos capturar e definir prioridades nos requisitos recolhidos a partir do entendimento dos problemas relatados pelos stakeholders. O any role é o nome que se dá a qualquer membro da equipe que realiza tarefas gerais, como por exemplo, enviar pedidos de alteração no projeto, participar de revisões e definições de prioridades, voluntário de trabalho em uma iteração particular, etc (OPENUP, 2008). O arquiteto coordena a criação do design técnico do sistema e é responsável pelas decisões de caráter técnico relacionado ao projeto. O desenvolvedor é o ator responsável pelo desenvolvimento de parte do sistema. O gerente de projeto é responsável pelo planejamento e avaliação de riscos do projeto, coordenação de iterações com os stakeholders e manter o foco da equipe para alcançar os objetivos do projeto. Os stakeholders representam o grupo de pessoas cujo conjunto de necessidades deve ser satisfeito ao final do projeto (OPENUP, 2008). O testador é responsável pelas principais tarefas relacionadas à área de testes. Ele deve identificar os testes que deverão ser realizados, identificar o modo mais apropriado para implementar cada teste, implementar testes individuais, configurar e executar testes, documentar e analisar os resultados dos testes e comunicar os resultados dos testes a todos os membros da equipe (CUNHA, 2007, p. 46). As tarefas em que o testador está apto a executar são: criar casos de teste, implementar e executar testes. Também é responsável pela criação e manutenção dos artefatos casos de teste, logs de teste e scripts de teste, conforme demonstrado na figura 6. Fonte: Pedri (2008, p. 55). Figura 6 Papel do testador Os casos de teste têm por objetivo fornecer uma maneira para capturar entradas de teste, condições e resultados esperados para um sistema. Deve também identificar sistematicamente aspectos do software a serem testados. Tem como objetivo ainda especificar se um resultado esperado foi alcançado baseado na verificação de um requisito do sistema,

23 22 grupo de requisitos ou cenário (OPENUP, 2008). Os registros de teste fornecem um registro detalhado, normalmente baseado no tempo, que serve como verificação de que um conjunto de testes foi executado, bem como fornece informações relacionadas ao sucesso dos testes. O foco normalmente está no fornecimento de uma trilha de auditoria exata, permitindo o diagnóstico, de pós-execução, das falhas a serem tratadas. Estes dados serão analisados posteriormente para ajudar a determinar os resultados de algum aspecto do esforço de teste. (OPENUP, 2008). Os scripts de teste contêm instruções passo a passo para realizar um teste, permitindo sua execução. Pode ter a forma de instruções textualmente documentadas que são executadas manualmente ou instruções interpretáveis pelo computador que permitem a execução automatizada de testes (OPENUP, 2008) Metodologia de testes do CenPRA Esta metodologia foi desenvolvida pelo Centro de Pesquisas Renato Archer (CenPRA), através do grupo de teste da Divisão de Melhoria de Processos de Software DMPS, com o objetivo de viabilizar a utilização das práticas de testes pelas empresas, englobando técnicas, procedimentos e ferramentas, capacitando-as a desenvolver produtos de melhor qualidade. Ela foi desenvolvida para que as empresas pudessem criar o processo de testes de acordo com as suas necessidades e disponibilidade de recursos, podendo ser aplicada a qualquer tipo de software, seja de sistemas de informação ou científico. A metodologia está fundamentada na adoção de um processo de testes e nos artefatos sugeridos pela Norma IEEE , que descreve os documentos que devem ser gerados nas atividades de gerência de teste de software. A implantação do processo de testes envolve um conjunto de atividades que vai desde o levantamento das necessidades da empresa, passa pela realização de treinamentos da equipe técnica e vai até o acompanhamento dos trabalhos realizados, constituindo assim um completo ciclo de implantação da atividade de teste dentro da empresa. Conforme Crespo et al. (2004), os três componentes fundamentais são: a) treinamento: através de cursos, consiste da capacitação em conceitos básicos sobre teste de software, técnicas de teste, documentação de teste e processo de teste. Estes cursos estão divididos em módulos e sua aplicação pode ser adaptada às necessidades específicas de cada empresa;

24 23 b) processo de teste: a metodologia define um processo genérico de teste que prevê a realização das atividades de planejamento, projeto, execução e acompanhamento dos testes de unidade, integração, sistemas e aceitação. A partir deste processo genérico cada empresa deve instanciar um processo específico que melhor atenda suas necessidades; c) suporte para geração de documentos: consiste da aplicação de uma técnica para a criação de documentos que serão utilizados para a gerência do processo de teste, tanto na fase de preparação para a atividade de teste quanto na fase de registro dos resultados do teste. Segundo Crespo et al. (2004), este processo genérico não contempla automação de teste, devido a necessidade de o processo ser simples, conforme a descrição inicial. Para que ele utilize de ferramentas, o processo deve estar convenientemente definido e consistentemente adotado, ou seja, a automação utilizando ferramentas obterá sucesso somente quando o processo já estiver maduro suficientemente para conseguir utilizá-las. 2.3 PADRÃO DE DOCUMENTAÇÃO IEEE O padrão de documentação IEEE-829 é um padrão conhecido mundialmente, podendo ser aplicado em softwares comerciais, científicos ou militares, independente do seu tamanho ou complexidade (THE INSTITUTE OF ELECTRICAL AND ELETRONICS ENGINEERS, 1998). O propósito do padrão IEEE-829, de forma resumida, é descrever o escopo, abordagem, recursos e cronograma das atividades de teste de software. Também tem como propósito identificar os itens a serem testados, as funcionalidades a serem testadas, as tarefas de teste a serem executadas, o pessoal responsável por cada tarefa e os riscos associados a esse plano (RIOS, 2008, p. 36). O padrão propõe que as instituições usem nos seus processos de teste de software um conjunto de documentos padronizados e organizados da seguinte forma (RIOS, 2008, p ): a) planejamento de teste: plano de teste; b) especificação de teste: projeto de teste, casos de teste e procedimentos de teste; c) relatório de teste: relatório de encaminhamento de itens de teste, relatório de log de

25 24 teste, relatório de incidente de teste e relatório de sumário de teste. A figura 7 ilustra a divisão das fases de preparação, execução e registro dos testes com seus respectivos documentos. Fonte: Crespo et al. (2004, p. 8). Figura 7 Relação entre os documentos de teste A seguir é descrito detalhadamente cada um destes documentos Plano de testes O plano de testes apresenta o planejamento para a execução do teste, incluindo a abrangência, a abordagem, os recursos e o cronograma das atividades de teste. Identifica os itens e as funcionalidades a serem testados, as tarefas a serem realizadas e os riscos associados com a atividade de teste, descrevendo ainda os diferentes ambientes que serão utilizados durante o teste. De acordo com The Institute of Electrical and Eletronics Engineers (1998), um plano de testes completo deve ter:

26 25 a) identificador; b) introdução; c) itens de teste; d) riscos do processo de teste; e) recursos que serão testados do ponto de vista do usuário; f) recursos que não serão testados do ponto de vista do usuário; g) abordagem (estratégia) dos testes; h) critério de conclusão dos testes; i) critério para interrupção e retomada dos testes; j) entregas (Plano de Teste, Casos de teste, etc); k) ambiente de teste; l) responsabilidades; m) pessoal (equipe, treinamento, local); n) cronograma; o) plano de riscos e contingências; p) aprovação dos testes Especificação do projeto de teste A tarefa de elaboração do teste é coberta pelos documentos de especificação de projeto de teste, especificação de casos de teste e especificação do procedimento de teste. O documento de especificação de projeto de teste trata-se de um detalhamento da abordagem apresentada no Plano de Teste que identifica as funcionalidades e as características a serem testadas pelo projeto. Este documento também aponta os casos e os procedimentos de teste, se existirem, e apresenta os critérios de aprovação. De acordo com The Institute of Electrical and Eletronics Engineers (1998), o projeto de teste deve ter a seguinte estrutura: a) identificador de especificação do projeto de teste; b) recursos que serão testados; c) abordagem dos testes; d) casos de teste com a sua respectiva identificação; e) critério de conclusão dos testes.

27 Especificação de caso de teste Este documento define os casos de teste, o que inclui os dados de entrada, os resultados esperados, as ações e as condições gerais para a execução do teste. Geralmente, utiliza-se a nomenclatura de Plano de Caso de Teste para esse documento gerado. De acordo com The Institute of Electrical and Eletronics Engineers (1998), um Plano de caso de teste deve conter: a) identificador; b) identificação dos casos de teste (o que testar); c) especificações de entrada; d) especificações de saída; e) requisitos ou procedimentos especiais; f) necessidades de ambiente; g) dependências entre casos de teste Especificação do procedimento de teste Identifica todos os passos necessários para a operação do sistema e o exercício dos casos de teste especificados, de maneira a cobrir o projeto de teste planejado. Os procedimentos de teste formam um documento separado, que se espera que seja seguido passo a passo, sem imprevistos. De acordo com The Institute of Electrical and Eletronics Engineers (1998), a estrutura básica desse documento é: a) identificador; b) propósito; c) requisitos especiais; d) passos do procedimento Diário de teste O diário de teste, também conhecido como relatório de log de teste, tem como propósito básico descrever tudo de relevante que ocorre durante o projeto de teste, de tal

28 27 modo que seja um documento básico de registro de todas as atividades desenvolvidas e outras ocorrências. O log pode ser considerado um diário de ocorrências da atividade de execução dos testes. De acordo com The Institute of Electrical and Eletronics Engineers (1998), os itens que compõe este documento são: a) identificador; b) descrição; c) atividades e eventos: - descrição da execução (identificar o que foi executado), - resultados (mensagens, requisições operacionais, etc), - informações sobre o ambiente, - eventos anormais (conexão com o relatório de incidentes) Relatório de incidentes de teste O propósito do relatório de incidentes é documentar qualquer evento que ocorra durante a execução dos testes que requeira algum tipo de investigação ou correção pela outra parte envolvida. Em algumas empresas este relatório tem o nome de Relatório de Defeitos. Segundo The Institute of Electrical and Eletronics Engineers (1998), o conteúdo básico deste relatório é: a) identificador; b) sumário da ocorrência; c) descrição do incidente; d) impacto Relatório de sumário Também conhecido como relatório-resumo, tem como objetivo fornecer um sumário das atividades de teste realizadas durante um determinado projeto e mostrar resumidamente as ocorrências durante todas as atividades realizadas. Este relatório costuma fechar o projeto de teste. Conforme The Institute of Electrical and Eletronics Engineers (1998), este relatório deve ter o seguinte conteúdo básico: a) identificador;

29 28 b) sumário; c) variações; d) avaliações do processo; e) sumário dos resultados; f) avaliação do teste; g) sumário de atividades; h) aprovação Relatório de encaminhamento de item de teste Este relatório identifica os itens encaminhados para teste no caso de equipes distintas serem responsáveis pelas tarefas de desenvolvimento e de teste. De acordo com The Institute of Electrical and Eletronics Engineers (1998), os itens que compõe este relatório são: a) identificador do relatório de encaminhamento; b) itens encaminhados; c) localização; d) estado; e) aprovações. 2.4 NOTAÇÃO PARA MODELAGEM DE PROCESSOS ORGANIZACIONAIS A notação proposta por Villela, Travassos e Rocha (2004) surgiu como necessidade para implantar uma gerência de conhecimento em ambientes de desenvolvimento de software, que consiste em disponibilizar para o desenvolvedor de software, dentro do seu contexto de trabalho, o conhecimento adquirido ao longo de vários projetos e que este possa contribuir diretamente para a geração de outros conhecimentos a serem utilizados em novos projetos. Conforme a notação proposta por Villela, Travassos e Rocha (2004), nesta modelagem é utilizada uma linguagem gráfica que foi motivada pelo fato de linguagens existentes não contemplarem a representação dos conhecimentos requeridos ou possuírem um conjunto excessivo de objetos, muitas vezes desnecessários e complexos. A linguagem é composta de elementos gráficos dos tipos área, objeto e ligação, sendo

30 29 que a ligação estabelece a relação entre dois objetos e a área agrupa os objetos definindo assim um contexto para os mesmos. Na figura 8 são apresentados os elementos gráficos que compõe o processo bem como suas respectivas descrições. A modelagem definida por Villela, Travassos e Rocha (2004) aborda várias outras representações gráficas, porém são detalhados apenas os elementos utilizados na modelagem do processo definido neste trabalho. Fonte: adaptado de Villela, Travassos e Rocha (2004). Figura 8 Notação e definição dos objetos Conforme visto na representação gráfica, define-se neste contexto: a) processo: representa o conjunto de etapas a serem seguidas regularmente desde o início até o fechamento do projeto; b) ator: uma pessoa, agente ou unidade organizacional que está inserido no contexto do processo;

31 30 c) atividades: é a ação de transformação que pode requerer competências para a sua execução e, ao ser executada, faz uso de recurso, consome artefatos de entrada, além de produzir artefatos de saída. d) artefatos do processo: são todos os documentos gerados pelo mesmo e que são geralmente os resultados (saídas) das atividades; e) ligação de dependência entre atividades: representa a dependência entre duas atividades distintas; f) fluxo de entrada e saída: representa as entradas e saídas do processo. Geralmente apontam para artefatos pertencentes ao processo; g) área do processo: área que define o processo, ou subprocesso, agrupando atividades executadas por um ou mais atores. 2.5 TRABALHOS CORRELATOS Existem ferramentas que visam objetivo semelhante o do trabalho proposto, dentre elas estão a infra-estrutura Maraká (DIAS NETO; TRAVASSOS, 2006), a ferramenta TestCen (BIANCHINI, 2004) e o sistema de gerenciamento de teste de software baseado na norma ISO/IEC (SANDER, 2002) Infra-estrutura Maraká Esta infra-estrutura tem por objetivo apoiar o planejamento e controle dos testes de software e foi desenvolvida a partir de requisitos extraídos de resultados obtidos em um survey 5, onde foi avaliado o estado da prática das atividades de teste de software em um cenário real de desenvolvimento de software. Maraká foi desenvolvida em ambiente web e permite acompanhar o processo de teste de software e a documentação das atividades realizadas ao longo dos testes. O controle das atividades de teste é feitos através de artefatos 6 que descrevem gráficos de acompanhamento, 5 Survey, palavra da língua inglesa que tem por significado fazer um levantamento de dados, pesquisa. 6 Artefatos, neste contexto, são documentos gerados durante um processo de teste de software.

32 31 cronogramas e outras informações sobre os testes TestCen A principal característica desta ferramenta é o suporte ao planejamento, controle, execução e a documentação de testes baseado em cenários de caso de uso. É utilizada a UML para geração de casos de teste funcionais a partir dos casos de uso. Para isso, foi modificada a ferramenta CASE ArgoUML para incluir extensões apropriadas a casos de testes e, posteriormente, desenvolvida a ferramenta TestCen para permitir a leitura destas extensões e documentar os testes seguindo orientações previstas no padrão IEEE que trata da documentação de testes de software. A aplicação foi desenvolvida utilizando a linguagem Object Pascal no ambiente Delphi Sistema de gerenciamento de teste de software baseado na norma ISO/IEC A ferramenta foi desenvolvida em ambiente DataFlex e tem como objetivo o suporte ao gerenciamento do teste de software com base nas recomendações existentes na norma ISO/IEC para o processo de gerência e para as atividades de teste. Tem como propósito auxiliar o gerenciamento do processo de teste. Apresenta um roteiro para planejamento da atividade de teste e possibilita o controle através do registro dos resultados de teste. Pode ser aplicado a diversos modelos de ciclo de vida, de acordo com os requisitos de cada projeto de software. O plano de teste deve ser mantido pelo gerente de teste e pode ser configurado de acordo com a fase do ciclo de vida do produto, atividade de teste, módulo a ser testado, domínio e ambiente de teste. Para cada plano devem ser designadas as ferramentas, procedimentos e casos de teste a serem utilizados pelo funcionário responsável pela execução do teste. Após a execução, o funcionário que executou o teste irá registrar o resultado de teste para cada ferramenta, procedimento e caso de teste, além de emitir uma avaliação geral para o teste do produto. Tanto o plano quanto o resultado são gravados num banco de dados, possibilitando a emissão de relatórios, imediatos ou futuros, para controle e documentação.

33 32 3 DESENVOLVIMENTO Para se cumprir o desenvolvimento da ferramenta proposta foram realizados os seguintes passos: a) definição de um processo de testes (seção 3.1); b) especificação dos requisitos do problema (seção 3.2); c) especificação da ferramenta através de diagramas de casos de uso, modelo conceitual e modelo Entidade-Relacionamento (MER) (seção 3.3); d) implementação da ferramenta (seção 3.4). 3.1 DEFINIÇÃO DO PROCESSO Para que fosse possível o desenvolvimento de um novo processo de teste o primeiro passo foi a coleta de informações sobre o processo atual da empresa em questão. Após a análise das necessidades encontradas no processo atual foi desenvolvido um novo processo observando essas necessidades e levando em consideração as metodologias de teste estudadas neste trabalho Processo de testes atual da empresa O processo de testes atual da empresa envolve dois papéis fundamentais, o desenvolvedor e o testador. Ele inicia quando o desenvolvedor termina de executar uma atividade de implementação e disponibiliza o sistema que sofreu alterações em um servidor local na empresa para testes e também elabora um roteiro com os testes que devem ser realizados. Depois de elaborado o roteiro, o desenvolvedor solicita a equipe de testes que sejam feitos os testes daquela atividade desenvolvida. Uma pessoa responsável da equipe de testes abre o roteiro de testes da atividade e executa os testes conforme indicado no documento. Ao terminar os testes, o testador cria um novo documento contendo informações da atividade que foi testada, bem como o resultado dos testes da mesma. Terminado essa etapa do processo, o testador comunica ao

34 33 desenvolvedor responsável que os testes foram realizados. O desenvolvedor então confere o documento com os resultados dos testes e, caso eles estejam sem erros, o desenvolvedor implanta a atividade no servidor do cliente para homologação do mesmo. Caso durante o processo de teste algum erro tenha sido detectado, o desenvolvedor corrige os erros encontrados e repete todo o processo novamente. Para a realização deste processo, a empresa conta com uma ferramenta gestora de projetos chamada Tetra, que faz a comunicação entre o desenvolvimento e o setor de testes quando há novos testes a executar ou atividades a corrigir. Para a criação dos artefatos é utilizado o editor de texto Microsoft Word Elaboração de um novo processo de testes O processo de testes definido neste trabalho baseou-se na especificação apresentada por Bastos et al. (2007, p ), onde ele contempla cinco fases principais do ciclo de vida de um processo de testes: planejamento, preparação, especificação, execução e entrega. No entanto, como um dos objetivos deste trabalho é a inserção do processo de testes em uma empresa de pequeno porte, optou-se por resumir estas fases em apenas duas fases gerais, porém, abrangendo indiretamente todas as cinco fases mencionadas. No quadro 2 tem-se uma comparação entre as fases do processo definido por Bastos et al. (2007, p ) e o processo proposto neste trabalho, onde pode-se observar que as fases de planejamento, preparação e especificação do processo definido por Bastos et al. (2007, p ) corresponde a uma única fase do processo proposto, a de planejamento, e as fases de execução e entrega são correspondentes a fase de execução. Fases por Bastos et al. (2007, p. Fases do processo proposto 46 47) Planejamento Planejamento Preparação Especificação Execução Execução Entrega Quadro 2 Comparativo entre as fases do processo Seguindo a notação proposta por Villela, Travassos e Rocha (2004), na figura 9 é apresentado o processo proposto, o qual é composto por duas etapas, planejamento e execução, que também podem ser chamadas de subprocessos.

35 34 Processo de testes Planejamento Execução Figura 9 Processo de testes na visão geral Conforme mostra na figura 9, a fase de execução dos testes é inteiramente dependente da fase de planejamento. O motivo desta dependência é pelo fato de não ser possível executar um teste sem que ele primeiramente seja planejado e criado seus roteiros de teste. A fase de planejamento consiste em elaborar os planos de teste. Ela deve iniciar junto com a fase de elicitação dos requisitos e do planejamento do sistema a ser testado a fim de prevenir e minimizar riscos no projeto e também para saber os passos a serem seguidos adiante. Na fase de planejamento também é onde se prepara os ambientes de teste, pessoal, ferramentas, hardware, etc. No decorrer do projeto, ainda na fase de planejamento são especificados os casos de teste necessários para execução, onde é descrito um passo-a-passo dos testes a serem executados. Na figura 10 é apresentada a fase de planejamento seguindo a notação de representação de processos proposta por Villela, Travassos e Rocha (2004). Planejamento dos testes Plano de teste Casos de teste Analista Criar plano de testes Criar casos de testes Figura 10 Subprocesso de planejamento de testes A fase de execução consiste basicamente em executar os casos de teste gerados na fase de planejamento e registrar seus resultados em um artefato de resultados dos testes para que, de acordo com o resultado, o projeto possa ser entregue ao cliente final ou corrigir eventuais erros quando houver. Na figura 11 é apresentada a fase de execução dos testes.

36 35 Execução dos testes Casos de teste Testador Executar testes Registrar resultados Resultado dos testes Figura 11 Subprocesso de execução de testes De acordo com o detalhamento das fases do processo, existem dois papéis que executam as atividades correspondentes: analista e testador. O analista é o responsável pelo planejamento e especificação dos testes e o testador tem a responsabilidade de executar os testes e registrar os resultados obtidos. Para que o processo possa ser completo, ele deve ainda empregar um conjunto de artefatos a fim de registrar as informações importantes dos testes do projeto. Na seção seguinte são detalhados os itens de cada artefato proposto no processo bem como descrito a utilidade de cada um deles Artefatos propostos para o processo De acordo com a necessidade de registrar informações durante o processo de testes, foi especificado os documentos que serão incorporados neste processo baseando-se nos artefatos da norma IEEE-829 e nos documentos da metodologia OpenUP da disciplina de testes. Conforme visto nas figuras 10 e 11, as etapas de planejamento e execução contemplam a geração de três artefatos: plano de teste, caso de teste e resultado dos testes. Os artefatos plano de teste e caso de teste fazem parte da etapa de planejamento, e o artefato de resultado dos testes da etapa de execução. O plano de testes é o artefato onde se registra o planejamento de todos os testes a serem realizados em um novo projeto. Na figura 12 é apresentado o layout do plano de testes a ser utilizado no processo.

37 36 Figura 12 Layout do plano de testes Conforme observado, o plano de testes é composto por: a) identificador: é o título do plano de testes; b) projeto: nome do projeto a qual o plano de testes pertence; c) cliente solicitante: o nome do cliente solicitante do projeto a qual pertence o plano de testes; d) responsável: pessoa responsável pela elaboração do plano de testes; e) data: data em que foi elaborado o plano de testes; f) introdução: descrever brevemente do que se trata o projeto; g) esforço: informar, em horas, a quantidade de tempo prevista para planejar e executar os testes; h) ambiente de teste: descrever o ambiente em que serão executados os testes, hardware e software utilizados, etc.; i) cronograma: especificar um cronograma de atividades previstas no plano; j) riscos: descrever os possíveis riscos; k) limitações: descrever limitações nos testes, caso houver; l) itens a serem testados: para cada item a ser testado, informar uma breve descrição do caso de testes a ser elaborado posteriormente, atribuir os responsáveis pelo planejamento e execução do futuro caso de teste. O caso de teste é o artefato onde se registra o detalhamento passo a passo da execução de um teste em específico. Na figura 13 é apresentado o layout do caso de testes desenvolvido.

38 37 Figura 13 Layout do caso de testes Conforme a figura 13, o caso de testes é composto por: a) identificador: descrição que identifica o caso de testes; b) responsável planejamento: pessoa responsável por planejar o caso de teste; c) responsável execução: pessoa responsável por executar o caso de teste; d) data: data em que foi elaborado o caso de testes; e) baseado no UC/requisito: identificação do caso de uso ou requisito em que foi baseado o caso de teste; f) pré-condições: caso houver, identificar uma pré-condição para que o teste em questão possa ser realizado com sucesso; g) pós-condições: caso houver, identificar uma condição que ocorrerá após a execução do teste em questão; h) plano de teste: informa a qual plano de teste pertence o caso de teste em questão; i) sistema: selecionar o sistema ou módulo que será testado; j) passos do teste: para cada passo informar a descrição do passo bem como o resultado esperado dessa execução. O artefato de resultados dos testes é onde se registra os resultados dos casos de teste executados. Cada plano de teste deve ter pelo menos um artefato de resultado dos testes para que o processo possa estar completo. Na figura 14 é apresentado o layout deste artefato desenvolvido.

39 38 Figura 14 Layout do artefato de resultados dos testes O artefato de resultados é composto por: a) identificador: campo que identifica o artefato; b) plano de teste: indica qual plano de teste está sendo gerado os resultados; c) projeto: de qual projeto os testes são referentes; d) cliente: cliente solicitante do projeto; e) data: data de registro do artefato de resultados; f) responsável pela criação: nome do responsável por preencher o artefato de resultados dos testes; g) tabela de itens testados: para cada item testado, informar em qual caso de teste o teste foi baseado, a data de conclusão da execução do caso de teste, a situação de execução (se executou com erros ou não), a descrição do incidente caso houver, o impacto do erro caso houver, e a classificação do erro se for registrado um erro. 3.2 REQUISITOS PRINCIPAIS A seguir são especificados os requisitos funcionais e não-funcionais da ferramenta desenvolvida. A notação para representação de requisitos segue o modelo apresentado por Wazlawick (2004, p. 38), que afirma que os requisitos são classificados em duas grandes categorias: a) os requisitos funcionais, que correspondem a listagem de tudo que o sistema deve fazer. Eles podem ser classificados em dois grupos: - requisitos funcionais evidentes, que são efetuados com conhecimento do usuário, - requisitos funcionais ocultos, que são efetuados pelo sistema sem o conhecimento explícito do usuário.

40 39 b) os requisitos não-funcionais, que são as restrições colocadas sobre como o sistema deve realizar seus requisitos funcionais. Eles podem ser classificados em: - categoria de atributos: indica a categoria do requisito, por exemplo, de interface, de implementação, de eficiência, - obrigatório: indica se o requisito deve ser obrigatório ou desejável, - permanente: indica se o requisito nunca mudará com o tempo, ou se será transitório, que sofrerá mudanças no futuro. Os requisitos não funcionais que não se adequarem em nenhum requisito funcional são separados em uma tabela chamada de requisitos não funcionais gerais, ou ainda requisitos suplementares. No quadro 3 são apresentados os requisitos funcionais do sistema e no quadro 4 os requisitos não funcionais gerais. Requisitos funcionais RF.01 O sistema deverá permitir criar/alterar/excluir logins de acesso. Descrição Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais O sistema deverá permitir o cadastro de novos membros da equipe no sistema bem como alterar os dados de logins já existentes ou excluí-los. Nº Restrição Categoria Obrigatório Permanente A função de criação/exclusão dos logins somente pode ser acessada pelo módulo administrativo A função de alteração dos dados do login poderá ser acessada pelos analistas/testadores para alterar seus respectivos dados Deverá ser cadastrada uma senha para o login. A senha poderá seguir qualquer formato, desde que não seja nula O sistema deverá ter um controle de acesso para os logins O sistema terá um mecanismo de filtro no módulo operacional indicando por usuário logado qual o plano de teste ativo. RF.02 O sistema deverá permitir manter os sistemas. Descrição Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Segurança Sim Sim Segurança Sim Sim Interface Sim Sim Segurança Sim Sim Usabilidade Não Sim O sistema deverá permitir a inserção/alteração/exclusão dos sistemas que serão testados. Nº Restrição Categoria Obrigatório Permanente O acesso à função de manter os sistemas deverá funcionar no módulo administrativo RF.03 O sistema deverá permitir manter os projetos. Descrição Segurança Sim Sim O sistema deverá permitir a inserção/alteração de projetos bem como suas

41 40 principais informações. Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Nº Restrição Categoria Obrigatório Permanente Somente poderá cadastrar um projeto se tiver um sistema pré-cadastrado A função de manter os projetos estará disponível para o módulo Operacional, a fim de que os analistas e testadores possam gerenciar esta função. RF.04 O sistema deverá permitir manter planos de teste. Descrição Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Especificaçã o Sim Sim Usabilidade Sim Sim O sistema deverá permitir a inserção/alteração de planos de teste de acordo com o projeto especificado. Nº Restrição Categoria Obrigatório Permanente Somente poderá cadastrar um plano de teste se tiver um projeto pré-cadastrado Um projeto poderá ter mais de um plano de teste, conforme a necessidade Um plano de testes deverá permitir pré-cadastrar um caso de teste bem como seus respectivos responsáveis por planejamento e execução do mesmo. RF.05 O sistema deverá permitir manter os casos de teste. Descrição Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Especificação Sim Sim Especificação Sim Sim Usabilidade Não Sim O sistema deverá permitir a inserção/alteração/exclusão de casos de teste. Nº Restrição Categoria Obrigatório Permanente O caso de teste deve ser obrigatoriamente correspondente a um plano de teste O caso de teste deve atribuir novas atividades aos analistas e testadores de planejamento e execução dos casos de teste O caso de teste pode ter vinculado a ele figuras para demonstração do teste. RF.06 O sistema deverá permitir manter os resultados dos testes. Descrição Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Especificação Sim Sim Especificação Sim Sim Especificação Não Sim O sistema deverá permitir inserir/alterar/excluir os resultados dos testes de um determinado plano de testes. Nº Restrição Categoria Obrigatório Permanente Somente poderá cadastrar resultados se houver previamente cadastrado pelo menos 1 plano de testes Poderá haver mais de um resultado para o mesmo plano de teste. Especificação Sim Sim Especificação Sim Sim

42 41 RF.07 O sistema deverá permitir a visualização e execução das atividades de teste pendentes. Descrição O sistema deverá permitir visualizar e executar as atividades de teste pendentes de responsabilidade dos analistas e testadores. Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Nº Restrição Categoria Obrigatóri o Permanente O sistema permite visualizar todas as atividades de testes pendentes no sistema, não restringindo a visualização por usuário As atividades pendentes podem ser de: - planejamento de caso de teste; - execução de casos de teste; Usabilidade Sim Sim Especificação Sim Sim RF.08 O sistema deverá permitir gerar documentos do processo de testes. Descrição O sistema deverá permitir salvar (exportar) os artefatos cadastrados de plano de teste, casos de teste e resultados de execução de teste. Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Nº Restrição Categoria Obrigatório Permanente Os artefatos poderão ser salvos em vários formatos como.pdf,.odt, etc. Interface Não Sim Será permitida a impressão dos artefatos. Interface Não Sim Os artefatos são baseados na norma IEEE-829 e nos artefatos do OpenUP. Especificação Sim Sim RF.09 O sistema deverá permitir manter as classificações de erro. Descrição O sistema deverá permitir a inserção/alteração/exclusão das classificações de erro. Categoria funcional Evidente ( x) Oculto ( ) Requisitos não funcionais Nº Restrição Categoria Obrigatório Permanente Esta classificação será mantida no módulo Administrativo. Segurança Sim Sim Será gerado um relatório gráfico com as estatísticas de classificação de erro. Quadro 3 Requisitos funcionais Usabilidade Não Sim

43 42 Requisitos não funcionais gerais Nº Restrição Categoria Obrigatório Permanente RNF.01 O sistema será desenvolvido usando a linguagem Java Server Page (JSP). RNF.02 O sistema deverá usar o banco de dados MySQL. RNF.03 Os módulos que contemplam o sistema são: 1. Administrativo responsável por manter os sistemas, logins de acesso, classificação de erros e controle de acesso aos artefatos; 2. Operacional executa as atividades de planejamento e execução de testes bem como o cadastramento dos projetos no sistema. RNF.04 As interfaces do sistema devem ser implementadas com formulários acessíveis nos browser homologados Firefox 2 e 3 e Internet Explorer 7. Implementação Sim Não Implementação Sim Não Segurança Sim Sim Interface Sim Sim RNF.05 O sistema deverá utilizar o servidor WEB Apache Tomcat. Implementação Sim Sim Quadro 4 Requisitos não funcionais gerais 3.3 ESPECIFICAÇÃO Foi utilizada a Unifield Modeling Language (UML) como linguagem para especificar os diagramas de casos de uso e modelo conceitual. Para realizar estas especificações foi utilizada a ferramenta Enterprise Architect. Para modelagem do MER foi utilizada a ferramenta DBDesigner Diagramas de casos de uso Os diagramas de casos de uso estão divididos por módulos: o módulo administrativo, onde são administradas informações como cadastro de novos logins, cadastro de sistemas, entre outras informações consideradas permanentes e o módulo operacional, onde são executadas as principais funcionalidades do sistema, como planejar os testes e executar os testes. Na figura 15 é demonstrado o diagrama de caso de uso do módulo administrativo.

44 43 ud PCT02 - Administração Módulo administrativo UC02.01 Manter logins de acesso UC02.02 Manter os sistemas Administrador UC02.03 Manter classificação de erros UC2.04 Manter status Figura 15 Diagrama de caso de uso módulo administrativo No módulo administrativo é onde são gerenciadas as configurações permanentes do sistema, como cadastrar os sistemas a serem utilizados, cadastrar classificações de erro, cadastrar novos logins de acesso e status das pendências a serem visualizadas no módulo operacional. Na figura 16 é apresentado o diagrama de caso de uso do módulo operacional.

45 44 ud PCT01 - Operacional Módulo operacional UC01.01 Manter projetos UC01.02 Manter plano de teste UC01.03 Manter casos de teste Analista UC01.04 Executar ativ idade pendente UC01.05 Efetuar login UC01.06 Gerar documentos do processo de teste Testador UC01.07 Registrar resultados da execução dos casos de teste Figura 16 Diagrama de caso de uso módulo operacional O módulo operacional é o responsável por executar todas as atividades referentes ao processo de teste de software definido na seção 3.1. Ele é operado pelos analistas e pelos testadores de acordo com suas responsabilidades. O detalhamento dos casos de uso apresentados nas figuras 15 e 16 está descrito no Apêndice A Modelagem conceitual Nesta seção é apresentado o modelo conceitual da ferramenta proposta contemplando as classes e seus atributos julgados importantes. De acordo com Wazlawick (2004, p. 102), o modelo conceitual é um diagrama do

46 45 domínio do problema e não do domínio da solução. Portanto, pode-se dizer que o modelo conceitual é diferente do diagrama de classes do projeto, pois este sim faz parte do domínio da solução. Na figura 17 é apresentado o modelo conceitual da ferramenta. class Modelo conceitual Projeto - descricao: String - sistema: Sistema Caso_teste_itens - esperado: String - passo: String pertence 1 * possui 1..* 1 Sistema - descricao: String Plano_teste - ambiente: Stirng - cliente: String - cronograma: String - data: Date - descricao: String - hrs_esforco: int - introducao: String - limitacoes: String - riscos: String gera Resultado_plano - data: Date - descricao: String possui 1 * 1 * 1 possui 1 tem * 1..* possui Caso_teste - data: Date - descricao: String - poscondicao: String - precondicao: String - uc: String Figura 1 possui - descricao: String - nome: String * -resp_planej 1 * contem 1 Pessoa - login: String - nome: String - senha: String * possui 1 1 * -resp_exec contem 1 referencia 1 * pertence 2 Pendencia - descricao: String referencia * tem 1 Status - descricao: String * 1..* Resultado_caso - data: Date - esforco: float - impacto: String - incidente: String possui * * possui Situacao - descricao: String 1 Classificacao_erro 1 - descricao: String 1 Grupo - descricao: String Figura 17 Modelo conceitual do sistema Modelo Entidade-Relacionamento Na figura 18 é apresentado o MER das tabelas a serem utilizadas no banco de dados.

47 46 Figura 18 Modelo Entidade-Relacionamento A seguir, é feito uma breve descrição de cada tabela indicando seu propósito: a) sistema: armazena informações dos sistemas utilizados nos testes; b) projeto: armazena informações dos projetos, bem como referenciando o sistema utilizado; c) status_2: armazena a descrição dos possíveis status cadastrados que serão utilizados pelas pendências; d) situação: armazena as possíveis situações dos resultados dos testes, por exemplo,

48 47 OK, NOK ; e) classificação_erro: armazena os tipos de classificação de erro que serão utilizados quando houver erro na execução de determinado caso de teste; f) grupo: armazena os possíveis grupos que serão disponibilizados no cadastro de pessoa para poder classificá-la; g) pessoa: armazena o cadastro de pessoas onde também é cadastrado o login de acesso; h) plano_teste: armazena informações dos planos de teste cadastrados; i) caso_teste: armazena informações dos casos de teste cadastrados bem como a referência de qual plano de teste ele pertence; j) caso_teste_itens: armazena o passo-a-passo dos testes a serem executados de cada caso de teste cadastrado; k) figura_result: armazena informações das figuras cadastradas nos resultados de execução dos testes; l) figura_casoteste: armazena informações das figuras cadastradas nos casos de teste a serem executados; m) pendencia: armazena os dados de cada pendência, vinculando a pessoa responsável por ela, a qual caso de teste pertence e qual status atual da pendência; n) resultado_execucao: armazena o cabeçalho do artefato de resultados da execução dos testes; o) resultado_caso: armazena os resultados de execução de cada caso de teste executado, é o corpo do artefato de resultados de execução dos testes. No apêndice B é apresentado o dicionário de dados dos campos das tabelas do MER da figura IMPLEMENTAÇÃO Nesta seção são apresentadas as técnicas e ferramentas utilizadas bem como a operacionalidade da ferramenta demonstrando suas principais funcionalidades.

49 Técnicas e ferramentas utilizadas Para realizar a implementação do trabalho proposto foi utilizada a ferramenta Codecharge Studio 3.0. Optou-se pela ferramenta pelo fato de ser a atual tecnologia adotada na empresa que irá fazer uso da ferramenta desenvolvida neste trabalho, seguindo assim um padrão em relação as tecnologias de desenvolvimento. Ela trabalha com a metodologia Rapid Application Development (RAD), onde gera código JSP de forma rápida e estruturada, facilitando assim futuras manutenções. O código gerado pela ferramenta CodeCharge Studio baseia-se nas tabelas de banco de dados, fazendo automaticamente os comandos de insert, update e delete. Para cada tabela é gerado um arquivo XML com os comandos Structured Query Language (SQL) e seus respectivos campos. É gerado também dois arquivos JSP, um contendo a estrutura de campos da tela e outro contendo os eventos dos campos dos formulários, tornando desta forma a manutenção simples e organizada. A seguir é mostrado como exemplo um trecho de cada arquivo gerado para a tabela caso_teste. Na figura 19 é apresentado um trecho do código que mostra a operação de insert para a tela caso de teste. Figura 19 Trecho do arquivo XML gerado Como se pode observar na figura anterior, o comando insert é preenchido com os parâmetros que vem da aplicação. Na figura 20 é apresentado um trecho do arquivo JSP gerado com a estrutura da tela caso de teste.

50 49 Figura 20 Trecho do arquivo JSP com a estrutura da tela caso de teste De acordo com a figura 20, o que é apresentado no arquivo JSP são os campos da tela caso de teste, neste trecho mostrando parte do formulário com os campos descrição, responsável planejamento, responsável execução e plano de teste. Na figura 21 é apresentado um trecho do segundo arquivo JSP gerado contendo os eventos da tela.

51 50 Figura 21 Trecho do arquivo JSP com os eventos da tela Na tela caso de teste foi feita uma inserção customizada, que é feito no evento afterexecuteinsert, ou seja, após a inserção de registros na tabela caso_teste é feita mais uma inserção na tabela de pendências a fim de que possa garantir que, para cada novo caso de teste cadastrado gere também uma nova pendência para planejar ou executar o respectivo caso de teste. A ferramenta desenvolvida conta também com a geração de relatórios para exportação e impressão. Para atender a esta funcionalidade foi utilizada a ferramenta ireport, que baseiase na biblioteca JasperReports para construção de relatórios. Na figura 22 é apresentado o trecho de código responsável por gerar o relatório utilizando a biblioteca JasperReports.

52 51 Figura 22 Rotina de geração do relatório A definição dos dados do relatório é salva em um arquivo com extensão Jasper Report extensible Markup Language (JRXML), que é uma extensão do extensible Markup Language (XML). Neste arquivo são passados parâmetros que necessitam ser recuperados da aplicação para a montagem do relatório. Para isto, eles são salvos em uma estrutura HashMap, conforme mostra a figura 22, e logo após passado o caminho do arquivo Jasper (que é o JRXML compilado), o HashMap e a conexão com o banco de dados que é utilizada para gerar o relatório para impressão. Toda implementação de geração de relatórios foi feita utilizando a IDE Eclipse na linguagem Java. Para a aplicação acessar a funcionalidade de geração de relatórios é necessário apenas chamar o projeto desenvolvido no Eclipse passando os parâmetros correspondentes da aplicação Operacionalidade da implementação ferramenta. Nessa seção é apresentado um estudo de caso com as funcionalidades básicas da O sistema no qual se baseia o estudo de caso é o Ambiente de Gerenciamento

53 52 Integrado (AGI). Esse sistema gerencia todo o conteúdo que é exibido no site Portal Unimed ( É no AGI que são cadastradas as matérias, enquetes, publicidades, entre outras informações, e é também no AGI onde são aprovadas essas informações para visualização no Portal. Com o intuito de possuir acesso restrito a médicos, colaboradores, administradores e clientes do Portal Unimed para algumas funcionalidades, surgiu a necessidade de cadastrar, através do AGI, os usuários que terão acesso a essas funcionalidades restritas. Para isso foi desenvolvido um projeto de cadastro de pessoas, onde será demonstrado nesse estudo de caso a elaboração de um teste para essa nova funcionalidade. Na figura 23 é apresentado o formulário de cadastro de pessoas do AGI. Figura 23 Parte do formulário de cadastro de pessoas no AGI Para atender aos casos de uso do módulo administrativo ilustrados na figura 15 o primeiro passo é cadastrar as pessoas envolvidas no teste (analistas e testadores) e o sistema que será testado. Nesse estudo de caso pressupõe-se que as classificações de erro e status das pendências já estejam cadastradas. A pessoa responsável pela administração do sistema deve acessar o módulo administrativo e clicar no menu Pessoas conforme mostra a figura 24.

54 53 Figura 24 Módulo administrativo com listagem de pessoas cadastradas Para cadastrar um novo usuário de acesso ao módulo operacional deve-se clicar no botão + e irá abrir um formulário conforme a figura 25. Figura 25 Formulário de cadastro de pessoas Após realizar o cadastro o novo usuário tem acesso ao módulo operacional. Deve-se repetir essa mesma operação para o cadastro de sistemas, acessando o menu Sistemas e preenchendo o formulário conforme a figura 26. Figura 26 Formulário de cadastro de sistemas Os passos seguintes do estudo de caso são referentes aos casos de uso do módulo operacional apresentados na figura 16. Com as pessoas e sistemas cadastrados é necessário então iniciar o processo de planejamento dos testes. Para isto deve-se acessar o módulo operacional com o login anteriormente cadastrado para a pessoa com perfil analista. Na figura

55 54 27 é apresentada a tela inicial do módulo operacional. Figura 27 Tela principal do módulo Operacional O primeiro passo para utilização do sistema é criar um novo projeto acessando o item Projetos e na listagem que aparece clicar no botão +. Abrirá a tela para cadastro do projeto apresentando um formulário conforme mostra a figura 28. Figura 28 Formulário de cadastro de projeto Depois de criado o projeto é necessário criar um plano de testes, acessando na tela principal o item Plano de teste e na listagem de planos de teste que aparece clicar no botão +. Abrirá a tela para cadastro de um novo plano de teste conforme mostra a figura 29. Figura 29 Tela de cadastramento de plano de teste

56 55 Também é possível pré-cadastrar os casos de teste que serão utilizados neste plano de testes, indicando o usuário responsável pelo planejamento do caso de testes e o responsável pela execução do mesmo. No momento em que o registro é salvo, é gerada uma nova pendência para o responsável pelo planejamento e responsável pela execução do teste. Na figura 30 é ilustrada as pendências geradas de acordo com os casos de teste pré-cadastrados na figura 29. Figura 30 Listagem de pendências Na pendência, acessando o link do caso de teste correspondente é possível fazer o planejamento do teste ou execução do mesmo. Também como recurso adicional é permitido inserir imagens nos casos de teste, a fim de que possa ser ilustrado de forma clara o teste a ser realizado. A figura 31 mostra o planejamento do caso de teste CT01 Cadastrar pessoa.

57 56 Figura 31 Planejamento de caso de teste A execução do caso de teste ilustrado na figura 31 pode ser feita através da tela de pendências, acessando a pendência correspondente e clicando no link do caso de teste para execução, ou diretamente através do menu Caso de teste, acessando o caso de teste que deseja executar. Depois de planejado e executado os casos de teste de determinado plano de testes, é

58 57 necessário gerar o artefato de resultados da execução. Para acessá-lo, na tela principal clicar no link Resultado execução. Selecionar como Plano ativo o plano de testes Plan01- Cadastro de pessoas. Irá abrir a listagem dos resultados daquele plano de testes. Para criar um novo basta clicar no botão + e irá abrir a tela de cadastramento de resultados da execução conforme ilustra a figura 32. Figura 32 Cadastramento do resultado da execução do teste Deve-se informar o resultado de execução para todos os casos de teste do plano de teste em questão para que o resultado da execução seja completo. Essas são as funcionalidades básicas da ferramenta, podendo ainda gerar relatórios de todos os artefatos de plano de teste, caso de teste e resultados da execução. Nesse estudo de caso, como a finalidade principal é a demonstração da ferramenta, será gerado o relatório parcial do plano de testes que foi cadastrado, compreendendo apenas o caso de teste CT01 e também o relatório de resultados da execução com o resultado do CT01. No apêndice C são ilustrados esses dois relatórios. 3.5 RESULTADOS E DISCUSSÃO Partindo como princípio a necessidade de uma ferramenta visando o planejamento e controle dos testes de software, foi desenvolvido um processo baseado nas metodologias já existentes OpenUP, a metodologia do CenPRA, e principalmente a real necessidade de uma pequena empresa de desenvolvimento de software em utilizar um processo de testes que seja eficaz e otimizado.