Módulo de Testes da GP. Ferramenta de Gestão de Testes

Transcrição

1 FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO MESTRADO EM ENGENHARIA INFORMÁTICA Módulo de Testes da GP Ferrameta de Gestão de Testes Testes e Qualidade de Software 22 de Juho de 2005 Luís Ramos Sumário 1. Itrodução Cotexto Ferrametas de Gestão de Testes - Aálise Bugzilla Test Ruer Mercury Iteractive Test Director Especificação e Desevolvimeto Cotexto Módulo de Testes da GP Coclusões Referêcias... 24

2 Ferrametas de Gestão de Testes 1. Itrodução Âmbito Este trabalho foi desevolvido o âmbito da disciplia de Testes e Qualidade de Software do Mestrado em Egeharia Iformática da Faculdade de Egeharia da Uiversidade do Porto. Objectivo O objectivo deste trabalho é fazer um estudo de ferrametas de gestão de testes e especificar e desevolver uma ova ferrameta de gestão de testes. A área cietífica em que este trabalho icide é a egeharia de software mais especificamete a Quality Assurace em que se icluem os testes de software e as ferrametas de gestão de testes. Estrutura do relatório No poto 2 cotém a apresetação do cotexto do trabalho omeadamete o equadrameto das Ferrametas de Gestão de Testes. No poto 3 será documetada a aálise feita às ferrametas Bugzilla Test Ruer e Mercury Iteractive Test Director tedo em vista a especificação do módulo de testes da aplicação de Gestão de Projectos do CICA/FEUP (GP). Esta ferrameta que foi especificada e desevolvida o âmbito deste trabalho é descrita o poto 5. No poto 6 são registadas algumas cosiderações fiais e as hipóteses de trabalho futuro. FEUP MEI TQS 2/24

3 Ferrametas de Gestão de Testes 2. Cotexto Quality Assurace A Quality Assurace é uma disciplia ligada à egeharia de software que defie um cojuto de actividades que pretedem garatir que: um dado produto satisfaz os requisitos do sistema e as ecessidades dos clietes; os stadards, processos e procedimetos são apropriados para um dado projecto e que são aí correctamete implemetados; um dado projecto gera os produtos iteros e exteros requeridos; etc. Resumido, podemos cosiderar que a Quality Assurace existem geericamete duas verificações a fazer: que os produtos implemetam os requisitos base e que os processos descritos o plao de desevolvimeto são seguidos. Neste trabalho iteressa-os a primeira das duas categorias do Quality Assurace: verificação de que os produtos implemetam os requisitos base. Os testes cotra requisitos são umas das técicas mais básicas de Quality Assurace para fazer esta verificação. Apesar disto, algus casos, falaremos de processos, isto porque as ferrametas de gestão de testes podem ter um papel prepoderate a implemetação destes processos. A Quality Assurace é distita da Gestão de Cofigurações que se preocupa essecialmete com o cotrolo e registo de alterações dos ites de cofiguração, isto é, código, documetação, requisitos, problemas, desig, etc. Gestão de Testes A gestão de testes trata do cotrolo de todo o processo de testes. Esta tarefa pode ser complicada pois testar software evolve processos, equipas de teste, versões de software, releases, aplicações, grupos de scripts, etc. Tipos de Abordagem aos Testes Existem três tipos de abordages aos testes: maual, automática via script e capture/playback. Na abordagem maual, a defiição, etrada de dados e execução dos testes é feita maualmete, ormalmete através de um cliete (GUI). A defiição dos testes de forma a garatir que todas as combiações são testadas requer cohecimetos profudos do software e um gasto de tempo elevado. Na abordagem automática via scripts são desevolvidos scripts usado liguages de programação stadard. Os scripts podem ser usados sistematicamete para variar os dados de etrada para cobertura dos diferetes modos do programa. A abordagem capture/playback depede da iteracção maual de pessoas para defiir os casos de teste. As ferrametas captam e gravam a sequêcia de acções executadas e reproduzem-as posteriormete. Tipos de Ferrametas de Testes Quato às ferrametas de testes podemos dizer que existem múltiplos tipos de ferrametas etre os quais: as ferrametas de gestão de testes, as ferrametas de capture/playback, as ferrametas de testes de carga, etc. As ferrametas do tipo Capture/Playback capturam e reproduzem/repetem os processos gravados. São usados pricipalmete para testes de programas com iterfaces iteractivas. As ferrametas de testes de carga geram carga e tráfego o sistema. As ferrametas de gestão de testes são as mais básicas e ormalmete as mais usadas. Normalmete, uma equipa, os outros tipos de ferrametas vêm por acréscimo e para colmatar ecessidades mais específicas. Em geral, com a FEUP MEI TQS 3/24

4 Ferrametas de Gestão de Testes utilização de outros tipos de ferrametas de testes aumeta o custo, o tempo dispedido e a qualidade do software. Ferrametas de Gestão de Testes Estas ferrametas ajudam a gerir durate todas as fases de um projecto de desevolvimeto de software todo o processo de teste de software e todas as fotes de iformação relacioada com o esforço de teste. Nas ferrametas de gestão de testes são ormalmete icluídas fucioalidades de cotrolo de versões (gestão de cofigurações), gestão de defeitos (bugs), gestão de scripts de testes, artefactos de plaeameto de testes, execuções de testes e resultados dos testes. Os testes a efectuar estas ferrametas são iicialmete testes mauais, isto é, é feita a gestão de guiões de teste e arquivo dos resultados, etc. Algumas ferrametas mais evoluídas permitem itegrar estes testes mauais com scripts de testes automáticos. As fases típicas de um processo de teste são: plaeameto, deseho, implemetação, execução, aálise e gestão. Fucioalidade típicas As fucioalidades mais típicas das ferrametas de gestão de testes são: Defiição de requisitos de testes (test requiremets); Desevolvimeto de plaos de testes; Plaeameto de execuções de testes; Registo de execuções e de resultados obtidos (difereças etre resultados obtidos e esperados); Registo dos defeitos ecotrados durate a execução dos testes; Prioritização das execuções dos testes; Associação de documetos/templates aos testes; Evio de avisos para resposáveis, testers, etc; Aálise da execução de plaos de testes Test the Test por exemplo, que testes uca deram origem a bugs? Ferrametas de Gestão de Testes Automáticos As ferrametas que suportam testes automáticos podem fucioar como Test Drivers. Um Test Driver lê um ou mais casos de teste de um ficheiro de testes, formata os dados dos casos de testes de acordo com as ecessidades do software a ser testado, ivoca o software a ser testado com os iputs cofigurados o ficheiro de testes e regista o output da execução um ficheiro de log. Plao de Testes Um plao de testes é um documeto que descreve os objectivos, o âmbito, a abordagem, e o efoque de um esforço de teste de uma aplicação Permite que pessoas detro e fora do projecto compreedam o porquê e o como da validação do produto. Algus ites que um plao de testes deve coter: Título, idetificação do produto a testar (icluido úmero da versão) e descrição geral do produto; Orgaização geral do projecto e documetação relevate (requisitos, arquitectura, outros plaos de testes, etc.); Objectivo do esforço de teste, orgaização dos testes, prioridades, âmbito e limitações do plao de testes; Esboço dos testes (abordagem aos testes por tipos de testes, fucioalidade, sistema, modulo, etc.); Descrição e cofiguração do ambiete de testes (hardware, sistema operativo, outro software ecessário, cofiguração de dados, etc.); FEUP MEI TQS 4/24

5 Ferrametas de Gestão de Testes Aálise da validade do ambiete de testes, isto é, idetificação das difereças etre o ambiete de testes e o ambiete de produção e o seu impacto a validade dos testes; Esboço dos processos de teste e ferrametas a usar para testes e registo de bugs; Automação dos Testes: justificação, descrição geral e descrição dos processos de mauteção e gestão de versões dos scripts de teste e do código de teste; Afectação de pessoal; Etc. Casos de Teste Um caso de teste é costituído por uma etrada de dados o sistema, uma acção (ou eveto) e uma resposta esperada do sistema. Serve para determiar se uma dada fucioalidade de uma aplicação está a fucioar correctamete. Um caso de teste deve coter atributos como idetificador, ome, objectivo, pré-codições, requisitos os dados de etrada, passos (ou iterações) e resultados esperados. A estruturação de um plao de testes em casos de teste oferece cosistêcia e escalabilidade ao processo de teste. Costrução de Casos de Teste Apesar de discutível, podemos afirmar que um bom caso de teste é um caso de teste que ecotre problemas, isto para salietar a importâcia de desevolver casos de teste que teham o objectivo de ecotrarem efectivamete problemas o software e ão apeas passarem e criarem a ilusão de qualidade do produto. É útil desehar os casos de teste o mais cedo possível o processo de desevolvimeto pois o processo de defiição de casos de teste pode ajudar a ecotrar problemas os requisitos ou a arquitectura de uma aplicação. Exemplos de Ferrametas de Gestão de Testes Existem iúmeras ferrametas de gestão de testes o mercado. Das mais poderosas e com mais sucesso comercial destacamos as seguites: Mercury Iteractive TestDirector (itegrado a suite Quality Ceter); Compuware QA Director; IBM Ratioal TestMaager. Das também umerosas mas meos poderosas ferrametas ope source de gestão de testes dispoíveis destacamos as seguites: Bugzilla Test Ruer; Software Testig Automatio Framework (STAF); Outras: jwebuit, Bugkilla (testes fucioais), JMeter (testes de performace), Bugzilla, Matis e phpbugtracker (sistemas de gestão de bugs). FEUP MEI TQS 5/24

6 Ferrametas de Gestão de Testes 3. Ferrametas de Gestão de Testes - Aálise Das várias ferrametas listadas o poto aterior optamos por escolher duas delas para aálise. Por um lado escolhemos o Test Director por ser uma ferrameta líder de mercado com grade quatidade de fucioalidades, por outro lado, escolhemos o Bugzilla Test Ruer pela sua simplicidade. Ambas as características deveriam ser imitadas pela ova ferrameta a desevolver. O objectivo do estudo é fazer um levatameto das fucioalidades das ferrametas de mercado para facilitar a especificação da ova ferrameta. Foi posta a hipótese de selecção para aquisição de uma ferrameta mas foi decidido ão o fazer pois já existia a aplicação de Gestão de Projectos local que poderia permitir a itegração de iformação dos testes, o que seria impossível com uma ferrameta comercial Bugzilla Test Ruer O Bugzilla Test Ruer é um sistema de gestão de casos de teste baseado a web que fucioa como um add-o do Bugzilla. Tal como as outras ferrametas de gestão de testes, o Bugzilla Test Ruer ajuda a orgaizar o processo de QA. Figura 1 - Págia iicial do Test Ruer Bugzilla O Bugzilla é um sistema de gestão e mauteção de bugs de um produto. Permite registar bugs e mudaças de código, a comuicação etre elemetos da equipa, a submissão e revisão de patches e a gestão da QA. É um dos primeiros produtos mozilla.org iiciado em 1998, é escrito em PERL e é, desde há já algus aos, a ferrameta ope source líder para gestão de bugs. É um produto sempre em iteso desevolvimeto que é testado pela Mozilla Foudatio. Bugzilla Test Ruer No Test Ruer a iformação está estruturada uma hierarquia composta por: Produtos, Plaos de Testes e respectivas execuções (TestPlas e TestPlaRus), Casos de Teste e respectivas execuções (TestCases e TestCaseRus) e Acções (Actios). Na págia iicial (Figura 1) podemos aceder a um dos produtos registados que poderá ter vários plaos de teste registados. FEUP MEI TQS 6/24

7 Ferrametas de Gestão de Testes Na Figura 2 podemos ver a págia de um plao de testes. Nesta págia podemos ver algus dos atributos de um plao de teste que o Test Ruer permite registar como: ome, produto, versão do produto, versão do plao, tipo de testes do plao, lista de casos de testes, documetos aexos, execuções, etc. A partir do plao de testes podemos aceder à lista de casos de teste e depois à págia de detalhes de um caso de teste (ver Figura 3). Nesta págia podemos ver os detalhes de um caso de teste como o editor, a versão, o úmero de execuções, o úmero de bugs detectados, um sumário, etc. Adicioalmete, um plao de teste pode ser executado e a execução podem ser registados detalhes como as datas de execução, o executate, um sumário e otas da execução, etc. Detro de uma execução de plao de teste podem ser executados os casos de teste do plao em execução. Na execução de um caso de teste podemos cosultar a defiição das acções e registar, etre outros dados, o sucesso ou falhaço da execução do caso de teste. Figura 2 - Págia de um TestPla FEUP MEI TQS 7/24

8 Ferrametas de Gestão de Testes Figura 3 - Págia de um Caso de Teste Fucioalidades Test Ruer Em resumo, as fucioalidades gerais do Test Ruer são: Defiição de plaos de teste: um plao de testes deve coter a visão para as actividades de QA que guiam os testers; Defiição de Casos de Teste: istruções de como testar uma determiada fucioalidade o sistema e os resultados esperados; Agrupameto dos casos de teste em grupos fucioais; Gestão de execuções de testes: que casos de teste foram executados em determiada versão do produto, quem e quado executou e qual foi o resultado; Ligação de execuções de casos de teste a bugs: idetificação de casos de teste que ecotram problemas; Outras: pesquisa de casos de teste, import/export testes para HTML. Coclusão Após a utilização e avaliação do Test Ruer podemos cocluir que o Test Ruer é uma ferrameta com as fucioalidades básicas de gestão de testes com uma orgaização da iformação bastate simples e lógica. Uma das vatages adicioais do Test Ruer é que tem uma óptima iterligação com o Bugzilla para a gestão de bugs gerados durate as execuções dos testes. O facto de o Test Ruer ser ope source tem as vatages de ter o custo zero e poder ser evoluído pelos possíveis utilizadores coforme ecessário e as FEUP MEI TQS 8/24

9 Ferrametas de Gestão de Testes desvatages de o desevolvimeto ser leto ou mesmo vir a parar e, por outro lado, o suporte ão ser garatido. O grade defeito idetificado o Test Ruer foi a sua péssima iterface com o utilizador (apesar da estrutura lógica dos dados ser simples) que provocam grades dificuldades de utilização/avegação. Fialmete, as capacidades de aálise dos testes executados são reduzidas Mercury Iteractive Test Director O Test Director é uma ferrameta de gestão de testes itegrada a suite de aplicações para testes de software da Mercure Iteractive chamada Quality Ceter. O Test Director é a ferrameta líder de mercado das ferrametas de gestão de testes e permite gerir e automatizar todo o processo de Quality Assurace. Fucioa como um repositório cetral de testes baseado a web. Uma das características fudametais do Test Director é o grade destaque que dá ao processo de teste: metodologia, estrutura, orgaização e documetação. Mercure Iteractive Quality Ceter Esta suite é composta pelas aplicações Test Director, Quick Test Professioal e WiRuer. As ferrametas Quick Test Professioal e WiRuer são ferrametas de execução de testes fucioais. O WiRuer é uma ferrameta do tipo Capture ad Playback. O Quick Test Professioal permite costruir testes automáticos tato a ível fucioal (capture/playback) como de regressão. Processo de Gestão de Testes Na Figura 4 podemos ver a orgaização que o Test Director usa do processo de teste e que se reflecte a orgaização da aplicação. Figura 4 - Processo de Gestão de Testes As quatro fases base do processo de gestão de testes são: Idetificar e defiir os Requisitos de Teste Idetificação dos requisitos fucioais e de performace a testar Desevolver o Plao de Testes Defiir e plaear quais os testes a serem executados e como o serão Execução dos Testes Orgaizar os grupos de testes, plaear a sua execução, executar os testes e aalisar os resultados das execuções Registar os defeitos ecotrados e moitorar a sua correcção Estas quatro fases do processo são os quatro módulos do Test Director: Gestão de Requisitos (Requiremets Maagemet), Plaos de Teste (Test Pla Developmet), Laboratório de Testes (Test Lab/Test Executio) e Gestão de Defeitos (Track Defects). FEUP MEI TQS 9/24

10 Ferrametas de Gestão de Testes Adicioalmete, cada um destes módulos tem uma secção de Relatórios e Aálise (Reports ad Aalysis) que pode ser cosiderado um quito módulo trasversal. Na Figura 5 podemos ver a secção à esquerda ode se faz o acesso a cada um dos quatro módulos da aplicação, o caso, Gestão de Requisitos. 1. Gestão de Requisitos As pricipais fucioalidades do módulo de gestão de requisitos são: Defiição de requisitos e respectivas propriedades; Defiir árvores de Requisitos; Agrupameto de requisitos por grupos fucioais e tipos; Estado dos Requisitos; Alteração dos requisitos (com histórico de alterações); Aexação de documetos aos requisitos; Evio de dados do requisito por ; Três vistas de gestão de requisitos: documet view lista de requisitos e propriedades; coverage view - testes de cada requisito; coverage/aalysis view execuções de testes de cada requisito. A figura 5 mostra o módulo de requisitos do Test Director. Figura 5 Test Director - Módulo de Gestão de Requisitos No meu esquerdo podemos ver a lista dos quatro módulos referidos ateriormete. Na parte cetral do ecrã é mostrada uma lista de requisitos. Cada requisito tem atributos como idetificador, ome, autor, estado, prioridade, data de criação, etc. 2. Desevolvimeto do Plao de Testes Neste módulo do Test Director podemos defiir plaos de teste e respectivas propriedades. De realçar que, esta secção, temos já dispoível os requisitos aprovados a partir dos quais podemos começar a trabalhar os plaos de testes. Os passos para a defiição do plao de testes são: FEUP MEI TQS 10/24

11 Ferrametas de Gestão de Testes Defiição da árvore de casos de teste (relações hierárquicas e de depedêcia etre testes); Ligação dos casos de teste aos requisitos (ou o cotrário); Defiição dos passos de cada caso de teste; Costrução dos scripts de teste (para os testes automáticos). No Test Director um plao de testes tem uma descrição geral (é a estratégia de teste para o módulo) e é possível aexar documetos. Um caso de teste tem atributos como tipo, ome, descrição, criador, data de criação, estado, etc. Os campos obrigatórios de um caso de teste são cofiguráveis (admiistrativamete). É possível aexar documetos aos casos de teste. Os passos/iterações têm atributos como ome, descrição, valores das etradas de dados, acção, resultado esperado, etc. Outras fucioalidades deste módulo são: Um dos passos de um teste pode ser outro teste completo; Templates de testes reutilização de testes; Permite iserir parâmetros que são cofiguráveis em cada uma destas chamadas; Trasformar/associar um teste maual um teste automático; Edição de scripts de teste directamete a ferrameta; Defiição visual do fluxo de execução de um grupo de testes (precedêcias e depedêcias). 3. Execução de Testes O módulo Test Lab é o módulo do Test Director que permite gerir a execução dos testes defiidos o módulo aterior. Nesta fase de execução de testes o Test Director permite defiir Test Sets que são cojutos de testes a executar. Estes Test Sets são cojutos executáveis de testes de diferetes plaos, costruídos para uma execução específica. Num Test Set podemos icluir vários plaos de teste ou apeas algus casos de teste de vários plaos. Os atributos deste Test Sets são a versão do produto e do browser, otificação por o caso de falha, aexação de documetos, watchers, etc. O módulo Test Lab permite a execução de testes automáticos directamete a aplicação bem como o plaeameto de execuções automáticas de testes. Neste plaeameto é possível cofigurar a reexecução em caso de falha e a defiição de regras de limpeza após execução de um teste. Outra fucioalidade iteressate do Test Lab é a defiição de depedêcias e precedêcias de passagem, isto é, a defiição se um dado teste falhar, pode cotiuar a execução ou ão. Como todas as ferrametas de gestão de testes, este módulo permite fazer o registo e aálise das execuções e dos resultados dos testes executados. É possível visualizar e pesquisar todas as execuções e resultados dos Test Sets, de cada caso de teste e de cada passo detro de cada teste. A fucioalidade que mais se destaca este módulo é a possibilidade de fazer a gestão visual do fluxo de execução de testes. A Figura 6 mostra um exemplo desta fucioalidade: à esquerda são mostrados os Test Sets com os casos de teste respectivos e o cetro podemos defiir o fluxo de execução através da defiição de uma árvore de execução. FEUP MEI TQS 11/24

12 Ferrametas de Gestão de Testes Figura 6 Test Director - Módulo Test Lab - Fluxo de Execução de Testes 4. Gestão de Defeitos O módulo Defects do Test Director fucioa como uma ferrameta de gestão de defeitos icorporada o Test Director e, portato, com a vatagem da itegração com as outras fases do processo de testes. Neste módulo podemos fazer registo e bugs ecotrados durate a execução de testes (possibilidade de associação de bugs a testes). As propriedades de um bug podem ser cofiguráveis por um admiistrador e podem ser reprodutibilidade (S/N), estado (ew, ope/reope, fixed, closed/rejected), etc. Para além da aexação de documetos a um bug é possível cotrolar todo o ciclo de vida de um bug através das fucioalidades de pesquisa e revisão de bugs oferecidas por este módulo. 5. Relatórios e Aálise O módulo de Reports & Aalysis do Test Director é, como já foi dito, um módulo trasversal e que está dispoível através de uma secção de cada um dos outros quatro módulos da aplicação. Nestas secçãões podemos fazer a filtragem e orgaização dos dados do respectivo módulo para geração de relatórios e gráficos, gerar relatórios e gráficos e gerar documetação de projecto formatada. Na geração de relatórios é possível cofigurar e filtrar os dados para cada relatório específico de uma forma muito versátil. Podem ser defiidos templates cofiguráveis, por exemplo, lista de requisitos, lista de testes, traceability matrix, etc. Na geração de gráficos é também possível gerar templates e criar gráficos com relações etre dados (cofiguráveis), por exemplo, requisitos por autor, defiições de testes por autor, execuções de testes por autor, testes por urgêcia, etc. Adicioalmete, este módulo é possível exportar dados para HTML, MsWord, MsExcell (com gráficos e relatórios icluídos), por exemplo, relatório com a execução de um plao de testes. E é possível importar dados do MsWord e do FEUP MEI TQS 12/24

13 Ferrametas de Gestão de Testes MsExcell através de add-is forecidos pela Mercure (fucioam como macros estas aplicações). Test Director Applicatio Delivery Dashboard Esta aplicação ão faz parte do Mercure Iteractive Quality Ceter mas fucioa como itegrador de iformação vida das várias aplicações do Quality Ceter mas também de outras fotes como outros sistemas de gestão de requisitos e bugs ou o MsProject. Neste dashboard é possível cofigurar Key Performace Idicators (KPIs) e outras vistas de aálise do processo de desevolvimeto. É possível cofigurar as vistas sobre os KPIs depededo de quem está iteressado em quê detro de uma orgaização. O dashboard vem com um cojuto de KPIs para a qualidade, performace e processo já cofigurados. Algus destes KPIs ligados aos bugs são bugs criados por dia, bugs fechados por dia, taxa de correcção de bugs, lista de defeitos por prioridade ou importâcia ou estado, taxa de ijecção de bugs, paiel de cotrolo com luzes de semáforo para bugs de alta prioridade ou importâcia, bugs reabertos, total de bugs por dia, etc. Algus destes KPIs ligados aos requisitos são a lista de requisitos por estado, úmero total de requisitos e paiel de cotrolo com semáforos para os requisitos por estado. Para os testes, os KPIs por defeito desta aplicação são as últimas execuções dos testes, execuções de testes por estado, paiel de cotrolo para os testes falhados, total de execuções de um dia, total de ovos testes defiidos por dia, etc. Coclusão Relativamete ao Bugzilla Test Ruer, as vatages do Test Director são iúmeras, das quais destacamos os factos de ser líder de mercado e de dar grade destaque ao processo de teste. Outras das vatages desta aplicação são: Quatidade e qualidade das fucioalidades; Cofigurabilidade; Extraordiárias fucioalidades de relatórios e aálise; Excelete itegração etre módulos através do fluxo de iformação de um passo do processo de testes para o seguite. A úica, mas obviamete sigificativa, desvatagem detectada o Test Director foi o preço. Podemos dizer que os preços do Test Director são cosiderados exorbitates. Os preços idicados do Test Director (icluido o WiRuer e um ao de suporte obrigatório) tem aproximadamete o mesmo preço que o produto Ratioal TestMaager (icluido o produto Ratioal Robot, uma versão limitada do produto Clear Quest e um ao de suporte obrigatório) que é $8200 por utilizador (até 10 utilizadores). Cosiderado que o suporte vale 20% do valor do produto, um segudo ao o preço seria aproximadamete de $6500 (fote: mesagem em comp.software.testig - ao 2000!!!). FEUP MEI TQS 13/24

14 Ferrametas de Gestão de Testes 4. Especificação e Desevolvimeto Neste poto apresetamos a parte prática deste trabalho. No âmbito deste trabalho foi especificado, desevolvido e testado o módulo de testes da aplicação de Gestão de Projectos utilizada o CICA/FEUP Cotexto Aplicação de Gestão de Projectos do CICA/FEUP (GP) A aplicação de Gestão de Projectos utilizada e desevolvida o CICA/FEUP (deomiada de agora em diate por GP) foi iicialmete cocebida como uma ferrameta de gestão de bugs e de cotrolo de versões. O módulo de gestão de bugs é bastate completo e icorpora também fucioalidades de gestão de tarefas (registo de actividades, afectação de recursos, timecards, etc.). As capacidades de cotrolo de versões são reduzidas e está previsto para breve o desevolvimeto de um módulo de gestão de cofigurações que permita fazer uma gestão mais avaçada e eficiete das versões e cofigurações dos produtos geridos pela aplicação. Âmbito do Trabalho Para este trabalho de TQS foi desevolvido o módulo de testes da GP. A especificação deste módulo foi feita a pesar o cotexto deste trabalho académico mas pricipalmete, como era também objectivo do próprio trabalho académico, o ambiete e ecessidades reais dos utilizadores da GP o CICA/FEUP. De facto o módulo de testes tem de ser pesado em cojuto com o módulo de requisitos da GP que foi desevolvido um pouco ates do módulo de testes. Apesar de fora do âmbito iicial do trabalho da disciplia, a revisão da especificação do módulo de requisitos foi uma parte cosiderável e importate deste trabalho. Isto acoteceu pois, por exemplo, a aálise do Test Director permitiu gahar mais sesibilidade em relação às fucioalidades relacioadas com requisitos. Módulo de Requisitos da GP O módulo de requisitos da GP, tal como o módulo de requisitos do Test Director, fucioa como uma ferrameta de gestão de requisitos que permite a iterligação dos seus dados com a gestão de tarefas, bugs, versões, testes, etc. Neste módulo podemos registar, cosultar e pesquisar os requisitos de um determiado produto ou módulo. Cada requisito pode estar associado a tarefas de implemetação ou bugs e pode ter os seguites campos associados: ome, requisito pai, descrição, observações, módulo, prioridade, estado, stakeholder, actores, iício previsto de desevolvimto, tempo de implemetação previsto, etc. FEUP MEI TQS 14/24

15 Ferrametas de Gestão de Testes Figura 7 - Págia de detalhes de um Requisitos Na Figura 7 podemos ver a págia de detalhes de um requisito. Nesta págia, por exemplo, temos um requisito que especifica a fucioalidade de cloagem de um caso de teste, isto é, o módulo de testes, o utilizador poderá criar um caso de teste copiado os dados de um caso de teste já defiido e alterado-os coforme desejado. Nesta págia é possível criar ovos requisitos, editar o requisito, etc Módulo de Testes da GP Visão Geral O módulo de testes da GP fucioa como uma ferrameta de gestão de testes, isto é, icorpora fucioalidades equivaletes ao Test Ruer e aos módulos Test Pla e Test Lab do Test Director. Geericamete, este módulo podemos registar plaos de testes e respectivos casos de teste, registar execuções desses casos de teste e pesquisar/moitorar as defiições e execuções dos testes. Apesar de o módulo ter sido pesado para mais tarde vir a ser itegrado com testes automáticos, essecialmete scripts PL/SQL, de mometo, essa fucioalidade ão está especificada. Processo de Especificação Após a aálise das ferrametas de gestão de testes descrita o poto 3, foi feito o levatameto das ecessidades juto dos stakeholders do ovo módulo (foram feitas reuiões com as várias equipas de testers) e gestores de projecto. Da aálise das ferrametas e deste levatameto resultou um cojuto de iformação suficiete para a elaboração da especificação de requisitos (processo gradual). Este trabalho de levatameto de ecessidades e especificação foi feito em estreita colaboração com outros elemetos da equipa do CICA que detiham cohecimetos fudados esta área. Neste trabalho, o módulo de requisitos da GP foi utilizado para gerir os requisitos do módulo de testes da GP. FEUP MEI TQS 15/24

16 Ferrametas de Gestão de Testes Neste cotexto, iteressa descrever sucitamete o processo de especificação do módulo de teste e como foi utilizado o módulo de requisitos da GP para tal. 1. O documeto de requisitos foi escrito o iício do projecto com o objectivo de documetar a primeira fase da especificação, isto é, stakeholders, actores, casos de uso, etc. 2. Após essa especificação iicial, a qual já se icluíam algus requisitos com detalhes, o documeto foi fechado e os requisitos foram iseridos a GP através do módulo de requisitos (o próprio documeto fica também a GP). 3. Desde etão os requisitos do módulo de testes puderam ser evoluídos, corrigidos e maipulados a GP muito facilmete. 4. Ifelizmete o ciclo ão pode ser fechado pois a fucioalidade de exportação da lista de requisitos para um documeto aida ão está implemetada, isto é, a lista de requisitos do documeto de especificação aexo está ligeiramete desactualizado. A versão actualizada dos requisitos pode ser cosultada a GP. Casos de Uso Na figura 8 podemos ver o diagrama de casos de uso global do módulo de testes da GP. Os pacotes de casos de uso foram divididos desta forma para mais fácil percepção da orgaização das fucioalidades. Figura 8 - Pacote global de requisitos do módulo de Testes da GP Os detalhes destes pacotes de casos de uso, a defiição dos actores e toda a especificação do módulo podem ser cosultados o documeto aexo: Especificação de Requisitos do Módulo de Testes da GP. Neste documeto aexo está documetado todo o processo de especificação de requisitos do módulo, desde FEUP MEI TQS 16/24

17 Ferrametas de Gestão de Testes a aálise de stakeholders, idetificação de actores e pacotes de caso de uso até à listagem de requisitos idividuais que defiem as fucioalidades da aplicação em detalhe. Fucioalidades implemetadas Neste poto faremos uma apresetação geral do módulo que está actualmete em fucioameto a GP do CICA/FEUP. De um poto de vista geral o módulo de testes da GP icorpora o fucioameto básico do Test Ruer mas tem uma iterface gráfica melhorada, para além de ter mais iterligações com os dados da GP e mais fucioalidades tiradas do Test Director. Como podemos ver a Figura 9 do lado direito do ecrã são apresetados os módulos da GP. O módulo de testes é facilmete acessível através da opção testes. A págia iicial do módulo é, como podemos ver a Figura 9 o formulário geral de pesquisa de testes. Figura 9 Formulário de Pesquisa de Testes Neste formulário podemos pesquisar defiições de plaos de testes e casos de testes com filtros como o módulo do produto, o autor das defiições, etc. Após efectuarmos a pesquisa podemos seleccioar um plao de testes específico e cosultar a págia de detalhes de um plao de testes, como se pode ver a Figura 10. FEUP MEI TQS 17/24

18 Ferrametas de Gestão de Testes Figura 10 - Págia de um Plao de Testes Nesta págia podemos ver detalhes do plao de testes: o ome, objectivo geral, o produto e o módulo a que dizem respeito, os iterveietes e a lista com liks dos casos de teste associados. Fialmete, o fial da págia é possível efectuar algumas pesquisas sobre as execuções feitas ou a decorrer deste plao de testes, podedo aqui ver os utilizadores, o úmero e a hora a que os casos de teste foram executados, a cobertura dos casos de testes, etc. FEUP MEI TQS 18/24

19 Ferrametas de Gestão de Testes Se clicarmos o ome de um caso de teste podemos ver a págia de detalhes de um caso de teste como mostra a figura 11. Figura 11 - Págia de um Caso de Teste Nesta figura podemos ver que o caso de teste é idetificado por uma descrição, um tipo de teste, uma ível, etc. Num caso de teste são listados todos os passos do caso de teste e o resultado esperado de cada passo. As execuções dos casos de teste são ecapsuladas as execuções dos plaos de teste respectivos. Na págia de execução de um plao de teste (que omitimos por razões de brevidade) podemos registar umas observações gerais de execução e podemos ver a lista de casos de teste e respectivas execuções podedo cotiuar uma execução iterrompida ou começar uma ova execução. Neste passo somos levados para a págia de execução de um caso de teste apresetada a Figura 12. FEUP MEI TQS 19/24

20 Ferrametas de Gestão de Testes Figura 12 - Págia de Execução de um Caso de Teste Na Figura 12 podemos ver a págia de execução do caso de teste. Para além de vermos os detalhes do caso de teste, esta págia podemos registar uma série de iformações sobre o ambiete de execução do caso de teste como, versão do módulo, URL, browser, etc. De seguida podemos registar os resultados da execução do caso de teste. Para cada passo podemos registar se o resultado obtido foi idêtico ao esperado e algumas observações que sejam ecessárias. No fial podemos registar observações gerais da execução e dar o caso de teste como passado ou falhado. Se o teste passar o utilizador é levado para a págia de execução do plao de teste, se o teste falhar é apresetada uma págia ode se pode associar um problema (bug) da GP (existete ou ovo) ao teste falhado. FEUP MEI TQS 20/24

21 Ferrametas de Gestão de Testes Outras fucioalidades básicas como iserção/edição dos plaos/casos de teste e todos os detalhes associados ão foram referidos este poto por motivos de brevidade. Fucioalidades por implemetar A especificação do úcleo do módulo foi feita com bastate detalhe o que permite que, o futuro, a cotiuação da implemetação possa ser facilmete trasmitida a outro programador. Foi defiido a especificação deste módulo de testes que haveria uma seguda iteração de especificação (após implemetação do úcleo) ode se faria a revisão da implemetação e possíveis correcções (já feita) e a especificação das fucioalidades de gestão, mais especificamete, a parte de gestão e moitorização do processo de teste (parcialmete elaborada). Supodo que a parte de gestão e moitorização do módulo represeta cerca de 10% do módulo podemos afirmar que 75% do módulo de testes já se ecotra implemetado. Isto é, como exercício foi especificada uma aplicação com fucioalidades bastate avaçadas que posteriormete foram prioritizadas e, como cosequêcia óbvia, as fucioalidades meos fudametais foram deixadas para o fim. Assim sedo, as pricipais fucioalidades por implemetar do módulo de testes são: Possibilidade de associar um requisito (do módulo de requisitos da GP) a um caso de teste e a listar os requisitos já associados ao caso de teste; Matriz de cobertura dos requisitos pelos testes ode podemos ver, para um determiado produto ou módulo, a listagem de testes que ão cobrem requisitos e a listagem de requisitos que ão são cobertos por testes. Criação de um caso de teste a partir de outro já existete (cloagem); Utilização de passos por defeito a defiição de casos de teste, por exemplo, possibilidade de importar para um caso de teste os passos para fazer auteticação o sistema; Associação de documetos aos plaos e casos de teste; Exportação de plaos de teste para documetos (HTML, PDF e MsWord); Em cada caso de teste uma ligação directa ao GESSI (framework aplicacioal) que seria o primeiro passo para a automação do processo de testes. De otar que estas fucioalidades têm complexidades e tempos de implemetação diferetes. Por exemplo, a associação de documetos a testes e a exportação dos testes para documetos são fucioalidades relativamete simples de implemetar equato a matriz de cobertura dos requisitos pelos testes é algo mais complexo. Testes Os testes efectuados ao módulo de testes foram de atureza iformal, isto é, o módulo foi testado durate a utilização em dois projectos: o projecto Cadidaturas a Bolsas de Estudo dos SASUP e o projecto Geração automática de CVs. À medida que o módulo foi sedo usado pelos testers desses dois projectos, os defeitos do módulo de testes foram sedo reportados e corrigidos (utilizado o módulo de gestão de bugs da GP). Optamos por ão desevolver plaos e casos de teste para o módulo de testes da GP pricipalmete porque cosideramos que o esforço ecessário para tal, seria, só por si, matéria e esforço suficiete para um outro trabalho de TQS. Sedo assim, os testes ao módulo de testes da GP foram relegados para trabalho futuro (ver poto 5). FEUP MEI TQS 21/24

22 Ferrametas de Gestão de Testes Coclusão Podemos cocluir que o ovo módulo de testes da GP já está a ter algum impacto positivo a equipa de desevolvimeto que utiliza a GP. É importate referir que ates da existêcia deste módulo de testes da GP, eram usadas folhas MsExcell com algus campos orietados à execução e ão à defiição. Não era feito ehum plaeameto em sequer repetição de testes defiidos. Apeas eram registados os resultados dos testes que se iam executado e, só os bugs eram registados a GP. Nos projectos actuais já se ota um esforço iicial um pouco maior por parte das equipas de especificação/desevolvimeto para que os testers teham bastates facilidades a execução dos testes já defiidos. Este projecto icluiu uma parte cosiderável de revisão do processo de desevolvimeto da equipa que trabalha a GP. É iteressate costatar como uma ferrameta deste tipo pode ajudar e facilitar a estabelecer um processo simples de desevolvimeto de software. Por exemplo, a defiição do processo de especificação de requisitos em que se faz a passagem dos requisitos do documeto para a GP foi defiido com base este projecto do módulo de testes da GP. Como coclusão referimos que o módulo de testes da GP está já a ser utilizado em vários projectos e que, apesar de só ter as fucioalidades básicas implemetadas, as vatages da sua utilização já são óbvias. FEUP MEI TQS 22/24

23 Ferrametas de Gestão de Testes 5. Coclusões Cosiderações Fiais Quato à aálise de ferrametas de gestão de testes do mercado podemos cocluir que foi extremamete vatajosa e facilitadora do trabalho de especificação do módulo de testes da GP. Cocluímos também que o desevolvimeto itero deste módulo é compesador face à possibilidade de selecção para aquisição de uma ferrameta de mercado; pricipalmete devido às possibilidades de itegração com os outros módulos da GP. O facto de este projecto ter um âmbito profissioal para além do académico torou possível um grade esforço de especificação e implemetação que seria totalmete impossível se assim ão fosse. Dado que o trabalho ão tiha objectivos bem defiidos o iício, seão o de especificar e implemetar uma ferrameta de gestão de testes, o fial do trabalho teve de ser defiido com bom seso, isto é, imeso trabalho poderia aida ser feito (ver próxima secção) mas foi cosiderado que o esforço dispedido já ultrapassou em larga medida o esforço ormal para uma disciplia de mestrado. Trabalho Futuro Um dos trabalhos futuros que será certamete realizado é a implemetação dos requisitos que ficaram por implemetar e, como já foi referido, a especificação e execução de plaos de testes para o próprio módulo de testes. Outra tarefa futura que terá de ser executada é a especificação em detalhe da parte de gestão e moitorização dos testes, para tal, foi já superficialmete aalisada a ferrameta Applicatio Delivery Dashboard que itegra uma série de KPIs que poderá ser iteressate itegrar a GP. De um poto de vista mais académico, podemos acrescetar que o estudo feito às ferrametas de gestão de testes podia ser mais aprofudado; tato ao ível da aálise feita a cada uma das aplicações como a outras aplicações referidas mas ão aalisadas (ver o poto 2 a secção Exemplos de Ferrametas de Gestão de Testes). Ao ível da GP existe aida imeso trabalho a fazer ão só do poto de vista da especificação e implemetação mas também do poto de vista da sua real utilização pelos programadores e gestores da equipa de desevolvimeto. Este trabalho terá de ser itegrado o melhorameto do processo de desevolvimeto (Quality Assurace). Aexos Como aexos são apresetados os seguites elemetos: Documeto de especificação de requisitos do módulo de Testes da GP; Lista de requisitos do módulo de testes da GP (demo do trabalho); Código fote desevolvido (PL/SQL); Ficheiro MsPowerPoit que serviu de suporte à apresetação do trabalho. FEUP MEI TQS 23/24

24 Ferrametas de Gestão de Testes 6. Referêcias [1] Mercury Iteractive website [2] TestDirector Tutorial [3] Test Ruer Site [4] Test Ruer olie demo [5] Ferrametas de testes ope source [6] Software QA/Test Resource Ceter [7] NASA Software Assurace / FEUP MEI TQS 24/24