CRIAÇÃO DE UM PLUG-IN PARA O SUPORTE A GERÊNCIA DE PROJETOS DE TESTES

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO CRIAÇÃO DE UM PLUG-IN PARA O SUPORTE A GERÊNCIA DE PROJETOS DE TESTES DANIEL RICARDO DE AMORIM BLUMENAU /1-XX

2 DANIEL RICARDO DE AMORIM FERRAMENTA DE APOIO A IMPLEMENTAÇÃO DO PROCESSO MELHORIA DE PROCESSO DE TESTE (MPT) 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ência da Computação Bacharelado. Prof. Jacques Robert Heckmann, Mestre - Orientador BLUMENAU /1-11

3 FERRAMENTA DE APOIO A IMPLEMENTAÇÃO DO PROCESSO MELHORIA DE PROCESSO DE TESTE (MPT) Por DANIEL RICARDO DE AMORIM 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. Jacques Robert Heckmann, Mestre Orientador, FURB Prof. Marcel Hugo, Mestre FURB Prof. Everaldo Artur Grahl, Mestre FURB Blumenau, 29 de junho de 2011

4 Dedico este trabalho a todos os amigos, especialmente aqueles que me ajudaram diretamente na realização deste.

5 AGRADECIMENTOS A Deus, pelo seu imenso amor e graça. À minha família, que sempre esteve presente. Aos meus amigos, pelos empurrões e cobranças. Ao meu orientador, Jacques Robert Heckmann, por ter acreditado na conclusão deste trabalho.

6 Os bons livros fazem sacar para fora o que a pessoa tem de melhor dentro dela. Lina Sotis Francesco Moratti

7 RESUMO O presente trabalho é um estudo sobre o modelo de processo Melhoria de Processo de Teste Brasileiro (MPT.BR). Aborda-se uma alternativa de processo de teste para empresas que não queiram um alto custo na implementação de um processo. O processo é baseado em outros modelos como Capability Maturity Model Integration (CMMI) e Melhoria de Processo de Software Brasileiro (MPS.BR), porém focado no processo de teste de software. Ele utiliza o padrão de documentação sugerido pela norma internacional IEEE-829. Diante deste foco é desenvolvida uma ferramenta em forma de plug-in para o Eclipse para apoiar a gerência de projetos de teste e gerência de requisitos de teste de forma aderente ao MPT.BR versão 2.2, através da automatização de alguns artefatos dos níveis 1 e 2 do processo pesquisado. Palavras-chave: Teste de software. Gerência de teste. Padrão IEEE-829. Processo de teste. MPT.BR. Plug-in.

8 ABSTRACT This work is a study about the process model Melhoria de Processo de Teste Brasileiro (MPT.BR). Is approached an alternative testing process for companies that don't want a high cost processimplementation. The process is based on other models like Capability Maturity Model Integration (CMMI) and Melhoria de Processo de Software (MPS.BR), but focused on software testing process. It uses the documentation standard suggested by the international standard IEEE-829. Given this focus, a tool is developed as a Eclipse plug-in to support test project management and test requirements management adherent to MPT.BR version 2.2, by automating some artifacts from levels 1 and 2 of the search process. Key-words: Software testing. Test management. IEEE-829 standard. Test process. MPT.BR. Plug-in.

9 LISTA DE ILUSTRAÇÕES Quadro 1 Áreas de processo do modelo MPT Figura 1 - Exemplo do caso de teste da ferramenta TestLink Figura 2 - Exemplo do módulo de gerência das atividades do OpenProj Figura 3 Exemplo da gerência de tarefas no XPlanner Figura 4 Ferramenta de gerência de requisitos Quadro 2 Comparação entre correlatos Figura 5 Diagrama de casos de uso Figura 6 Diagrama de classes Figura 7 Diagrama de classes de agrupamento Figura 8 Diagrama de classes de log Figura 9 Tela de registro das classes utilizadas no plug-in Figura 10 Exemplo do método init Figura 11 Exemplo do método createpartcontrol Figura 12 Método refresh da classe ProjetoView Figura 13 Classe IElementView Figura 14 Classe responsável pela tela de configurações da ferramenta Figura 15 Itens disponíveis pelo Visual Editor Figura 16 Classe gerada pelo Visual Editor Figura 17 Menu de componentes do Visual Editor Figura 18 Tela de configurações do MPT Figura 19 Exibição das telas disponíveis Figura 20 View de cargos Figura 21 Formulário de cadastro de cargos Figura 22 Visualização de cargos com um registro Figura 23 Visualização de usuários Figura 24 Formulário de cadastro de usuário Figura 25 Visualização de produtos Figura 26 Formulário de cadastro de produtos Figura 27 Visualização de projetos Figura 28 Formulário de cadastro de projetos Figura 29 Visualização do projeto cadastrado... 60

10 Figura 30 Formulário de cadastro de ata de reunião Figura 31 Ata de reunião da visualização de projetos Figura 32 Formulário de risco Figura 33 Formulário de plano de teste Figura 34 Formulário de cadastro de não conformidade Figura 35 Formulário de requisitos de teste Figura 36 Formulário de suíte de teste Figura 37 Formulário de caso de teste Figura 38 Formulário de cadastro de checklists Figura 39 Formulário de tarefa Figura 40 Relatório checklist de teste Quadro 3 Comparação entre correlatos Quadro 4 UC01 Cadastrar permissões de usuário Quadro 5 UC02 Cadastrar usuários Quadro 6 UC03 Cadastrar cargos Quadro 7 UC04 Cadastrar casos de teste Quadro 8 UC05 Cadastrar suite de teste Quadro 9 UC06 Cadastrar projeto Quadro 10 UC07 Cadastrar requisite de teste Quadro 11 UC08 Cadastrar produto Quadro 12 UC12 Cadastrar configurações Quadro 13 UC10 Cadastrar risco Quadro 14 UC11 Cadastrar plano de teste Quadro 15 UC12 Cadastrar tarefa Quadro 16 UC13 Cadastrar ata de reunião Quadro 17 UC14 Cadastrar checklist de teste Quadro 18 UC15 Extrair indicadores Quadro 19 UC16 Visualizar relatório de checklist de teste... 91

11 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA TESTE DE SOFTWARE CONCEITOS BÁSICOS PADRÃO DE DOCUMENTAÇÃO IEEE AUTOMAÇÃO DE TESTES DESCRIÇÃO DO MODELO MPT.BR BIBLIOTECA PLUG-IN DEVELOPMENT ENVIRONMENT (PDE) TRABALHOS CORRELATOS TestLink OpenProj XPlanner Ferramenta de apoio à gerência de requisitos baseado no modelo CMMI Comparação entre os trabalhos correlatos DESENVOLVIMENTO REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO Diagrama de casos de uso Diagrama de classes IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Plug-in Development Environment Visual Editor Banco de dados Operacionalidade da implementação Visualização de cargos Visualização de usuários Visualização de produtos Estudo de caso... 59

12 3.4 RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Relação dos casos de uso da ferramenta... 81

13 12 1 INTRODUÇÃO Conforme Bastos et al. (2007, p. 18), Durante as décadas de 1970, 1980 e 1990, os testes eram efetuados pelos próprios desenvolvedores do software, cobrindo aquilo que hoje chamamos de testes unitários e testes de integração. Na globalização do mercado de software, cada vez mais competitivo, terá mais chance de sobreviver quem for organizado e eficiente no seu processo de produção, disponibilização e evolução de software. Esse cenário faz com que o processo de melhoria de qualidade de produtos e serviços relativos à informação seja vital para as empresas desse ramo. (COUTO, 2007, p. 3). O modelo de Melhoria de Processo de Teste Brasileiro (MPT.BR) foi criado com a proposta de disponibilizar um modelo de testes para empresas de qualquer porte, dando a oportunidade para as empresas de software implementarem níveis de maturidade dentro de suas organizações, trazendo mais qualidade para seus produtos, sem que haja um aumento do custo do produto (ASSOCIAÇÃO LATINO AMERICANA DE TESTE DE SOFTWARE, 2002a). Segundo Molinari (2003, p. 19), a qualidade é algo cobiçado por todos dentro de uma organização de tecnologia de informação. Gerentes querem alta qualidade em seu produto, os desenvolvedores querem desenvolver produtos de alta qualidade e os usuários, cada vez mais exigentes, querem confiança e consistência na sua ferramenta de trabalho. Segundo pesquisa do próprio pesquisador, existem outros modelos de maturidade de teste de software além do MPT.BR, como Testability Support Model (TSM), Testing Maturity Model (TMM), Test Process Improvement (TPI), Testing Assessement Program (TAP), Test Organization Maturity (TOMtm), Testing Improvement Model (TIM), Testing Maturity Model Integration (TMMi). Porém, conforme SOFTEX (2010a), nenhum desses modelos têm representantes no Brasil, tornando muito difícil sua implementação e, mesmo que a organização faça a implementação por conta própria, seria muito caro conseguir sua homologação e reconhecimento no mercado brasileiro. Segundo Bastos et al. (2007, p. 18), Defeitos encontrados durante a produção tendem a custar muito mais que defeitos encontrados em modelos de dados e em outros documentos do projeto do software. Pelo fato do MPT.BR ser um modelo novo, ainda não existe uma solução no mercado que atenda às necessidades de sua implementação em uma única ferramenta. Desta forma, a solução atual para a automação do modelo MPT.BR é a aquisição, a implantação, a integração e o treinamento dos usuários em diversas ferramentas, cada uma abrangendo uma área do

14 13 processo. Isso torna a automação difícil, considerando-se a necessidade de gastos com a compra de todas estas diversas ferramentas, integração e treinamento nas mesmas. O Eclipse foi escolhido para servir de suporte para o plug-in pelo fato de ser uma ferramenta de desenvolvimento gratuita e que dá suporte a uma linguagem não proprietária, que é o Java. Diante do exposto é importante uma ferramenta (gratuita) para automatizar o processo que define o modelo MPT.BR, desenvolvendo-se um plug-in para o Eclipse. Isso facilitará às empresas de tecnologia da informação implementarem um processo de teste em suas organizações e tornarem o seu produto ainda mais confiável, consistente e sem custos de aquisição de uma ferramenta. O plug-in será disponibilizado a implementadores do modelo MPT.BR credenciados pela Associação Latino Americana de Teste de Software (ALATS). 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho foi criar um plug-in para o Eclipse para apoiar à implementação do modelo MPT.BR. O objetivo específico deste trabalho é: a) atender algumas práticas genéricas e específicas do nível 1 e 2 do modelo MPT.BR na versão 2.2; 1.2 ESTRUTURA DO TRABALHO No segundo capítulo deste trabalho é feita uma revisão bibliográfica abordando os temas teste de software, apresentando boas práticas e documentação padronizada da IEEE- 829, automação de testes, processo MPT, bem como sua divisão em níveis e conceitos do processo que irão servir como base para o desenvolvimento da ferramenta. Também é feita uma breve apresentação do ambiente Plug-in Development Environment (PDE), que será o ambiente utilizado para o desenvolvimento da ferramenta em forma de plug-in do Eclipse e, por fim, são apresentadas algumas ferramentas de mercado que apresentam funcionalidades semelhantes com a proposta deste trabalho.

15 14 No terceiro capítulo são apresentados os requisitos da ferramenta desenvolvida neste trabalho, assim como sua especificação, ferramentas utilizadas, implementação apresentando um estudo de caso e os resultados e desafios encontrados no desenvolvimento da ferramenta. No quarto capítulo são apresentadas as conclusões deste trabalho e sugestões para futuras extensões do mesmo.

16 15 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são abordados temas como teste de software, padrão de documentação, automação de processos, processo de teste MPT.BR, detalhando o processo, bem como os níveis que ele dispõe. É descrito uma introdução ao PDE, que foi o framework utilizado para o desenvolvimento da ferramenta e, por fim, são descritos os trabalhos correlatos. 2.1 TESTE DE SOFTWARE Neste tópico são apresentados conceitos básicos de teste de software e padrão de documentação segundo IEEE CONCEITOS BÁSICOS Desenvolver sistemas que atendam corretamente seu objetivo é uma tarefa de alta complexidade, dependendo da finalidade do software. Isso eleva a possibilidade do sistema apresentar problemas, dos mais variados tipos (DELAMARO; MALDONADO; LINO, p. 1). Segundo Tozelli (2008), Não se pode garantir que todos os programas funcionariam corretamente, sem a presença de erros humanos, visto que os mesmo muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. Myers (1979, p. 5) afirma que testar é executar um programa com a finalidade de encontrar erros e Almeida (2010) complementa que testar não é somente procurar erros, mas que também fazem parte da atividade de teste planejar, controlar, preparar, modelar, avaliar, mensurar e revisar. Existem várias definições diferentes para teste de software. A atividade de teste é complexa. São diversos os fatores que podem colaborar para a ocorrência de erros. Por exemplo, a utilização de um algoritmo incorreto para computar o valor das mensalidades a serem pagas para um empréstimo ou a nãoutilização de uma política de segurança em alguma funcionalidade do software são dois tipos distintos de engano e, de certa forma, encontram-se em níveis diferentes de abstração. O primeiro tipo de erro provavelmente está confinado a uma função ou

17 16 rotina que implementa de forma incorreta uma dada funcionalidade. No segundo caso, mesmo que exista uma certa política de segurança implementada de maneira correta, é preciso verificar se todos os pontos nos quais essa política deveria ser aplicada fazem-no de maneira correta. (DELAMARO; MALDONADO; LINO, p. 3). Para Hetzel (1973), teste é um processo que transmite a confiança de que o programa atende o seu propósito. Rios (2008, p. 9) afirma que a qualidade do software depende também do investimento feito no processo de teste e complementa dizendo que dentro do processo de teste existem técnicas de verificação que servem para identificar defeitos ou anormalidades no projeto e que se deve utilizar documentos como planos, especificações e requisitos PADRÃO DE DOCUMENTAÇÃO IEEE-829 Para Rios (2008, p. 27), O IEEE ao decidir criar um padrão de documentação preocupou-se em definir aqueles documentos sem os quais o processo de teste de software não pode atingir os seus objetivos. Processos não trazem bons resultados quando não possuem documentos padronizados para que todos os profissionais sigam as mesmas premissas (RIOS, 2008, p. 29). Um dos documentos que a IEEE-829 traz em sua documentação é o plano de teste. O Plano de Teste, documento básico gerado através da etapa de planejamento, serve como escopo de referência durante a execução do teste e também serve como documento de comunicação junto ao cliente que contratou o serviço de teste. Ao passarmos para a etapa de especificação precisamos ter em mãos o Plano de Teste. (RIOS, 2008, p. 30). Um plano de teste da IEEE-829 deve conter em seu padrão campos como identificador, introdução, itens de teste, funcionalidades a serem testadas, funcionalidades a não serem testadas, abordagem de teste, critérios de término dos testes, critérios de suspensão dos testes, entregas, tarefas, ambientes, responsabilidades, treinamentos, cronograma, riscos e aprovações (RIOS, 2008, p. 37). Outro documento que a IEEE-829 apresenta é o caso de teste. O caso de teste da IEEE-829 deve conter os campos como identificador, itens de teste, especificações de entrada, especificações de saída, necessidades de ambiente, requisitos e dependências entre casos de teste (RIOS, 2008, p.59). O propósito do Caso de Teste é definir uma unidade de teste que será executada pelo

18 17 testador, seja manualmente ou automaticamente. (RIOS, 2008, p. 59). 2.2 AUTOMAÇÃO DE TESTES Nesta seção apresentam-se algumas ferramentas utilizadas na automação de testes. Graham e Fewster (1999, p. 4) afirmam que teste e automação de testes são atividades distintas. Teste é executar a atividade de testar um software, seja planejar, executar ou mensurar. Já automação de testes é a utilização de uma ferramenta para automatizar as atividades de teste de software mencionadas anteriormente. Segundo Molinari (2010, p. 37) O teste automatizado aumenta a produtividade e atinge em tempo menor aquilo que é em geral rotineiro no teste. Existem várias classificações de automação de testes. Ferramentas de planejamento de testes são importantes para projetar e planejar os testes, criar casos de teste e requisitos de teste em um ambiente definido. Ferramentas de automação da execução dos testes são muito utilizadas para os testes de regressão, diminuindo o esforço de teste depois da automação feita. Ferramentas de gerenciamento de defeitos são importantes para controlar os problemas já encontrados e como eles estão sendo tratados (MOLINARI, 2010, p. 41). Molinari (2010, p.79) afirma que A melhor forma de expressar o papel da automação da gerência e do planejamento dos testes é justamente gerenciar o centro nervoso dos testes: o caso de teste, além disso, explica que: Quando nos referimos à gerência, também engloba o processo, isto é, automatizar a gerência de testes significa também automatizar o processo de testes, ou o controle do processo que gira em torno dos casos de teste. Não quer dizer que gerenciar é automatizar tudo, mas controlar as informações chave do processo de teste que a empresa usa. Querendo ou não, quando implantamos uma ferramenta de gerência de testes, afetamos diretamente ou indiretamente, de forma positiva, o processo existente na empresa. Algumas ferramentas precisam ser ajustadas e customizadas para atender o processo. Em outras ocorre justamente o contrário: a empresa é que se adapta ao processo proposto pela ferramenta. (MOLINARI, 2010, p. 79). Segundo Aderson et al (2007, p. 23), podemos dizer que o retorno do investimento será maior à medida que investirmos em teste. Isto é, quanto mais melhorarmos a atividade de teste, melhores serão os resultados financeiros.

19 DESCRIÇÃO DO MODELO MPT.BR O MPT.Br é um modelo para Melhoria do Processo de Teste concebida para apoiar as organizações através dos elementos essenciais para o desenvolvimento da disciplina de teste no processo de desenvolvimento de software (SOFTEX RECIFE, 2010a). O Guia de implementação do MPT.BR está subdividido em níveis de maturidade, a exemplo do CMMI e do MPS.BR (ASSOCIAÇÃO LATINO AMERICANA DE TESTE DE SOFTWARE, 2002b). A ideia do MPT.Br foi criação de um modelo para avaliação da maturidade das áreas de teste de software compatível, mas não necessariamente igual, com o modelo MPS.BR, embora totalmente voltado para a área de teste de software. (SOFTEX RECIFE, 2011b, p. 10). O MPT.BR é um modelo para Melhoria do Processo de Teste de Software Brasileiro, que está sendo desenvolvido com o principio básico de ser compatível com o modelo MPS.BR criado pela Softex e é baseado também em alguns critérios usados pelo CMMI. O MPT é voltado para a melhoria das áreas de teste de software de empresas de qualquer porte. O modelo é leve e passível de ser adotado por área de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que as áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos operacionais. (SOFTEX RECIFE, 2010b, p. 4). Conforme SOFTEX RECIFE (2010a), os principais objetivos do MPT.BR são, aumentar a qualidade dos produtos de software através da otimização e melhoria contínua dos processos de teste, fornecer visibilidade relativa a maturidade do processo de teste de uma organização para o mercado de software e, por fim, fomentar a melhoria contínua dos processos de teste no âmbito do desenvolvimento de software. Segundo Couto (2007, p. 130), Estudos sobre a qualidade no setor de software brasileiro mostraram a necessidade de um esforço significativo capaz de aumentar a maturidade dos processos de software das empresas brasileiras. O nível um contempla a área de gerência de projetos de teste, o qual abrange atividades como desenvolvimento do plano de teste, comprometimento dos interessados e monitoramento do plano de teste. Conforme SOFTEX RECIFE (2010a), no Brasil existem 30 profissionais da área de teste de software credenciados como implementadores do modelo MPT.BR e 7 empresas certificadas com o nível 1 até o mês de maio de O modelo é dividido em cinco níveis para facilitar a sua implementação e o seu

20 19 entendimento de cada prática, sendo cada uma delas divididas em genéricas e específicas. Conforme SOFTEX RECIFE (2010b, p. 13), Os projetos de teste de software são temporários, ou seja, terminam junto com a liberação do software para a produção. Isso não significa que nas futuras manutenções do mesmo software novos projetos de teste sejam abertos. O nível 1 do MPT.BR é composto por 17 práticas específicas e 8 práticas genéricas na versão 2.2. Segundo SOFTEX RECIFE (2010b, p. 14), as práticas específicas do nível 1 são: a) definir o escopo do trabalho para o projeto. Esta prática tem como produtos típicos a descrição em linhas gerais do escopo do projeto, a descrição das atividades envolvidas no desenvolvimento do projeto, a descrição dos pacotes de trabalho, descrição genérica do sistema a ser testado, a estrutura analítica do projeto e a lista de requisitos; b) estabelecer estimativas para o tamanho das tarefas e dos produtos de trabalho do projeto de teste utilizando métodos apropriados. Esta prática tem como produtos típicos a definição do tamanho e complexidade das tarefas e dos produtos de trabalho, os modelos usados para elaborar as estimativas, indicadores e históricos usados nas estimativas; c) definir as fases do ciclo de vida do projeto de teste. Está prática tem como produto típico o ciclo de vida do projeto de teste de software com fases e, se possível, subfases; d) estimar o esforço e o custo para a execução das tarefas e dos produtos de trabalho com base em dados históricos ou referências técnicas. Esta prática tem como produtos típicos a estimativa de esforços do projeto de teste e a estimativa dos custos do projeto de teste; e) estabelecer e manter o orçamento e o cronograma do projeto de teste, incluindo marcos e/ou pontos de controle. Esta prática tem como produtos típicos o cronograma do projeto de teste, dependências do cronograma do projeto de teste e o orçamento do projeto de teste; f) determinar e documentar os riscos do projeto de teste, assim como seu impacto, probabilidade de ocorrência e prioridade de tratamento. Esta prática tem como produtos típicos a identificação dos riscos, a determinação do impacto e probabilidade de ocorrências dos riscos, a prioridade de tratamento dos riscos e os planos de mitigação e contingência dos riscos;

21 20 g) planejar os recursos humanos para o projeto considerando o perfil e a proficiência necessários para executá-lo. Esta prática tem como produtos típicos a definição do perfil necessário dos recursos humanos do projeto, a lista dos recursos humanos do projeto indicando as necessidades de contratação e a qualificação do pessoal e as necessidades de treinamento; h) planejar as tarefas, os recursos (não humanos) e o ambiente de trabalho necessário para executar o projeto de testes. Esta prática tem como produtos típicos a estrutura analítica do projeto detalhada contemplando os recursos necessários, as necessidades de pessoal baseadas no escopo e no tamanho do projeto e os equipamentos e ambientes de teste necessários; i) identificar e planejar os artefatos e dados relevantes do projeto de teste quanto à forma de coleta, armazenamento e distribuição. Esta prática tem como produtos típicos o plano de gerência de dados, o plano de comunicação e os requisitos de segurança de dados; j) estabelecer os planos para a execução do projeto de teste e reunir no plano de teste. Esta prática tem como produto típico o plano de testes contemplando todos os outros planos; k) avaliar a viabilidade de atingir as metas do projeto de teste, considerando as restrições e os recursos disponíveis, fazendo, se necessário, ajustes pertinentes. Esta prática tem como produto típico a análise preliminar de viabilidade; l) fazer a revisão do plano de teste com todos os interessados e obter o compromisso com o mesmo. Esta prática tem como produtos típicos a ata de reunião de início e o plano de envolvimento com as devidas responsabilidade; m) monitorar o progresso do projeto com relação ao estabelecido no plano de teste e documentar os resultados. Esta prática tem como produtos típicos as atas de reunião de acompanhamento do projeto demonstrando que os itens relevantes do projeto foram monitorados e o registro de mudanças com a sua monitoração até a conclusão; n) gerenciar o envolvimento das partes interessadas no projeto de teste. Esta prática tem como produtos típicos a lista de todos os técnicos envolvidos no projeto, as necessidades de técnicos em termos de contratação ou treinamento, as regras e responsabilidades dos técnicos envolvidos com respeito à responsabilidade no projeto por fase do ciclo de vida e por atividade e os recursos necessários como treinamentos, equipamentos e orçamento para que os técnicos envolvidos possam

22 21 desenvolver a sua atividade no projeto; o) executar revisões em marcos do projeto e conforme estabelecido no planejamento. Esta prática tem como produtos típicos as atas de reuniões de acompanhamento do projeto e os registros de mudança com a sua monitoração até a conclusão. p) estabelecer os registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, assim como tratar os mesmos com as partes interessadas. Esta prática tem como produto típico o registro de mudanças com a sua monitoração até a conclusão; q) estabelecer ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas, assim como implementar e acompanhar até a sua conclusão. Esta prática tem como produto típico o registro de mudanças com a sua monitoração até a conclusão com o registro das ações corretivas adotadas. SOFTEX RECIFE (2010b, p. 25), apresenta as práticas genéricas do nível 1 como: a) atingir os resultados definidos. Esta prática tem como produtos típicos ter o processo definido e institucionalizado; b) estabelecer e manter uma política organizacional para o processo. Esta prática tem como produtos típicos o manual de qualidade reconhecendo a importância dos processos, o processo definido na intranet da empresa e o registro na intranet de uma publicação que divulgue a obrigatoriedade do cumprimento dos processos; c) planejar a execução do processo. Esta prática tem como produto típico o plano de teste; d) monitorar e controlar a execução do processo para atender aos planos. Esta prática tem como produtos típicos as atas de reunião de acompanhamento do projeto, os registros de mudança com a comprovação do seu monitoramento e as atas de reunião de acompanhamento do projeto em diversos níveis; e) identificar e disponibilizar os recursos necessários para a execução do processo. Esta prática tem como produtos típicos o plano de recursos do projeto, o registro de treinamentos realizados e treinamentos em estimativas, riscos e planejamento; f) garantir que as pessoas que executam o processo são competentes em termos de formação, treinamento e experiência. Esta prática tem como produtos típicos o registro de treinamentos realizados, os treinamentos em estimativas, riscos, planejamentos e ter definido um processo de capacitação e treinamento; g) garantir a comunicação entre as partes interessadas no processo de forma a manter o seu envolvimento no projeto. Esta prática tem como produtos típicos o plano de

23 22 comunicação do plano de teste e as atas de reunião de acompanhamento do projeto; h) monitorar e controlar o processo. Esta prática tem como produtos típicos as atas de reunião de acompanhamento do projeto, o plano de teste e o processo de gerência de projetos de teste. Segundo SOFTEX RECIFE (2010b, p. 11), Ao final da implementação deste nível a organização deve ser capaz de gerenciar seus projetos de teste de software, de acordo com os requisitos exigidos neste nível de maturidade. O nível dois de gerência de requisitos de teste abrange a atividade de levantamento de requisitos de teste. O objetivo da área de processo Gerência de Requisitos de Teste é buscar junto aos fornecedores de requisitos aqueles inerentes ao projeto de teste de software. Esta gerência deverá garantir que não existe nenhuma inconsistência ou não conformidade na lista de requisitos, de forma a permitir que os artefatos deles provenientes, como, por exemplo, o Plano de Teste, possam vir a ser criados corretamente. Na maior parte das vezes os requisitos de software poderão também ser usados como requisitos de teste. (SOFTEX RECIFE, 2011b, p. 4). Conforme SOFTEX RECIFE (2010c, p. 3), A organização poderá iniciar a implantação do modelo MPT.BR pelo nível dois desde que implemente paralelamente também o processo do nível um e que demonstre maturidade para assim proceder. Segundo SOFTEX RECIFE (2011c, p. 6) afirma que o nível 2 contêm 5 práticas específicas e 8 práticas genéricas. SOFTEX RECIFE (2010c, p.3) apresenta as práticas específicas: a) obter o entendimento dos requisitos de software e definir os requisitos de teste. Esta prática tem como produtos típicos a lista de fornecedores de requisitos, os critérios para avaliação e a especificação ou lista de requisitos aprovados pelos interessados no projeto; b) aprovar e obter o comprometimento com os requisitos de teste utilizando critérios objetivos. Esta prática tem como produtos típicos documentos contendo a lista de requisitos aprovados e documentos onde as partes envolvidas aprovam os requisitos; c) estabelecer e manter a rastreabilidade bidirecional entre os requisitos e artefatos de teste. Esta prática tem como produtos típicos a matriz de rastreabilidade e o mecanismo que permita rastrear os requisitos até os casos de teste; d) realizar revisões em planos e produtos de trabalho do projeto e corrigir inconsistências identificadas em relação aos requisitos. Esta prática tem como produtos típicos o registro de não conformidades e ações corretivas com controle

24 23 dessas ações; e) gerenciar as alterações dos requisitos no projeto de teste. Esta prática tem como produtos típicos o versionamento dos requisitos, relatório de estudo do impacto da alteração no projeto, relatórios do estudo de viabilidade para a aprovação da mudança, atas de reunião monitorando as alterçaões e a aprovação de requisitos. Conforme SOFTEX RECIFE (2011c, p. 9), as práticas genéricas do nível 2 são: a) atingir os resultados definidos. Esta prática tem como produtos típicos o processo definido e institucionalizado e o plano de projeto incluindo a lista de requisitos; b) estabelecer e manter uma política organizacional para o processo. Esta prática tem como produtos típicos o manual de qualidade reconhecendo a importância do processo de gerência de requisitos de testes; c) planejar a execução do processo. Esta prática tem como produto típico o plano de teste com a lista de requisitos ou, em alguns casos, o plano de gerências de requisitos e o processo de gerência de requisitos de teste; d) monitorar e controlar a execução do processo para atender aos planos. Esta prática tem como produtos típicos as atas de reunião de acompanhamento do projeto, o processo de gerência de requisitos e relatórios de falhas registradas; e) identificar e disponibilizar os recursos necessários para a execução do processo. Esta prática tem como produtos típicos o plano de recursos do projeto dentro do plano de testes e o processo de gerência de requisitos de teste; f) garantir que as pessoas que executam o processo são competentes em termos de formação, treinamento e experiência. Esta prática tem como produtos típicos o registro de treinamentos realizados, treinamentos em estimativas, riscos e planejamento e o processo de capacitação e treinamento; g) garantir a comunicação entre as partes interessadas no processo de forma a manter o seu envolvimento no projeto. Esta prática tem como produtos típicos o plano de comunicação do plano de teste, as atas de reunião de acompanhamento do projeto e o processo de gerência de requisitos de teste; h) monitorar e controlar o processo. Esta prática tem como produtos típicos as atas de reunião de acompanhamento do projeto, os documentos que comprovem o envolvimento das partes envolvidas no andamento do projeto, o plano de testes e o processo de gerência de requisitos de teste. Os demais níveis ainda não foram detalhados pela Softex Recife, porém ela já tem as áreas de abrangência de cada nível definidas.

25 24 O nível três contempla as áreas de medição, gerência de configurações, garantia de qualidade e aquisições, o qual abrange atividades como revisão dos resultados dos testes em forma de indicadores, seleção de ferramentas necessárias para o projeto de teste e aquisições de ferramentas ou recursos necessários para o projeto de teste. O nível quatro contempla as áreas de gerências de recursos humanos, incluindo skill 1 de recursos, gerência de riscos e a área de gerência de reutilização, sendo este último opcional para este nível. O nível cinco contempla as práticas de validação e verificação, sendo que estas estão presentes também no nível três no modelo CMMI. MPT.BR 2.2. No quadro 1 é possível visualizar a divisão das áreas do processo com os níveis do Nivel 1 Nível 2 Nível 3 Nível 4 Nível 5 Gerência de Projetos de Teste - GPT Gerência de Requisitos de Teste - GRT Aquisição AQU (opcional) Gerência de Configuração GCO Garantia da Qualidade - GQA Medição - MED Gerência de Recursos Humanos - GRH Gerência de Reutilização - GRU (opcional) Gerência de Riscos - GRI Validação - VAL (opcional) Verificação - VE Fonte: Softex Recife (2010b). Quadro 1 Áreas de processo do modelo MPT 2.4 BIBLIOTECA PLUG-IN DEVELOPMENT ENVIRONMENT (PDE) Segundo Eclipse Foundation (2010), o Plug-in Development Environment é um recurso para o Eclipse onde o desenvolvedor pode criar, desenvolver, depurar, testar, compilar e implantar seus próprios plug-ins, fragmentos e atualizações. 1 Skill, termo oriundo do inglês, que significa habilidade.

26 25 Eclipse Foundation (2010) afirma que o PDE é dividido em quatro componentes: a) PDE build: componente para a criação de ferramentas e scripts para a automatização da construção de processos; b) PDE UI: composto por modelos, construtores e editores para facilitar o desenvolvimento de plug-ins para o Eclipse; c) PDE Application Programming Interface (API) tools: IDE do Eclipse com ferramentas de integração de criação de processos para manter a API; d) PDE incubator: desenvolvimento de novas ferramentas que não estão prontas para serem adicionadas no Eclipse. 2.5 TRABALHOS CORRELATOS Existem várias ferramentas não comerciais que apresentam funções similares, cada uma com sua particularidade. Dentre elas apresentam-se o TestLink, o OpenProj, o XPlanner e a ferramenta desenvolvida por Meisen (2005) TestLink Costa (2008), afirma que o TestLink é uma ferramenta de gerenciamento de casos de teste e execução de teste, ela é de código livre e foi desenvolvida para plataforma Web, utilizando PHP e MySql. O TestLink dá suporte a integração com o Mantis, que é uma ferramenta de gerenciamento de defeitos. (TESTLINK). Segundo Costa (2008), a ferramenta tem como ponto positivo a escalabilidade, pois é uma ferramenta web, dependendo somente do servidor para aumentar a quantidade de usuários. Porém o mesmo Costa (2008) afirma que a ferramenta simplesmente não tem segurança, pois existem erros graves de Cross Site Scripting (XSS) e de manipulação de URL Na figura 1 é exibida a tela de cadastro de casos de teste da ferramenta.

27 26 Fonte: Costa (2008). Figura 1 - Exemplo do caso de teste da ferramenta TestLink Algumas características do TestLink são: a) permite criar planos de teste; b) permite criar casos de teste; c) permite criar requisitos de teste; d) dispõe de rastreabilidade entre requisitos e casos de teste; e) ferramenta web, desenvolvida em PHP; f) tem abertura para sistemas de gerenciamento de defeitos, como Bugzilla e Mantis OpenProj Conforme Serena Software Incorporated (2008a), OpenProj é uma ferramenta desktop

28 27 livre para gerenciamento de projetos de software. É uma ferramenta multi-plataforma que substitui as funcionalidades oferecidas pela ferramenta chamada MSProject que é uma ferramenta de gerenciamento de projetos da Microsoft, possui gráficos Gantt, diagramas de rede e Work Breakdown Structure (WBS). Segundo Serena Software Incorporated (2008b), o OpenProj é uma solução OpenSource para gestão de projetos avançados. Tem seu código fonte aberto à comunidade, com os mais avançados recursos e algoritmos de programação do mercado, além de rodar em várias plataformas como Linux, Unix, Mac ou Windows. Na figura 2 tem-se um exemplo do módulo de gerência das atividades do OpenProj. Fonte: Serena Software Incorporated (2008a). Figura 2 - Exemplo do módulo de gerência das atividades do OpenProj XPlanner Segundo XPlanner (2002), a ferramenta oferecida gratuitamente pela organização com o mesmo nome foi criada para atender uma metodologia de desenvolvimento de software chamada extreme Programming (XP). São características do Xplanner:

29 28 a) modelo simples de planejamento; b) anotações; c) suporte para a gravação e monitoramento de projetos, iterações e tarefas; d) continuação de histórias inacabadas; e) medições de tempo trabalhado; f) gráficos de velocidade da iteração; g) distribuição de tarefas; h) possibilidade de anexar notas às histórias e tarefas; i) visão da estimativa exata da iteração; j) página de tarefas, mostrando a história individualmente para desenvolvedores e clientes; k) exportação de projetos para Extensible Markup Language (XML), Portable Document Format (PDF) e outros; l) suporte a vários idiomas. Na figura 3 tem-se uma visão da gerência de tarefas no XPlanner.

30 29 Fonte: XPlanner (2002). Figura 3 Exemplo da gerência de tarefas no XPlanner Ferramenta de apoio à gerência de requisitos baseado no modelo CMMI Segundo Meisen (2005), a ferramenta tem a função de auxiliar a gerência de requisitos

31 30 em projetos de software. Foi criada para atender a alguns dos requisitos do modelo CMMI referentes aos níveis 2 e 3, através do desenvolvimento de uma área para a criação de um plano de gerência de requisitos, histórico de mudanças, indicadores de estabilidade e cadastros básicos para a gerência de requisitos em projetos. Na figura 4 é possível verificar-se como a ferramenta disponibilizava a funcionalidade de cadastro de requisitos. Fonte: Meisen (2005). Figura 4 Ferramenta de gerência de requisitos. Segundo Meisen (2005), estes são os requisitos da ferramenta desenvolvida: a) criar projetos: o sistema deve permitir a criação do projeto; b) manter usuários: o sistema deve permitir a inclusão/alteração/exclusão de usuários; c) manter tipos de requisitos: o sistema deve permitir a inclusão/alteração/exclusão de tipos de requisitos que serão utilizados nos projetos; d) manter atributos: o sistema deve permitir a inclusão/alteração/exclusão de atributos que serão associados aos tipos de requisitos; e) manter vínculos: o sistema deve permitir a inclusão/alteração/exclusão de vínculos entre os tipos de requisitos; f) manter projetos: o sistema deve permitir a inclusão/alteração/exclusão dos projetos

32 31 previamente criados; g) registrar uma política para gerência de requisitos: o sistema deve permitir a criação de um documento que descreva as regras de gerência de requisitos da empresa, para que todos os usuários tenham acesso; h) manter acessos: o sistema deve permitir a inclusão/alteração/exclusão de acessos de escrita ou leitura aos analistas; i) manter glossário: o sistema deve permitir a inclusão/alteração/exclusão do glossário dos projetos; j) manter requisitos: o sistema deve permitir a inclusão/alteração/exclusão dos requisitos Comparação entre os trabalhos correlatos Nesta seção é feita uma comparação entre os trabalhos correlatos apresentados anteriormente. A mesma pode ser visualizada no quadro 2. Prática Ferramenta Definir o escopo do trabalho para o projeto TestLink: Atende OpenProject: Atende XPlanner: Atende Meisen (2005): Atende Estabelecer estimativas para o tamanho das tarefas e TestLink: Não atende dos produtos de trabalho do projeto de teste utilizando OpenProject: Atende métodos apropriados XPlanner: Atende Meisen (2005): Não atende Definir as fases do ciclo de vida do projeto de teste TestLink: Atende OpenProject: Atende XPlanner: Atende Meisen (2005): Não atende Estimar o esforço e o custo para a execução das tarefas TestLink: Não atende e dos produtos de trabalho com base em dados OpenProject: Atende históricos ou referências técnicas XPlanner: Atende

33 32 Estabelecer e manter o orçamento e o cronograma do projeto de teste, incluindo marcos e/ou pontos de controle Determinar e documentar os riscos do projeto de teste, assim como seu impacto, probabilidade de ocorrência e prioridade de tratamento Planejar os recursos humanos para o projeto considerando o perfil e a proficiência necessários para executá-lo Planejar as tarefas, os recursos (não humanos) e o ambiente de trabalho necessário para executar o projeto de testes Identificar e planejar os artefatos e dados relevantes do projeto de teste quanto à forma de coleta, armazenamento e distribuição Estabelecer os planos para a execução do projeto de teste e reunir no plano de teste Monitorar o progresso do projeto com relação ao estabelecido no plano de teste e documentar os resultados Avaliar a viabilidade de atingir as metas do projeto de teste, considerando as restrições e os recursos disponíveis, fazendo, se necessário, ajustes pertinentes Meisen (2005): Não atende TestLink: Não atende OpenProject: Atende XPlanner: Atende Meisen (2005): Não atende TestLink: Não atende OpenProject: Atende parcial XPlanner: Atende parcial Meisen (2005): Não atende TestLink: Atende OpenProject: Atende XPlanner: Atende Meisen (2005): Não atende TestLink: Atende OpenProject: Não atende XPlanner: Não atende Meisen (2005): Não atende TestLink: Atende OpenProject: Não atende XPlanner: Não atende Meisen (2005): Não atende TestLink: Atende OpenProject: Não atende XPlanner: Não atende Meisen (2005): Não atende TestLink: Atende OpenProject: Atende parcial XPlanner: Atende parcial Meisen (2005): Não atende TestLink: Não atende OpenProject: Não atende XPlanner: Não atende Meisen (2005): Não atende

34 33 Fazer a revisão do plano de teste com todos os TestLink: Atende interessados e obter o compromisso com o mesmo OpenProject: Não atende XPlanner: Não atende Meisen (2005): Não atende Gerenciar o envolvimento das partes interessadas no TestLink: Não atende projeto de teste OpenProject: Não atende XPlanner: Não atende Meisen (2005): Não atende Executar revisões em marcos do projeto e conforme TestLink: Não atende estabelecido no planejamento OpenProject: Não atende XPlanner: Não atende Meisen (2005): Não atende Estabelecer os registros de problemas identificados e o TestLink: Não atende resultado da análise de questões pertinentes, incluindo OpenProject: Não atende dependências críticas, assim como tratar os mesmos XPlanner: Não atende com as partes interessadas Meisen (2005): Não atende Estabelecer ações para corrigir desvios em relação ao TestLink: Não atende planejado e para prevenir a repetição dos problemas, OpenProject: Não atende assim como implementar e acompanhar até a sua XPlanner: Não atende conclusão Meisen (2005): Não atende Quadro 2 Comparação entre correlatos Foram escolhidos estes itens de comparação, pois são as práticas específicas do nível 1 processo MPT.BR. Com esta comparação pode-se observar que o trabalho correlato Testlink é a ferramenta mais próxima ao processo MPT.BR, pois atende a maior quantidade de práticas específicas do processo.

35 34 3 DESENVOLVIMENTO Nesta seção são detalhados os requisitos principais do trabalho, as especificações utilizadas para o desenvolvimento, a implementação do plug-in e, por fim, são apresentados os resultados e discussões. 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO Os requisitos especificados para o desenvolvimento da ferramenta proposta são baseados nas práticas do MPT.BR níveis 1 e 2. O objetivo não é atender todas as práticas deste processo, mas sim utilizá-las como embasamento. A ferramenta proposta deverá: a) permitir revisar documentos de desenvolvimento (Requisito Funcional - RF); b) permitir elaborar planejamento dos testes (RF); c) permitir documentar o ambiente de teste necessário (RF); d) permitir elaborar casos de teste (RF); e) permitir documentar o resultado dos testes unitários (RF); f) permitir registrar e acompanhar defeitos (RF); g) permitir registrar resultados dos testes manuais (RF); h) permitir controlar quais ferramentas necessárias para o sucesso do projeto através da gerência de configurações do projeto de teste (RF); i) permitir registrar não conformidades no projeto para garantir a qualidade do produto (RF); j) permitir extrair resultados e medições do projeto através de indicadores (RF); k) permitir integrar os módulos, sendo que cada nível do processo representa um módulo (RF); l) utilizar o recurso PDE para sua construção (Requisito Não Funcional - RNF); m) utilizar a linguagem Java para sua construção (RNF); n) utilizar o banco de dados MySQL para persistir os dados (RNF).

36 ESPECIFICAÇÃO Nesta seção serão abordadas as especificações utilizadas para o desenvolvimento da ferramenta, diagrama de classe, diagrama de caso de uso e modelo de entidades e relacionamentos Diagrama de casos de uso ferramenta. Na figura 5, visualiza-se o diagrama de casos de uso utilizado para desenvolver a

37 36 Figura 5 Diagrama de casos de uso O diagrama de caso de uso apresenta dois atores: o administrador que irá inserir as informações necessárias para que os usuários possam utilizar a ferramenta e o usuário que é responsável por todas as atividades referentes ao processo MPT. No caso do usuário, as atividades são controladas por permissões individuais para cada atividade, cadastradas pelo administrador.

38 37 O detalhamento completo do diagrama de caso de uso apresentado na figura 5 está descrito no Apêndice A Diagrama de classes Na figura 6 pode-se visualizar o diagrama de classes da ferramenta com as classes descritas abaixo, nesse diagrama são exibidas apenas as classes de modelo da ferramenta. Figura 6 Diagrama de classes A classe ProjetoModel é a maior classe da ferramenta, pois ela é obrigatória para que existam todos os artefatos necessários para um projeto de teste baseado no MPT, nela

39 38 podemos encontrar todos os riscos do projeto, todas as atas de reunião do projeto, todas as suítes do projeto, todos os planos de teste do projeto, todas as tarefas referentes a esse projeto também estarão dentro dessa classe. A classe PlanoTesteModel é responsável por manter as informações necessárias para criar um plano de teste, que segundo Rios (2010), é o artefato principal para implementar o nível 1 do MPT.BR. Este foi desenvolvido baseado na documentação IEEE-829, pois Rios (2010) afirma que este artefato no MPT segue este padrão. A classe RiscoModel representa os riscos que serão cadastrados e mantidos no projeto de teste, este artefato seria um item dentro do plano de teste, mas para melhor controle dos riscos foi criada essa classe com um cadastro separado para os riscos. AtaReuniaoModel é onde são guardadas as informações das reuniões que ocorrem durante um projeto. Nesta classe são mantidas as informações de descrição, assunto, decisões, participantes, data da reunião e gerador, informações que são pertinentes em uma reunião. NaoConformidadeModel é a classe utilizada para registrar os artefatos cadastrados que estão em desacordo com o processo MPT.BR ou a falta de artefatos cadastrados no projeto. Para esses artefatos deve haver uma não conformidade cadastrada informando uma ação corretiva, para que o artefato fique de acordo com o processo deve haver uma ação preventiva. Para que essa não conformidade não volta mais a ocorrer. UsuarioModel representa as informações dos usuários da ferramenta como usuário, senha e nome, mas também guarda informações de permissões de acesso, onde o campo cadastraprojeto representa a permissão para cadastrar e editar projetos. O campo cadastraproduto representa a permissão para cadastrar e editar produtos. cadastraplanoteste é responsável pela permissão que o usuário tem de cadastrar e editar planos de teste. O campo cadastrasuiteteste controla a permissão para cadastrar e editar suítes de teste. Para controle do cadastro de listas de checagem de teste é utilizado o campo cadastrachecklistteste. O campo cadastrorisco controla a permissão para cadastrar e editar riscos. cadastraatareuniao é responsável pelo controle de quem pode cadastrar e editar atas de reunião. O campo cadastranaoconformidade controla a permissão de poder cadastrar e editar não conformidades para um projeto. cadastrarequisito é responsável pela permissão de cadastrar editar requisitos. O campo cadastracasoteste controla a permissão para cadastrar e editar casos de teste. A classe TarefaModel é utilizada para cadastrar os defeitos, sugestões de melhoria, implementações e atividades necessárias no produto que está sendo testado no projeto de

40 39 teste. Cada tarefa terá um responsável, uma criticidade, um estado representado pelo campo status. Também podem ser vinculadas à tarefa requisitos de teste e casos de teste para situações em que um defeito esteja ligado a um caso de teste executado, ou para necessidades de alterações em requisitos. ProvidenciaModel representa o andamento das tarefas de um projeto. Através desta classe são registradas as atividades feitas pertinentes a uma tarefa. Toda providência é caracterizada por uma descrição e um gerador. RequisitoTesteModel é responsável por manter as informações de um requisito cadastrado. Esses requisitos normalmente são compostos por um título, uma descrição, e um status para saber se o requisito já foi aprovado. A classe CasoTesteModel representa um caso de teste cadastrado na ferramenta. Os casos de teste são responsáveis por manter as informações da análise de teste do profissional. Os profissionais da área podem criar os passos do que precisa ser testado no produto. SuiteTesteModel é um agrupador da classe CasoTesteModel, que serve para facilitar o controle dos casos de teste, permitindo que o usuário agrupe os casos de teste por funcionalidade, tela, ou por algum critério próprio. ChecklistTesteModel representa um agrupador de casos de teste, os quais podem ser classificados com um estado de o teste passou ou falho, também pode-se informar o tempo de execução manual do caso de teste listado no checklist. ProdutoModel é a classe que representa o artefato do produto que será testado no projeto de teste, cada projeto de teste pode ter apenas 1 produto. Este é composto apenas por uma descrição. A classe CargoModel é um atributo da classe UsuarioModel e representa o cargo que o usuário está vinculado. RelatorioChecklistTesteModel é a classe que exibe o relatório com os resultados informados nos checklists de teste do projetos Na figura 7 visualiza-se o diagrama com as classes utilizadas para agrupar os artefatos.

41 40 Figura 7 Diagrama de classes de agrupamento A classe SetTarefasAbertas é uma necessidade para exibir as tarefas abertas em uma agrupador na árvore de projetos, pois a arquitetura exige que cada nível da árvore seja uma classe diferente. A classe SetTarefasFechadas agrupa todas as tarefas que já estão com o status fechadas dentro de um projeto. A classe SetNaoConformidadeModel é utilizada para agrupar as não conformidades de um projeto. SetAtaReuniaoModel é a classe utilizada para agrupar as reuniões realizadas e devidamente registradas durante um projeto. As classes SetProjetoAbertos e SetProjetosFechados são o topo da árvore de exibição dos projetos. Essas duas classes separam a visualização de projetos que ainda estão

42 41 em aberto e projetos que já foram finalizados e fechados. SetPlanoTesteModel agrupa os planos de teste cadastrados em um projeto de teste. A classe SetRequisitoTesteModel é responsável por agrupar os requisitos cadastrados em um projetos de teste. SetRiscoModel é a classe utilizada para agrupar o artefato risco, assim pode-se exibir os riscos do projeto agrupador. A classe SetSuiteTesteModel agrupa todas as suítes de teste de um produto dentro do projeto de teste. SetRelatorios é a classe que exibe o relatório de checklists de teste. Na figura 8 observa-se o diagrama de classes com as classes de log dos artefatos. Figura 8 Diagrama de classes de log

43 42 CasoTesteLogModel é utilizada para manter e exibir as alterações feitas em um caso de teste. Todas as classes de log são compostas por 3 campos que são, versao que é campo incremental para controle de versionamento, alterador que é o usuário que fez a alteração no artefato e dataalteracao que guarda a data e hora que foi feita a alteração. Além dos campos apresentados também mantem os campos estendidos da classe pai, o qual são as informações do artefato antes da alteração. A necessidade de gravar os logs de alteração de alguns artefatos é especificada no guia do MPT observa Softex Recife (2010a), pede-se que os dados estejam mantidos de forma segura em ambiente adequado com controle de versões.. A classe PlanoTesteLogModel apresenta as alterações efetuadas em um plano de teste do projeto. RequisitoTesteLogModel representa o log de uma alteração feita em um requisito de teste. A classe NaoConformidadeLogModel guarda as informações anteriores de uma não conformidade quando ela é alterada. AtaReuniaoLogModel é utilizada para manter e exibir as alterações feitas em uma ata de reunião. A classe RiscoLogModel representa o log de uma alteração feita em um requisito de teste. 3.3 IMPLEMENTAÇÃO A seguir são apresentadas as técnicas e ferramentas utilizadas, a operacionalidade da implementação através de um estudo de caso Técnicas e ferramentas utilizadas Nesta seção são apresentadas as técnicas utilizadas, apresentando as particularidades

44 43 do ambiente PDE e a ferramenta Visual Editor descrevendo sua importância no desenvolvimento das telas e MySQL utilizado como banco de dados Plug-in Development Environment Para a ferramenta desenvolvida neste trabalho foi utilizado o PDE, disponibilizado pelo próprio Eclipse para criar e desenvolver plug-ins para o IDE Eclipse. Foi escolhido desenvolver a ferramenta em forma de plug-in por ela ser feita em JAVA, uma das tecnologias mais atuais e que dispõe de ambientes de desenvolvimento gratuito. Mas o motivo principal foi tornar o Eclipse como uma ferramenta única em empresas de desenvolvimento de software que utilizem este ambiente para o desenvolvimento e para o gerenciamento dos testes. O desenvolvimento de um plug-in para o Eclipse tem uma série de particularidades, de sua biblioteca interna, que serão apresentadas ao longo desta seção. Todas as classes utilizadas devem conter um atributo ID e devem ser todas registradas no arquivo plug-in.xml do projeto para que o Eclipse possa reconhecê-las como pertencentes ao plug-in. Na figura 9 apresenta-se a tela de registro das classes no arquivo XML do plug-in.

45 44 Figura 9 Tela de registro das classes utilizadas no plug-in Para a criação de um editor, o qual foi utilizado para desenvolver as telas de cadastro dos artefatos, é necessário estender a classe EditorPart. Com a extensão da classe são adicionados os métodos da classe pai. Um dos métodos é o init, que é executado ao abrir a tela. Funciona como um construtor, só que com parâmetros definidos pelo Eclipse, sendo esses parâmetros um IEditorSite, que faz a ligação lógica do Eclipse com a tela que está sendo aberta e um IEditorInput que contêm as informações que serão exibidas na tela. O IEditorSite é a primeira interface entre o editor e o IDE que é apresentada como workbench na literatura. Para fazer a ligação da tela que está sendo aberta com o workbench é necessário utilizar o método setsite, passando o IEditorSite como parâmetro. Com isso a tela está ligada ao ambiente do Eclipse e pode ser aberta. Já o IEditorInput é uma interface que vai ser utilizada para todas as telas que são necessárias abrir. Cada classe de tela que precisa ser aberta necessita de uma outra classe que implemente essa interface e que manipule os dados necessários para o funcionamento da tela, pois todo o editor necessita receber um IEditorInput para conseguir passar informações de um componente qualquer para um editor, no caso deste trabalho, de um componente ViewPart, que ainda será explicado, para um componente EditorPart.

46 45 Na figura 10 observa-se um exemplo do método init. Figura 10 Exemplo do método init O método dosave, também herdado, é utilizado para salvar as informações que estão no editor e onde são feitas todas as validações de formulário. Porém, para que a opção de salvar seja feita pelo teclado através do comando Ctrl+S, foi necessário criar uma classe para cada editor, essa classe é responsável por ligar o comando ao método. Um método essencial da classe EditorPart que é utilizado na classe da tela é o createpartcontrol. Este método é responsável por desenhar a parte visual da tela. E recebe como parâmetro um Composite que é a tela onde podem ser desenhados os elementos gráficos. Tudo o que foi desenhado neste método precisa colocar o Composite, recebido como parâmetro, como elemento pai. Na figura 11 tem-se um exemplo do método createpartcontrol.

47 46 Figura 11 Exemplo do método createpartcontrol Para a criação da parte visual de uma view é necessário sobrescrever o método createpartcontrol. Esta view é utilizada para fazer toda a parte de visualização dos usuários cadastrados, dos cargos, dos produtos, da hierarquia dos projetos e todos os seus artefatos. Na criação de uma classe que será a view é necessário estender a classe ViewPart para que seja possível sua visualização dentro do Eclipse. A partir da extensão serão adicionados alguns métodos para o funcionamento da view. A atualização da view, quando se faz necessária por alguma ação em um editor, foi feita através da implementação de um método estático chamado refresh na classe da view. Assim quando um usuário fizer uma alteração em uma classe através de um editor, é necessário apenas chamar esse método para a view listar as informações atualizadas. Na figura 12 é apresentado o método refresh da classe ProjetoView.

48 47 Figura 12 Método refresh da classe ProjetoView O método createpartcontrol, gerado na extensão tem o mesmo princípio do método de mesmo nome do EditorPart. É o responsável por desenhar a parte gráfica da view. Para este trabalho foi escolhido desenhar a parte gráfica da view com a classe TreeViewer. Assim as informações exibidas ficaram em forma de árvore hierárquica, podendo-se visualizar os artefatos que estão dentro de cada projeto individualmente. Para a utilização do componente visual TreeViewer é necessário definir um modelo de dados para as informações nele exibidas. Esse modelo é indicado pelo método setinput da classe, no qual é passado um conjunto de elementos já em forma hierárquica. Como este modelo de dados é único, ele trata somente uma classe. Para isso foi criado uma interface chamada IElementView para identificar as classes que serão listadas na view. Assim todas as classes que implementarem essa interface podem ser listadas na view e terão os métodos necessários para a view manipular a exibição das classes. Na figura 13 visualiza-se a interface IElementView. Figura 13 Classe IElementView

49 48 O modelo de dados da árvore de visualização utiliza o método getdescricao desta classe como texto para o item na árvore. O método getelementsfilhos é utilizado para exibir na view as classes que estão dentro da classe que está sendo listada. No caso da classe ProjetoModel, ela irá listar os conjuntos dos artefatos que formam aquele projeto. Para adicionar alguma classe em um elemento da árvore de visualização é utilizado o método addelementfilho e para remover algum item é utilizado o método removeelementfilho, esses métodos são utilizados nos casos de inclusão e exclusão de artefatos, respectivamente. Para adicionar e excluir itens da view, foi criado um menu de contexto, no qual é apresentado as opções de incluir um elemento filho ou excluir o elemento selecionado. Essas opções são exibidas por um listener que adiciona um elemento Menu na view, tomando esse menu de uma classe que, no caso da view de projeto, se chama ProjetoViewContextMenu. Essa classe é que decidem quais opções devem ser exibidas para o usuário e retorna um elemento gráfico Menu com os elementos MenuItem, dependendo de permissões e de qual elemento na view recebeu o evento do clique. Como a ferramenta precisa de configurações como banco de dados, módulos que serão utilizados, usuário e senha, utilizou-se a classe MPTPreferencePage para criar uma página de configurações dentro do Eclipse com as informações necessárias. Essa classe estende a classe FieldEditorPreferencePage, que adiciona à classe o método createfieldeditors, no qual foram declarados os campos necessários para a tela de configurações do MPT.BR. Essa página de preferências fica disponível no Eclipse através do menu Window na opção preferences e guarda local as informações recebidas pela tela. Na figura 14 apresenta-se a classe responsável por gerar a tela de configurações.

50 49 Figura 14 Classe responsável pela tela de configurações da ferramenta Visual Editor Para a criação da parte gráfica da ferramenta desenvolvida foi utilizado um plug-in do Eclipse chamado Visual Editor. Esse plug-in foi desenvolvido pelo Eclipse em um projeto interno. O projeto Visual Editor do Eclipse é uma ferramenta para a criação de interfaces GUI no Eclipse. Ela suporta o desenvolvimento de interfaces gráficas para JAVA, a saber: Swing, AWT, SWT, RCP. Este último é utilizado para a criação das telas de um plug-in para o Eclipse. Como o Visual Editor já é incluído no Eclipse, a pasta RCP que contém as opções de criar um novo Editor Visual Class e um View Visual Class tornam-se visíveis. Elas são as duas partes gráficas nas quais há necessidade de desenha-se para criar um plug-in. Além destas, está disponível também opções para AWT, Swing e SWT. Na figura 15 é possível visualizar a tela de criação de um novo editor através do item Editor Visual Class ou uma nova área de visualização através do item View Visual Class com o plug-in Visual Editor.

51 50 Figura 15 Itens disponíveis pelo Visual Editor A visualização da classe criada pelo Visual Editor é dividida em três partes, na figura 16 é possível visualizá-las.

52 51 Figura 16 Classe gerada pelo Visual Editor A parte superior da figura 16 apresenta a visualização gráfica da classe gerada, onde podem ser arrastados componentes para criar a parte gráfica sem a utilização do código fonte. A parte do meio representa o código fonte da classe. As alterações feitas no código fonte refletem automaticamente na visualização gráfica. Com isso ao fazer qualquer alteração pelo código, é possível visualizar o resultado na parte de visualização gráfica. A parte inferior apresenta os componentes visuais inseridos na classe, de forma hierárquica, para facilitar a visualização de como está estruturada a classe. Na figura 17 observa-se o menu de componentes visuais do Visual Editor. Figura 17 Menu de componentes do Visual Editor Para a utilização dos componentes basta clicar no componente desejado e após isso clicar na posição da parte gráfica do visual editor para incluir o componente na sua classe.

53 Banco de dados O banco de dados utilizado foi o MySQL, pelo fato de ele ser livre e oferecer ferramentas de fácil manipulação. Hutters (2010) afirma que o MySQL tem um poder de alta escalabilidade e um atrativo custo benefício, visto que as aplicações podem manter o mesmo ritmo com o aumento do volume de dados. Para utilizar o MySQL no plug-in desenvolvido existe uma particularidade do ambiente de desenvolvimento do Eclipse, pois não é possível importar e instanciar o driver do banco de dados diretamente, pois a arquitetura não reconhece o a biblioteca, foi necessário criar um plug-in a partir dos arquivos do MySQL e importar este plug-in no plug-in desenvolvido para este trabalho Operacionalidade da implementação Nesta seção é apresentado um estudo de caso das funcionalidades da ferramenta. Este estudo de caso é feito através de um projeto de teste de um software de vídeo locadora fictício. A ferramenta tem por objetivo automatizar o gerenciamento de artefatos para o gerenciamento de projetos de testes, sendo que os artefatos são baseados nas práticas dos níveis 1 e 2 do processo MPT.BR. É nessa ferramenta que serão cadastrados os artefatos necessários nestes níveis do processo com o intuito de padronizar e centralizar os artefatos de um projeto de teste. Os usuários terão acesso restrito aos artefatos possíveis dentro da ferramenta. Para atender o caso de uso de cadastrar configurações, foi desenvolvida uma tela de configurações juntamente com as demais configurações do Eclipse para que possam ser informadas algumas configurações básicas, conforme descrito abaixo. Como a ferramenta é um plug-in do Eclipse, precisa-se configurar o usuário e senha que acessará o sistema, configurar a base de dados que será utilizada pela ferramenta e configurar os módulos em uso da ferramenta. Para visualizar a tela de configurações do MPT.BR é necessário selecionar a opção Window no menu do Eclipse, em seguida clicar em preferences. Com isso é aberta uma tela

54 53 das configurações do Eclipse. Nessa tela existe um item no menu, com a descrição Configurações MPT. Ao clicar nesta opção é aberta a tela de configurações da ferramenta. Na figura 18 visualiza-se a tela de configurações. Figura 18 Tela de configurações do MPT A seguir identifica-se os campos de configuração da ferramenta: a) Usuário: informa-se o usuário que acessa a ferramenta; b) Senha: informa-se a senha do usuário que acessa a ferramenta; c) Banco de dados: informa-se a conexão para a base de dados que se utilizará na ferramenta. O usuário e senha utilizados para a conexão com o banco de dados são definidos de maneira fixa no próprio código da ferramenta. Isto foi feito para não expor estes dados ao usuário final; d) Ativar nível 2 do MPT: informa-se o uso do nível 2 do processo MPT na ferramenta. Para abrir as telas da ferramenta no Eclipse é necessário ir à opção do menu

55 54 Window, em seguida selecionar Show view, após isso clique em other. Neste momento o Eclipse abre uma lista com todas as telas de visualização que ele possui. As telas da ferramenta desenvolvida estão dentro da pasta MPT, conforme exibido na figura 19. Como o Eclipse não permite fazer a validação de usuários para abrir as views, as validações são feitas dentro de cada tela. Com isso todos os usuários conseguirão visualizar essas views para abrir, mas ao abrir poderão fazer apenas o que suas permissões deixarem. Figura 19 Exibição das telas disponíveis Visualização de cargos Para atender o caso de uso de cadastro de cargos foi desenvolvida uma View de cargos para listar os cargos existentes e um cadastro de cargos. A View de Cargos é utilizada para listar todos os cargos cadastrados na ferramenta. Também permite cadastrar novos cargos. Na figura 20 é possível visualizá-la.

56 55 Figura 20 View de cargos Essa View somente terá ações disponíveis para o administrador da ferramenta, que poderá adicionar, alterar e excluir cargos. Para inserir um cargo o usuário deve clicar com o botão direto no mouse na View, que aparecerá um menu flutuante com a opção Inserir cargo. Ao clicar nessa opção o sistema adiciona um registro na View com a descrição >Novo cargo. Ao clicar nesse novo registro a ferramenta abre o formulário de cadastro do cargo, conforme a figura 21. Figura 21 Formulário de cadastro de cargos Neste caso, como exemplo, insere-se o cargo de analista de testes. No formulário de cadastro de cargos contém apenas um campo texto no qual é preenchido pelo usuário com a descrição do cargo que ele deseja cadastrar. O formulário foi desenvolvido sem botões, então, para salvar o registro, o usuário precisa pressionar as teclas ctrl+s para que o registro seja salvo no banco de dados e que seja atualizado na View de cargos, apresentando a View conforme a figura 22. Caso o usuário deixe o campo descrição vazio e tente salvar, o sistema não salva o registro e exibe uma mensagem para o usuário informando que a descrição do cargo é obrigatória.

57 56 Figura 22 Visualização de cargos com um registro Para excluir o registro da View, o usuário deve clicar com o botão direito do mouse sobre o registro de interesse. Essa ação exibe um menu flutuante com a opção Remover cargo. Clicando nessa opção a ferramenta exclui o cargo Visualização de usuários Para atender o caso de uso de cadastro de usuário e cadastro de permissões foi desenvolvido a View de usuários para visualizá-los e o formulário de cadastro de usuários, que inclui o vínculo das permissões para cada usuário, conforme descrito em seguida. A View de usuário lista todos os usuários cadastrados na ferramenta, permitindo adicioná-los e excluí-los. Nesta tela o usuário visualizará o registro do usuário administrador já na primeira vez que acessar, pois este usuário é inserido na criação da base de dados. Na figura 23 observa-se a View de usuários. Figura 23 Visualização de usuários Para adicionar um usuário clica-se com o botão direito do mouse sobre a View de usuário. Com isso a ferramenta exibirá um menu flutuante com a opção Inserir Usuário. Ao clicar nesta opção a ferramenta adiciona um registro na View com a descrição >Novo usuário. Para Informar os dados deste usuário e salvá-lo é necessário dar um duplo clique com o mouse sobre o seu registro na View. Com isso a ferramenta abre o formulário de cadastro do usuário, conforme figura 24.

58 57 Figura 24 Formulário de cadastro de usuário Neste caso como exemplo adiciona-se um usuário analista de teste, com permissão para todos os cadastros. O campo nome representa o nome completo do usuário que está sendo inserido ou alterado, por isso foi preenchido com o nome Daniel Ricardo de Amorim. Os campos usuário e senha representam o usuário e senha que será informado pelo usuário na tela de configurações da ferramenta. Foi inserido usuário daniel e senha O campo cargo representa o cargo do usuário, o qual é um combo onde seleciona-se um dos cargos já existentes. Neste exemplo selecionou-se o cargo de analista de testes. As permissões representam as ações que o usuário poderá fazer dentro da ferramenta, sendo que a permissão de cadastrar vale também para edição do artefato. No exemplo marcaram-se todas as permissões para utilizar este usuário em todo estudo de caso. Para salvar as informações do usuário após preencher o formulário, pressionam-se as teclas ctrl+s. Com isso a ferramenta valida os dados e caso os campos nome, usuário, senha e cargo estejam preenchidos corretamente, a ferramenta salva o novo usuário e atualiza a View de usuários. Caso algum dos campos mencionados não tenha sido preenchido, a ferramenta exibe uma mensagem para o usuário informando que o campo não preenchido é obrigatório para que possa ser salvo o novo usuário. Para excluir-se um usuário clica-se com o botão direito do mouse sobre o usuário, na View de usuários, que se deseja excluir. Com isso a ferramenta exibe um menu com a opção

59 58 Remover usuário. Ao clicar nesta opção a ferramenta valida se o usuário não tem vínculo com algum artefato criado e exclui-o. Caso ele tenha vínculo com algum artefato, a ferramenta exibe a mensagem de que ele não pode ser excluído, pois tem vínculo com algum artefato. O usuário administrador nunca pode ser excluído Visualização de produtos Para atender o caso de uso 08, cadastrar produtos, foi desenvolvida uma View de produtos para listar os produtos cadastrados e um formulário de cadastro de produtos, que estão descritos em seguida. A View de produtos lista todos os produtos cadastrados na ferramenta. Esses produtos são associados ao projeto para criar um vínculo com qual produto o projeto de teste será realizado. Na figura 25 observar-se a visualização de produtos. Figura 25 Visualização de produtos Para adicionar um produto, clica-se com o botão direito do mouse sobre a View de produtos. Com isso a ferramenta exibe um menu flutuante com a opção Inserir produto. Clicando nesta opção é adicionado um registro na View. Para adicionar as informações neste registro e salvá-lo, deve-se dar um duplo clique no novo registro para abrir o formulário de cadastro de produtos, exibido na figura 26. Figura 26 Formulário de cadastro de produtos Neste formulário adiciona-se o nome do software que será testado no projeto. Para o estudo de caso utilizou-se o nome Vídeo Locadora, pois é o software que se está testando na

60 59 demonstração da ferramenta. Para isto preenche-se o campo descrição com o nome do software. Para salvar este registro pressionam-se as teclas ctrl+s. Com isso a ferramenta valida se o campo descrição foi preenchido, salva o registro e atualiza a View de produtos. Caso o campo descrição não esteja preenchido, a ferramenta exibe a mensagem de que o campo descrição é obrigatório. Para excluir um produto clica-se com o botão direito sobre o registro na View de produtos. Com isso a ferramenta exibe um menu flutuante com a opção Remover produto. Ao clicar nesta opção, a ferramenta valida se o produto ainda não tem vínculo com um projeto e exclui-lo. Caso o produto esteja vinculado a um projeto, a ferramenta exibe a mensagem de que o produto não pode ser excluído devido ao vínculo Estudo de caso Para atender os demais casos de uso envolvendo os cadastros de projeto, requisito, riscos, plano de teste, tarefa, ata de reunião, checklist de teste, caso de teste e suíte de teste foi desenvolvido uma View de projetos, na qual é possível cadastrar todos os artefatos de um projeto de teste. Na figura 27 visualiza-se a View de projetos. Figura 27 Visualização de projetos A exibição dos projetos é dividida entre projetos abertos e projetos fechados. Para adicionar um projeto, clica-se na View de projetos com o botão direito sobre a opção Abertos. Essa ação abre um menu flutuante com a opção Novo projeto. Clicando-se nela a ferramenta adiciona um projeto dentro da divisão Abertos. Para isso o usuário deve ter permissão para cadastrar projetos, caso contrário o menu flutuante não é exibido. Para preencher as informações do projeto, dá-se um duplo clique no novo registro. Então a ferramenta abre o formulário de cadastro de projeto, exibido na figura 28.

61 60 Figura 28 Formulário de cadastro de projetos Neste formulário adiciona-se o projeto de teste que será utilizado para testar o produto cadastrado. Para exemplificar o estudo de caso, adicionou-se o projeto Vídeo Locadora Teste. O campo descrição representa a descrição do projeto. Neste preencheu-se com a descrição citada acima. O campo produto representa o produto que será tratado no projeto de teste, neste caso selecionou-se o produto Vídeo Locadora. O campo status indica se o projeto está aberto ou fechado. Colocou-se como aberto pois será utilizado até o final deste estudo de caso. O campo participantes representa quais usuários estão vinculados ao projeto em questão. Escolheu-se o usuário Daniel Ricardo de Amorim. Abaixo dos participantes do projeto, pode-se visualizar os indicadores do projeto, sendo eles, tarefas abertas, não conformidades abertas, caso de teste com mais erros e tarefas abertas na última semana. Para salvar o projeto pressionam-se as teclas ctrl+s. Com isso a ferramenta valida se a descrição do projeto foi preenchida, um produto selecionado e como participantes do projeto deve haver no mínimo o usuário que está criando o projeto. Para remover um projeto clica-se com o botão direito do mouse sobre o projeto e clicase na opção Remover projeto que é exibido no menu flutuante. Para isso ele não pode ter qualquer artefato cadastrado, caso contrário ele pode ser apenas fechado. A visualização do projeto na View de projetos após sua inclusão é dada na figura 29. Figura 29 Visualização do projeto cadastrado Os projetos cadastrados possuem (dentro de si) um agrupador para cada artefato

62 61 possível, apresentados em seguida. Para adicionar uma ata de reunião clica-se sobre o agrupador Atas de reunião e clicase sobre a opção Nova ata de reunião. Com isso a ferramenta adiciona um registro de uma ata de reunião dentro do agrupador Atas de reunião, procedimento permitido apenas a usuários com permissão. Para preencher as informações da ata, o usuário dá um duplo clique no registro da ata de reunião. Assim a ferramenta abre o formulário de preenchimento da ata de reunião, conforme figura 30. Figura 30 Formulário de cadastro de ata de reunião Como exemplo do estudo de caso, cadastraram-se os dados da reunião inicial do projeto. O formulário de cadastro de ata de reunião possui os campos: a) descrição: representa uma descrição textual para a ata de reunião; b) assunto: representa os assuntos abordados na reunião que gerou o artefato; c) decisões: representa as decisões tomadas sobre o assunto na reunião que gerou o artefato; d) participantes: representa as pessoas que estiveram presentes na reunião; e) data: representa a data que ocorreu a reunião. Para salvar a ata de reunião com as informações preenchidas no formulário pressionam-se as teclas ctrl+s. Com isso a ferramenta valida se todos os campos foram preenchidos e o salva. Juntamente com o registro, a ferramenta salva um log da ação tomada.

63 62 Após salvá-lo, a ferramenta desabilita o formulário e habilita somente o botão Nova versão. O artefato de ata de reunião faz a ferramenta atender parcialmente todas as práticas que tem como produto típico uma ata de reunião. Na figura 31 visualiza-se o registro da ata de reunião na view de projetos. Figura 31 Ata de reunião da visualização de projetos Os registros com a descrição de data e hora dentro do registro da ata de reunião representam os logs das alterações feitas. Ao dar um duplo clique em um registro do log é possível visualizar as informações da ata de reunião na data e hora descritas. Este comportamento de log e repete para os artefatos de não conformidade, plano de teste, requisito de teste, casos de teste e riscos. Para fazerem-se alterações necessita-se que o usuário clique no botão Nova versão. Assim o formulário é habilitado para alterações seguindo os mesmo procedimentos de salvar a ata de reunião. O procedimento de excluir uma ata de reunião inicia-se clicando com o botão direito do mouse na View de projetos sobre a ata de reunião que deseja-se excluir e clica-se na opção Remover ata de reunião. Esse procedimento é permitido apenas para usuários com permissão. Já com a equipe e os objetivos do projeto apresentados, os integrantes na reunião de inicial, pode-se adicionar os riscos e preenche-se o plano de testes do projeto. Risco é o artefato no qual mantém-se os registros de todos os riscos encontrados no projeto, este artefato é um item dentro do plano de testes segundo o guia de implementação do MPT.BR, mas para melhor controle dos riscos foi feito um artefato separado. Para adicionar-se um risco clica-se com o botão direito sobre o agrupador de riscos e seleciona-se a opção Novo risco. Com isso a ferramenta adiciona um registro de risco dentro do agrupador de riscos. Essa ação é permitida para usuários com permissão. Para preencher as informações do risco, dá-se um duplo clique sobre o registro do risco para abrir o formulário de risco. Observa-se o formulário de risco na figura 32.

64 63 Figura 32 Formulário de risco Os campos do formulário de risco são: a) título: representa um identificador para o risco; b) descrição: representa a descrição do risco; c) responsável: representa o usuário responsável por monitorar e tratar o risco; d) gerador: representa quem gerou o risco; e) impacto: representa o impacto do risco perante o projeto; f) probabilidade: representa a probabilidade do risco ocorrer durante o projeto; g) tipo: representa o tipo do risco, podendo ser um risco de projeto ou um risco de produto; h) mitigação: representa a descrição do plano de mitigação para o risco; i) contingência: representa a descrição do plano de contingência para o risco. Para salvá-lo e excluí-lo, segue-se o mesmo padrão de operação do artefato ata de reunião. O artefato risco da ferramenta atende a prática específica Determinar e documentar os riscos do projeto de teste, assim como seu impacto, probabilidade de ocorrência e prioridade de tratamento do nível 1 do MPT.BR. O plano de teste representa o artefato principal do planejamento do projeto de teste. Este artefato contém as informações que guiarão o andamento do projeto. O procedimento para adicionar um plano de teste é clicar com o botão direito do mouse sobre o agrupador de planos de teste e clicar na opção Novo plano de teste, caso o usuário tenha permissão. Após essa ação, a ferramenta adiciona um registro dentro do

65 64 agrupador de planos de teste. Para preencher as informações do plano de teste dá-se um duplo clique no registro adicionado para que a ferramenta abra o formulário de plano de teste, como apresentado na figura 33. Figura 33 Formulário de plano de teste Os campos de um plano de testes são: a) título: identificador textual do plano de teste; b) propósito: representa o propósito do plano de testes existir; c) introdução: apresenta uma introdução do que abordará o plano de teste; d) itens testados: representa os itens que serão planejados para teste neste plano de teste; e) funcionalidades: representa as funcionalidades que engloba o plano de teste; f) abordagem: representa a estratégia de testes utilizada no plano de teste e que será utilizada no teste do produto durante o projeto; g) aceite: representa as condições nas quais serão aceitas a liberação do produto; h) suspensão: representa as condições que serão suspensas as atividades de teste; i) produtos: representa os artefatos externos que influenciam no planejamento dos testes; j) ambiente: representa o ambiente necessário para realizar os testes, contando desde ambiente físico, estações de trabalho, ferramentas e softwares; k) responsabilidades: apresenta as responsabilidades de cada integrante do projeto; l) treinamentos: treinamentos necessários para que a equipe do projeto esteja apta a atuar no mesmo;

66 65 m) cronograma: representa as entregas e marcos do projeto. Para salvá-lo e excluí-lo segue-se o padrão descrito no artefato ata de reunião. O artefato plano de teste propõe-se a auxiliar o atendimento de algumas práticas do MPT.BR, sendo elas Definir o escopo do trabalho para o projeto, Estabelecer estimativas para o tamanho das tarefas e dos produtos de trabalho do projeto de teste utilizando métodos apropriados, Estimar o esforço e o custo para a execução das tarefas e dos produtos de trabalho com base em dados históricos ou referências técnicas, Estabelecer e manter o orçamento e cronograma do projeto de teste, incluindo marcos e/ou pontos de controle, Planejar os recursos humanos para o projeto considerando o perfil e a proficiência necessários para executá-lo, Planejar as tarefas, os recursos não Humanos e o ambiente de trabalho necessário para executar o projeto de teste, Identificar e planejar os artefatos e dados relevantes do projeto de teste quanto à forma de coleta, armazenamento e distribuição, Estabelecer os planos para a execução do projeto de teste e reunir no Plano de teste. Não conformidades são utilizadas para registrar inconsistências entre os artefatos cadastrados no projeto e o processo MPT.BR. Caso algum artefato esteja fora das práticas do processo deve-se registrar uma não conformidade para que um usuário possa tratar essa inconsistência. Os passos para adicionar uma não conformidade seguem o padrão dos demais artefatos. Clica-se com o botão direito sobre o agrupador de não conformidades e clica-se na opção Nova não conformidade, ação permitida apenas para usuários com permissão. Diante destes passos, a ferramenta adiciona um registro dentro do agrupador de não conformidades. Ao dar-se um duplo clique no registro adicionado, a ferramenta abre o formulário de preenchimento do artefato. Na figura 34 observa-se o formulário de não conformidade. Figura 34 Formulário de cadastro de não conformidade

67 66 Os campos disponíveis no cadastro de não conformidades são: a) título: representa uma descrição textual para a identificação da não conformidade; b) artefato: representa a descrição do artefato que está em desacordo com o processo; c) não conformidade: representa o que dentro do artefato informado está fora das práticas do processo MPT.BR; d) ação corretiva: representa a ação que o usuário participante do projeto vai tomar para corrigir o artefato; e) ação preventiva: representa a ação que o usuário participante do projeto vai tomar para que a inconsistência do artefato não volte a ocorrer; f) status: representa o status da não conformidade, sendo ela aberta, caso ainda não tenha sido tratada ou fechada caso já tenha sido tratada. Para salvá-lo e excluí-lo segue-se o mesmo procedimento descrito no artefato ata de reunião. O artefato de não conformidade auxilia no atendimento da prática Monitorar e controlar o processo. O requisito de teste é o artefato que guiará a criação de casos de teste, com ele tem-se quais as funcionalidades do software deve-se testar. Este artefato esta disponível na ferramenta somente com o nível dois do processo habilitado, perante configuração da ferramenta exibida anteriormente. Para adicionar um requisito, clica-se com o botão direito do mouse sobre o agrupador requisitos e clica-se na opção Novo requisito, disponíveis apenas para usuários com permissão. Isso faz com que a ferramenta adicione um registro dentro do agrupador de requisitos. Para preencher as informações do requisito, clica-se duplamente sobre o registro abrindo o formulário de requisito de teste exibido na figura 35.

68 67 Figura 35 Formulário de requisitos de teste Os campos presentes no formulário de requisito de teste são: a) título: representa um identificador textual do requisito de teste; b) descrição: representa a descrição do requisito de teste; c) casos de teste: representa os casos de teste que o requisito tem vínculo, mantendo a rastreabilidade. Este artefato é vinculado ao produto e não ao projeto, com isso pode-se criar outros projetos para o mesmo produto que o requisito estará no novo projeto. Para salvá-lo ou excluí-lo segue-se o padrão descrito no artefato ata de reunião. O artefato de requisito de teste auxilia no atendimento da prática específica Gerenciar as alterações dos requisitos no projeto de teste. A suíte de testes é um simples agrupador de casos de teste, normalmente utilizado para separar os casos de teste por funcionalidade, artefato disponível somente no nível 2 do processo MPT conforme configuração explicada anteriormente. Para adicionar uma suíte de teste, clica-se com o botão direito do mouse sobre o agrupador de suítes de teste e clica-se na opção Nova suíte de teste, ação permitida somente para usuários com permissão. Com isso a ferramenta adiciona um registro dentro do agrupador de suítes de teste. Para preencher a descrição da suíte, que é seu único campo, dá-se um duplo clique no registro adicionado, que a ferramenta abre o formulário para preencher a descrição da suíte de teste, conforme exibido na figura 36. Figura 36 Formulário de suíte de teste

69 68 O único campo que compõe o formulário da suíte de teste é a descrição, pelo fato de ele ser apenas um agrupador de casos de teste com uma descrição livre ao usuário. Este artefato é vinculado ao produto e não ao projeto, com isso pode-se criar outros projetos para o mesmo produto que a suíte estará no novo projeto. Para salvá-lo e excluí-lo segue-se o padrão descrito no artefato ata de reunião. Caso de teste é um artefato que só é disponível com a ferramenta configurada para atender o nível 2 do processo. Neste artefato são escritos os testes que serão feitos em determinada funcionalidade. Tem vinculo com o requisito de teste, pois é neste que ele deve basear-se para criar os casos de teste. Assim mantém a rastreabilidade bidirecional. Para adicionar um caso de teste precisa-se da existência de uma suíte de testes, pois é nela que clica-se com o botão direito do mouse para exibir a opção de Novo caso de teste. Isso insere um registro de caso de teste dentro da suíte. Para preencher as informações do caso de teste dá-se um duplo clique sobre o registro de caso de teste adicionado, abrindo-se o formulário de preenchimento do caso de teste exibido na figura 37. Figura 37 Formulário de caso de teste Os campos do formulário de caso de teste são: a) título: representa um identificador textual para o caso de teste; b) pré-condições: representa o estado que deve-se estar para iniciar a execução do caso de teste; c) passos: representa os passos que o executor do caso de teste deve fazer para testar o que foi proposto no caso de teste; d) resultado esperado: representa o resultado que os passos devem gerar após serem feitos; e) requisitos: representa os requisitos que o caso de teste escrito está cobrindo.

70 69 Para salvá-lo e excluí-lo segue-se o padrão descrito no artefato ata de reunião. O caso de teste auxilia no atendimento da prática específica Estabelecer e manter a rastreabilidade bidirecional entre os requisitos e artefatos de teste. Com os casos de teste prontos, pode-se selecioná-los para distinguir quais deles serão executados em determinado momento ou marco do projeto. Para isso utiliza-se um checklist de teste. Checklists de teste são utilizados para agrupar casos de teste de modo que possam ser executados manualmente pelos usuários e que os resultados dos testes possam ser registrados, bem como o tempo de execução e status. Para adicionar um checklist de teste clica-se com o botão direito do mouse sobre o agrupador de checklists e clica-se em Novo checklist de teste. Com esta ação a ferramenta adiciona um registro do artefato ao agrupador, procedimento permitido apenas a usuários com permissão. Para preencher o checklist de teste dá-se um duplo clique sobre o registro adicionado. Esta ação faz com que a ferramenta abra o formulário de cadastro do checklist de teste, conforme observa-se na figura 38. Figura 38 Formulário de cadastro de checklists O formulário de checklists de teste apresenta os campos: a) descrição: representa uma descrição textual para o checklist de teste; b) data de criação: representa a data que foi criado o checklist;

71 70 c) casos de teste: representa os casos de teste estão vinculados ao checklist de teste; d) tempo de execução: representa o tempo que o usuário demorou para executar o teste manual do caso de teste selecionado; e) status: representa o status da execução manual do caso de teste selecionado. Para salvá-lo e excluí-lo segue-se o padrão descrito no artefato ata de reunião. Tarefa é o artefato onde registra-se algum acontecimento ou necessidade de atividade no projeto. Nela registra-se erros, sugestões, melhorias, implementações do produto, atividades a serem executadas como analise de casos de teste, criação de plano de teste, criação de requisito e manutenção de artefatos. Na figura 39 visualiza-se o formulário de tarefa. Figura 39 Formulário de tarefa Os campos do formulário são: a) título: representa o título da tarefa; b) descrição: representa a descrição da tarefa; c) caso de teste: representa o caso de teste que a tarefa tem vínculo. d) responsável: representa o responsável por executar a atividade prevista na tarefa; e) data de criação: representa a data que foi criada a tarefa; f) data de fechamento: representa a data que foi fechada a tarefa; g) criticidade: representa a criticidade da tarefa;

72 71 h) requisito: representa o requisito que a tarefa vem vínculo; i) status: representa o status da tarefa, podendo estar aberta ou fechada; j) providência: - descrição: representa a descrição do trâmite, - gerador: representa o usuário que gerou o trâmite, - data de criação: representa a data de criação do trâmite. Para salvá-lo e excluí-lo segue-se o mesmo padrão do artefato ata de reunião. O artefato de tarefa auxilia o atendimento da prática Estabelecer os registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, assim como tratar os mesmos com as partes interessadas. O relatório de checklist de teste é utilizado para visualizar o resultado de um checklist de teste de um modo macro, conseguindo visualizar ao mesmo tempo o resultado de todos os casos de teste presentes em um checklist de teste. Na figura 40 visualiza-se o relatório de checklist de teste. Figura 40 Relatório checklist de teste