Gestão de Testes (Test Management) João António Nico Neto da Costa Alves CGI Portugal joao.alves@cgi.com j_alves12@netcabo.pt O desenvolvimento de sistemas de informação é cada vez mais complexo. A necessidade de tornar este processo cada vez mais eficiente, com vista à redução de custos e a um melhor time-to-market, traz uma nova perspectiva à necessidade de se ter um melhor e mais eficiente processo de testes, que deve ser cada vez mais entendido como uma fase crucial da gestão da qualidade do trabalho desenvolvido. Assim sendo, a importância de planear, executar e documentar testes das aplicações desenvolvidas é crucial para os departamentos de desenvolvimento e para a qualidade dos produtos criados. Surge então o conceito de gestão de testes, que consiste em quatro aspectos fundamentais: Gestão de Requisitos, Planeamento de Testes, Agendamento e Realização de Testes, e Gestão de Defeitos/Incidentes. Neste artigo é apresentado o trabalho realizado no âmbito do projecto de final de curso de IGE, que consistiu no desenvolvimento de uma metodologia de testes a adoptar pela CGI, de forma a esta alargar o seu leque de oferta no mercado. Palavras-chave: gestão de testes; testes de software; test cases; V-Model; Rational Unified Process (RUP) Software development has become more and more complex. The need to make this process more and more efficient, aiming cost reduction and a better time-to-market, brings a new perspective to the need of having a better and more efficient testing process, which must be perceived as a crucial stage in managing the quality of the work made. Thus, the importance of plan, execute and document software testing is crucial for development departments, as well as for the products’ quality. With this, rises the concept of test management, which consists of four fundamental aspects: Requirements Management, Test Planning, Test Scheduling and Execution, and Defects/Issues Management. This article intends to present the work made within the scope of the final project of the Computer Science and Business Administration degree at ISCTE (Portugal). This project consisted on developing a testing methodology for CGI, which the company would include in its services portfolio. Keywords: test management; software testing; test cases; V-Model; Rational Unified Process (RUP) O Projecto O projecto teve como principal objectivo a criação de uma metodologia de realização de testes, para posteriormente a CGI utilizar nos seus projectos quando não existir uma orientação concreta determinada pelo(s) cliente(s). Esta metodologia não pretende definir um procedimento rígido, mas sim fornecer aos seus destinatários uma orientação no sentido de melhorar o processo de testes na CGI. Inicialmente foi feito um levantamento do estado da arte que consistiu na compilação de várias metodologias de testes existentes dentro e fora da CGI a nível mundial, de forma a definir um procedimento de testes adaptado à nossa realidade. Após este levantamento seria feita uma consulta aos colaboradores da CGI de forma a obter as suas opiniões acerca deste novo procedimento bem como da sua aplicabilidade na vida real. Ao mesmo tempo foi feito um benchmarking das várias ferramentas de testes disponíveis no mercado, de forma a identificar a(s) que melhor poderão implementar o procedimento de testes. Numa segunda fase do projecto foi feita uma aplicação real da nova solução, sendo que para tal recorreu-se a um dos outros projectos que foram desenvolvidos na CGI, o Project Management Toolkit. Tal serviu para criar a Prova de Conceito, bem como para validar toda a solução desenvolvida ao longo do projecto. De uma forma mais esquematizada temos: Criação de uma metodologia Definição de um procedimento de testes para a CGI Portugal Compilação de metodologias Levantamento das ferramentas apropriadas Consulta aos colaboradores Aplicação e validação da solução Os Conceitos Antes de definir a metodologia, foi necessário ainda esclarecer alguns conceitos relacionados com testes, começando exactamente por definir o que são testes de software. O teste de software é uma das fases do processo de engenharia de software que visa atingir um elevado nível de qualidade da aplicação desenvolvida. O objectivo, por paradoxal que pareça, é mesmo o de encontrar defeitos no produto, para que estes possam ser corrigidos pela equipa de desenvolvimento, antes da entrega final. A maioria das pessoas pensa que o teste de software serve para demonstrar o correcto funcionamento de uma aplicação, quando na verdade ele é utilizado como um processo para encontrar defeitos. O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem actualmente várias definições para esse conceito. De uma forma simples, testar software significa verificar através de uma execução controlada se o seu comportamento ocorre de acordo com o especificado. O objectivo principal desta tarefa é encontrar o maior número de erros dispondo do mínimo de esforço, ou seja, mostrar à equipa de desenvolvimento se os resultados estão ou não de acordo com os padrões estabelecidos. Depois da definição deste conceito mais genérico, chegou-se ao conceito base de todo o trabalho desenvolvido: a gestão de testes. A gestão de testes é um método de organização de tudo o que se relaciona com testar uma aplicação (p.e. requisitos de teste, planos de teste, documentação, scripts, ou relatórios), de forma a permitir um fácil acesso e reutilização. O objectivo da gestão de testes é o de produzir aplicações de qualidade em menor tempo. A maioria das organizações não possui um processo standard de organização, gestão e documentação das suas actividades de teste. Muitas vezes, os testes são conduzidos como uma actividade ad-hoc, a qual se modifica a cada novo projecto. Sem uma fundamentação standard para planear e executar testes, bem como para gerir defeitos, o esforço de teste torna-se não-replicável, não-reutilizável, e difícil de medir. Um processo de gestão de testes correctamente desenhado permite a uma organização: Conduzir o processo de testes de uma forma melhor, mais rápida e mais barata, na medida em que realizar actividades de teste sem seguir standards leva à criação de testes, desenho e planos que não são replicáveis, e como tal impossíveis de serem reutilizados em futuras iterações da actividade de testes. Efectuar compilações diariamente, dado que uma abordagem bem definida e sistemática às actividades de teste, e um repositório centralizado para os testes, planos e relatórios de execução permitem um acréscimo de valor à realização frequente de compilações. Gerir alterações aos requisitos. Um esforço de teste completamente baseado nos requisitos é a melhor maneira de garantir que o produto final vai de encontro às necessidades do utilizador. Sem uma gestão de testes que faça a ligação entre os planos de teste e os requisitos funcionais da aplicação, bem como permita às organizações ligar as alterações aos requisitos com os test cases (e vice-versa), é praticamente impossível desenhar testes que verifiquem se o sistema contém a funcionalidade especificada. Implementar testes à escala global, na medida em que adoptando um processo de teste claramente definido e um método colaborativo intuitivo e fácil de usar, é possível criar uma equipa de testes “virtual” distribuída geograficamente. Organizar vários testes e vários projectos, mediante um processo sistemático que permita às equipas de teste a gestão de múltiplos projectos e a definição clara dos objectivos de cada um. Conduzir mais do que procurar bugs. Hoje em dia as actividades de teste focam-se em verificar que o desenho da aplicação e a sua funcionalidade vão de encontro aos requisitos de negócio, pelo que o processo de testes necessita uma definição clara das especificações do sistema e das restrições de negócio da aplicação. Testar cedo no ciclo de vida, o que permite uma redução dos custos. Para que os testes se iniciem ao mesmo tempo que o desenvolvimento, é necessário definir claramente um conjunto de objectivos e prioridades que permita um melhor entendimento do desenho de sistema, dos requisitos, e dos objectivos dos testes. Obter visibilidade organizacional através da qualidade, que por sua vez apenas se obtém com um processo de gestão bem estruturado e presente em toda a organização. Independentemente daquilo que a aplicação faz, de como foi escrito, ou da plataforma em que está a correr, os princípios básicos da gestão de testes são os mesmos. Inicia-se com a compilação e documentação dos requisitos de teste e prossegue através do desenho e do desenvolvimento de testes, da execução de testes, e da análise dos defeitos. O processo de testes não é linear, e naturalmente difere dependendo das práticas e metodologias de cada organização. No entanto, os princípios que estão por detrás de todos os processos de teste são os mesmos. A Metodologia A metodologia desenvolvida suporta a premissa de que os testes devem ser geridos como um projecto dentro do projecto. Deste modo, as tarefas de gestão de testes inerentes à metodologia abordam: Preparação da estratégia e do plano de testes, que são criados antes do início da construção. São dois documentos que andam lado a lado. Enquanto a estratégia define a abordagem a adoptar para que os objectivos dos testes sejam atingidos, o plano quantifica a estratégia em termos de tipo, quantidade e tempo dos recursos (humanos ou máquinas) necessários. Análise de risco, para que sejam identificadas as aplicações com maior risco, de modo a que seja planeado e executado um processo de testes mais extenso para estas aplicações, e para identificar quais as componentes críticas e/ou as áreas de foco mais importantes do sistema do ponto de vista do cliente. Procedimentos de escalamento de problemas, ou seja, a definição de linhas gerais acerca de como proceder ao longo de todo o esforço de teste, e acerca dos processos de reporting. Organização da equipa de testes, nomeadamente a definição dos papéis que cada membro tem dentro da equipa. Métricas de teste, que permitem ao gestor do projecto avaliar os níveis de qualidade, bem como saber o que é necessário para que se atinja um determinado nível de qualidade. As métricas permitem ainda ao gestor de projecto que este possa tomar decisões acerca de continuar ou não com as actividades de teste. Seguimento de defeitos e níveis de severidade, que devem ser descritos clara e precisamente. Um defeito pode existir num de três estados: aberto (descoberto, mas ainda não corrigido), resolvido (aberto e corrigido, mas ainda não re-testado), e fechado (aberto, corrigido e re-testado). Os níveis de severidade são três: severidade 1 (problema que tem de ser corrigido e para o qual não existe alternativa), severidade 2 (problema que tem de ser resolvido rapidamente e para o qual existe uma alternativa), severidade 3 (todos os outros problemas) Verificação de critérios de entrada/saída dos vários níveis e sub-níveis de teste. Critérios de entrada são utilizados para determinar quando é que um componente do sistema está pronto a ser testado. Critérios de saída são utilizados para determinar se a aplicação foi testada com sucesso num dado nível, e se o componente pode seguir para o nível de teste seguinte. Modelo Evolutivo vs. Modelo Não Evolutivo De forma a flexibilizar a metodologia, foram criadas duas abordagens aos procedimentos de testes, em que uma se refere a modelos de desenvolvimento não evolutivos, o e outro ajusta-se a modelos de desenvolvimento evolutivos. Como modelo não evolutivo, optou-se pelo V-Model. Este modelo mapeia os tipos de testes (unitários, integração, sistema e aceitação) a cada uma das fases do desenvolvimento (ver figura 1). Tal como a figura mostra, o ciclo de desenvolvimento está lado a lado com o ciclo de testes. Isto possibilita que as actividades de testes tenham o seu começo numa fase mais inicial de todo o processo de desenvolvimento da aplicação. Do lado do desenvolvimento, o fluxo de trabalho é tipicamente baseado no modelo Waterfall, no qual cada passo se segue ao anterior. Do lado dos testes, à medida que vamos dos Testes Unitários até aos Testes de Aceitação, o nível de detalhe é cada vez menor, tornando-se mais orientado a uma visão de negócio. Também na figura 1 temos, para cada uma das fases do processo, o(s) documento(s) a ser(em) elaborado(s) nessa mesma fase. Fases Actividades de Teste Requisitos Elaborar Plano de Testes de Aceitação (Especificar Test Cases de Aceitação) Especificação de Sistema Elaborar Estratégia de Testes Elaborar Plano de Testes de Sistema (Especificar Test Cases de Sistema) Desenho de Sistema Elaborar Plano Geral de Testes Elaborar Plano de Testes de Aceitação (Rever test cases e executar todas as outras tarefas) Elaborar Plano de Testes de Sistema (Rever test cases e executar todas as outras tarefas) Elaborar Plano de Testes de Integração Desenho Detalhado Elaborar Plano de Testes Unitários Programação N/A Testes Unitários Executar Testes Unitários Testes de Integração Executar Testes de Integração Testes de Sistema Executar Testes de Sistema Testes de Aceitação Executar Testes de Aceitação No entanto, e tendo em conta a tabela acima, vemos que para o Plano de Testes de Aceitação e para o Plano de Testes de Sistema, a sua elaboração divide-se em duas partes. Deste modo, temos que durante a fase de Requisitos é executada a primeira tarefa da elaboração do Plano de Testes de Aceitação – Especificar Test Cases de Aceitação. Esta servirá de input a todas as outras tarefas, bem como aumentará a qualidade do documento a produzir durante a fase de Especificação de Sistema. Do mesmo modo temos também que a elaboração do Plano de Testes de Sistema está dividido pela fase de Especificação de Sistema, na qual são especificados os test cases, e pela fase de Desenho de Sistema, onde são executadas todas as outras tarefas. No que diz respeito ao modelo evolutivo, a opção recaiu sobre o Rational Unified Process (RUP), que é um modelo de desenvolvimento de software bastante aceite em todo o mundo. O RUP utiliza uma abordagem orientada a objectos na sua concepção, sendo projectado e documentado recorrendo à notação UML (Unified Modelling Language) para ilustrar os processos em acção. É um processo considerado pesado e, como tal, preferencialmente aplicável a grande equipas de desenvolvimento e a projectos de larga escala. No entanto, o facto de ser amplamente costumizável torna possível a sua adaptação a projectos de dimensão mais reduzida. Figura - Rational Unified Process (RUP) A figura 2 dá-nos uma visão geral de todo o processo. O gráfico identifica as disciplinas que estão mais activas durante cada fase do processo. Por exemplo, a disciplina Modelação do Negócio (Business Modelling), a vermelho, demonstra grande actividade apenas nas fases de Concepção (Inception) e Elaboração (Elaboration), enquanto a Gestão do Projecto (Project Management), a azul, mostra uma actividade mais acentuada ao longo de todo o processo, do tempo e dos aspectos dinâmicos do RUP. Deste ponto de vista o processo é descrito em ciclos, fases, iterações e milestones. O RUP divide-se em quatro fases, sendo estas compostas por iterações. Enquanto as iterações têm prazos finais, as fases têm objectivos. As fases do RUP são: Concepção (Inception), durante a qual é definido o business case, ao nível do negócio, que é complementado por um modelo básico de use cases, pelo plano de projecto, e pela análise de riscos. Elaboração (Elaboration), onde o projecto começa a ganhar forma. Nesta fase é feita a análise ao sistema, e a arquitectura base do projecto é feita uma forma básica. Construção (Construction). Nesta fase o foco vai para o desenvolvimento das componentes e de outras funcionalidades do sistema. É nesta fase que o grosso da programação é feita. Transição (Transition). Nesta fase o produto é entregue ao utilizador final. Nas actividades desta fase incluem-se a formação dos utilizadores e a execução de testes para validar Uma das grandes vantagens do RUP está relacionada com a existência de iterações. Dividindo o projecto deste modo proporciona, por exemplo, a mitigação do risco, mas também necessita de um maior acompanhamento e esforço do que a tradicional abordagem sequencial. O RUP define uma disciplina de Gestão do Projecto (Project Management) que guia o gestor de projecto através da gestão de iterações. Utilizando iterações um projecto terá uma fase de planificação geral, mas terá vários planos de iteração. Utilizando um modelo evolutivo, como o RUP, as actividades de teste serão executadas de acordo com as várias iterações em cada uma das fases do processo. Deste modo, e tendo em conta a figura 2, as actividades de teste para o RUP são as seguintes: Fases Actividades de Teste Concepção N/A Elaboração Elaborar Estratégia de Testes Elaborar Plano Geral de Testes Elaborar Plano de Testes Unitários Elaborar Plano de Testes de Integração Elaborar Plano de Testes de Sistema Elaborar Plano de Testes de Aceitação Construção Executar Testes Unitários Executar Testes de Integração Executar Testes de Sistema Transição Executar Testes de Aceitação Actividades Entrando mais em detalhe em cada uma das actividades acima mencionadas, temos: Elaborar Estratégia de Testes: tem como objectivo estabelecer uma estratégia genérica e que indique como o sistema vai ser testado. O documento da Estratégia de Testes é elaborado de forma a minimizar o risco, reduzir os custos relacionados com as actividades de teste, e garantir uma implementação com sucesso. As tarefas que são executadas no âmbito desta actividade são: priorar áreas de foco, estabelecer níveis alvo de qualidade, escolher sub-níveis de teste, estimar actividades de teste. Elaborar Plano Geral de Testes: tem como objectivo fornecer um plano geral para a gestão das actividades de cada sub-nível de teste (unitário, integração, sistema e aceitação). As tarefas a executar no âmbito desta actividade são: definir critérios de entrada e de saída para cada nível de teste, estimar número de test cases necessários, definir procedimentos de escalamento de problemas, identificar os requisitos do ambiente de testes, rever a organização da equipa de testes, elaborar calendarização genérica. Elaborar Plano de Testes Unitários: tem como objectivo fornecer um plano detalhado para a execução dos sub-níveis de testes unitários. O propósito dos sub-níveis de testes unitários é o de identificar e corrigir erros e omissões no código das componentes, como módulos ou rotinas, antes de estas serem integradas com outras componentes, formando todo o pacote. O Plano de Testes Unitários deve estar alinhado com todos os outros planos. As tarefas a executar no âmbito desta actividade são: especificar test cases unitários, actualizar requisitos de ambiente de testes, rever organização da equipa de testes, elaborar calendarização detalhada. Elaborar Plano de Testes de Integração: tem como objectivo fornecer um plano detalhado para a execução dos sub-níveis de testes de integração. Testes de integração verificam a correcta execução dos componentes que interligam com outras aplicações. A comunicação entre componentes (p.e. módulos) dentro de um sub-sistema é testada num ambiente controlado e isolado interno ao projecto. Não requer a execução da aplicação como um todo, mas sim de sub-sistemas individualmente dentro da aplicação. O Plano de Testes de Integração deve estar alinhado com todos os outros planos. As tarefas a executar no âmbito desta actividade são: especificar test cases unitários, actualizar requisitos de ambiente de testes, rever organização da equipa de testes, elaborar calendarização detalhada. Elaborar Plano de Testes de Sistema: tem como objectivo fornecer um plano detalhado para a execução dos sub-níveis de testes de sistema. Testes de sistema verificam que todos os componentes (software, hardware e rede) de toda a aplicação são executadas correctamente. Os testes verificam ainda a capacidade do sistema para ler interfaces de outras aplicações, bem como gerar interfaces para outras aplicações. O Plano de Testes de Sistema deve estar alinhado com todos os outros planos. As tarefas a executar no âmbito desta actividade são: especificar test cases unitários, actualizar requisitos de ambiente de testes, rever organização da equipa de testes, elaborar calendarização detalhada. Elaborar Plano de Testes de Aceitação: tem como objectivo fornecer um plano detalhado para a execução dos sub-níveis de testes de aceitação. Testes de aceitação verificam se o sistema vai de encontro à especificação dos requisitos do cliente, bem como validam que o sistema executa o que é pretendido. Os testes de aceitação têm lugar, ou simulam, o ambiente operacional do cliente, e inclui testes de performance e de segurança. Demonstram ainda que o sistema satisfaz as expectativas do cliente, para que este o aceite. O Plano de Testes de Aceitação deve estar alinhado com todos os outros planos. As tarefas a executar no âmbito desta actividade são: especificar test cases unitários, actualizar requisitos de ambiente de testes, rever organização da equipa de testes, elaborar calendarização detalhada. Executar Testes Unitários: o objectivo desta actividade é o de identificar, corrigir e documentar erros e omissões na programação dos sub-componentes, como módulos ou rotinas, antes que estes sejam integrados com outros sub-componentes. Testes unitários permitem ao programador verificar que a especificação foi correctamente traduzida para a lógica interna do módulo ou da rotina, além de garantirem que o módulo está pronto para os testes de integração. Os resultados dos testes unitários são documentados no Relatório de Testes Unitários para futura análise de métricas. As tarefas que são executadas nesta actividade são: executar plano de testes unitários, rastrear defeitos, analisar resultados, corrigir defeitos e re-testar. Executar Testes de Integração: o objectivo desta actividade é o de integrar os componentes da aplicação, e de seguida identificar, corrigir e documentar erros relacionados com o modo como os módulos (ou sub-sistemas) se interligam, de forma a garantir que estes estão prontos para os testes de sistema. Testes de Integração permitem ao tester verificar a correcta execução dos componentes da aplicação que interligam com outras aplicações. A comunicação entre os módulos de um sub-sistema é testada num ambiente controlada e isolado, internamente ao projecto. Não requer a execução da aplicação como um todo, mas sim de sub-sistemas individualmente dentro da aplicação. Os resultados dos testes de integração são documentados no Relatório de Testes de Integração para futura análise de métricas. As tarefas que são executadas nesta actividade são: integrar os componentes do software, executar plano de testes de integração, rastrear defeitos, analisar resultados, corrigir defeitos e re-testar. Executar Testes de Sistema: o objectivo desta actividade é o de identificar, corrigir e documentar erros relacionados com a performance do sistema e das suas interfaces, bem como o de garantir que o sistema está pronto para os testes de aceitação. Testes de Sistema permitem ao tester verificar a correcta execução de todos os componentes da aplicação, incluindo a capacidade de interligação com outras aplicações. Os resultados dos testes de sistema são documentados no Relatório de Testes de Sistema para futura análise de métricas. As tarefas que são executadas nesta actividade são: executar plano de testes de sistema, rastrear defeitos, analisar resultados, corrigir defeitos e re-testar. Executar Testes de Aceitação: o objectivo desta actividade é o de demonstrar que o sistema vai de encontro com todos os critérios de aceitação definidos pelo cliente, bem como registar os resultados dos testes de aceitação para que sirvam de referência no futuro. Testes de Aceitação permitem ao tester verificar que o sistema satisfaz a especificação dos requisitos do cliente, assim como validar que executa aquilo que é pretendido. Os testes de aceitação são executados no ambiente operacional do cliente (ou numa simulação do desse mesmo ambiente), e tipicamente inclui testes de performance, de segurança e de documentação. Os testes demonstram que o sistema vai de encontro às expectativas do cliente, para que este possa dar o seu aval. Os resultados dos testes de sistema são documentados no Relatório de Testes de Aceitação para futura análise de métricas. As tarefas que são executadas nesta actividade são: executar plano de testes de aceitação, rastrear defeitos, analisar resultados, corrigir defeitos e re-testar. O Benchmark O documento de benchmarking elaborado no âmbito do projecto Test Management teve como principal objectivo fazer uma análise profunda de várias soluções de software de testes disponíveis no mercado. No entanto, o resultado desta análise não pretendia ser uma recomendação final, mas sim oferecer à empresa um documento que sirva de referência para futuras decisões no que diz respeito a software de testes. De modo a fazer a escolha de quais os vendors que iriam ser alvo de análise, foi utilizada a regra 80/20, que nos diz que 80% do mercado é absorvido por 20% da oferta. Assim sendo, foram 5 os vendors escolhidos para figurarem na avaliação: Compuware, IBM/Rational Software, Mercury, Empirix, e Segue. Para analisar as ferramentas, foram seleccionados seis critérios base: Características das ferramentas: facilidade de utilização, costumização, suporte a plataformas, linguagem de scripting, base de dados. Capacidades de execução: controlo, execução distribuída, lógica de recuperação da suite, gestão de testes. Capacidades de integração Capacidades de reporting: nível de detalhe, apresentação de relatórios. Capacidades de testes de performance e análise: funcionalidades de testes de carga e stress, funcionalidades de monitorização de testes de performance. Qualificações do vendor: requisitos de consultoria, suporte, licenciamento, preço. A Prova de Conceito Para a prova de conceito do projecto foi feita uma parceria com um dos outros projectos desenvolvidos na CGI simultaneamente a este. Esse outro projecto foi o Project Management Toolkit (PMT), que consistia no desenvolvimento de uma aplicação que suportasse todos os processos de gestão interna da empresa. Deste modo, foi possível então aplicar toda a metodologia acima descrita a um projecto de desenvolvimento, como era o do sub-sistema de Recursos Humanos do PMT. Antes que o esforço de teste tivesse início, deparou-se com uma especificidade da aplicação, que se prendia com o facto de esta ser desenvolvida sobre a ferramenta Microsoft SharePoint, a qual não possibilita qualquer desenvolvimento de código. Assim sendo, deixou de fazer sentido a execução de testes unitários, pelo que foram apenas realizados testes de integração, de sistema e de aceitação. Este pormenor permitiu ainda demonstrar alguma flexibilidade por parte da metodologia em se adaptar às contingências de cada projecto. Os principais actores presentes ao longo de todo o processo de testes são três: o cliente, a equipa de testes e o gestor de projecto. Os dois primeiros ocupam posições antagónicas dentro da estrutura da equipa: enquanto o cliente ocupa uma posição mais orientada para o negócio, a equipa de testes, ou o tester, está numa posição mais operacional. O gestor do projecto está numa posição vertical a todo o esforço de teste, estando presente ao longo de todas as actividades. Tendo sido a aplicação PMT desenvolvida mediante uma metodologia não evolutiva – Waterfall – utilizou-se a abordagem ao V-Model como fio condutor de todas as actividades de teste. Assim sendo, o primeiro documento a ser produzido foi o da Estratégia de Testes. Este documento tinha como destinatários: o cliente, que tem de assegurar que os seus requisitos foram levados em linha de conta; o gestor de projecto, que tem de documentar todos os requisitos de teste e monitorizar a adesão à estratégia de testes; a equipa de testes, que tem de saber a sua distribuição pelas diferentes actividades, bem como os métodos, meios e ferramentas a utilizar. Um dos itens da estratégia de testes passava pela definição dos sub-níveis de teste a executar. Assim, tínhamos que dentro dos testes de integração iriam ser realizados testes funcionais, dentro dos testes de sistemas, os sub-níveis seriam testes das funções existentes e regressão, testes de usabilidade e testes de documentação, e dentro dos testes de aceitação, seriam realizados testes de documentação e testes de regressão. O segundo documento foi o do Plano Geral de Testes, que tinha como destinatários, e tal como a Estratégia: o cliente, que tem de garantir que todas as milestones cumpridas e que a aplicação foi bem testada; o gestor de projecto, que tem de documentar todos os requisitos de planeamento de testes, e monitorizar a adesão à estratégia e ao plano de testes; a equipa de testes, que tem de saber as suas responsabilidades nas diferentes actividades, bem como os métodos, meios e ferramentas a utilizar. Neste documento foram feitas estimativas para os test cases, tendo sido estimados no total 21 test cases de integração, 61 test cases de sistema, e 21 test cases de aceitação. Foram ainda definidas a métricas a utilizar ao longo de todo o procedimento: progresso, que confronta o número de test cases planeados com os executados; sucesso, que confronta o número de test cases passados com os falhados; métricas de sub-nível, que especificam se os sub-níveis atingem os níveis de qualidade pretendidos; impacto da variância, que especifica a quantidade e a percentagem de defeitos por estado e por severidade. De seguida foi elaborado o Plano de Testes de Aceitação. Os destinatários deste documento são: o cliente, que tem de saber as datas em que tem de rever e aprovar toda a documentação, bem como participar na selecção de test cases de aceitação; o gestor de projecto, que tem de documentar os requisitos para o plano de testes de aceitação, e garantir que o sistema está pronto para testes de aceitação; a equipa de projecto, que tem de saber as suas responsabilidades nas diferentes actividades de testes de aceitação, os métodos, meios ferramentas a utilizar, a calendarização das actividades, e os procedimentos para o desenho dos testes. No Plano de Testes de Aceitação foram definidos os test cases a realizar, tendo sido definidos um total de 12. O quarto documento foi o Plano de Testes de Sistema, que tem como destinatários: o gestor de projecto, que tem de documentar os requisitos para o plano de testes de aceitação, e garantir que o sistema está pronto para testes de sistema; a equipa de projecto, que tem de saber as suas responsabilidades nas diferentes actividades de testes de aceitação, os métodos, meios ferramentas a utilizar, a calendarização das actividades, e os procedimentos para o desenho dos testes. No Plano de Testes de Sistema foram definidos ainda um total de 18 test cases a realizar. O último documento desta fase inicial do esforço de teste foi o Plano de Testes de Integração, que tem como destinatários, e à semelhança do que foi escrito para os testes de sistema, o gestor de projecto e a equipa de testes. Neste plano foram ainda definidos 26 test cases a realizar. Finalizada a fase de planeamento de testes, passou-se então à sua execução. Tal como definido pelo V-Model, os primeiros testes executados foram os testes de integração. Estes testes foram documentados no Relatório de Testes de Integração, cujos destinatários eram: o gestor de projecto, na medida em que tem de registar e analisar as métricas resultantes da execução dos testes; e o tester, que tem de fazer o rastreio do sucesso da execução dos test cases e o estado dos defeitos, bem como documentar as acções correctivas aplicadas para corrigir os defeitos. Na execução dos testes de integração, tivemos que todos os 26 test cases foram executados, tendo 23 sido executados com sucesso, e 3 falharam. Dos 3 test cases que falharam, 1 tinha grau de severidade 2 e 2 tinham severidade 1. Depois dos testes de integração foram realizados os testes de sistema, que ficaram documentados no Relatório de Testes de Sistema. Os destinatários do documento eram o gestor de projecto e o tester, exactamente pelas mesmas razões descritas acima para os testes de integração. Neste nível de testes, foram executados todos os test cases que haviam sido planeados, sendo que 15 foram executados com sucesso e 3 falharam. Estes 3 test cases tinham um grau de severidade 1. Este facto por si só seria razão mais que suficiente para que não estivessem satisfeitos os critérios de saída dos testes de sistema. Mas devido às restrições de tempo, à natureza académica do projecto, e apenas e só para efeitos desta prova de conceito, foi decidido prosseguir para os testes de aceitação. A última actividade de testes, os testes de aceitação, foi, tal como as restantes, documentada no Relatório de Testes de Aceitação. Este documento tinha como destinatários, não só o gestor de projecto e o tester, mas também o cliente, que tem de ter conhecimento dos resultados dos testes de aceitação, de forma a dar o seu aval à aplicação. Dos 12 test cases planeados, todos foram executados. Destes, 9 foram executados com sucesso, tendo falhado 3. Tal seria de esperar, pois advinham dos 3 test cases que falharam ao nível dos testes de sistema. Deste modo, o grau de severidade destes 3 test cases era também grau 1. O Futuro do Projecto Após a conclusão da prova de conceito, deu-se como concluído todo o trabalho relativo ao projecto Test Management. Deste modo, será agora feito o handover da metodologia às várias equipas de teste da empresa, para que estas possam agora fazer a adaptação dos processos já existentes a este novo procedimento standard para a execução de testes. Conclusão Tal como foi dito no início deste artigo, tem vindo a ganhar um cada vez maior protagonismo a necessidade das empresas em diferenciarem-se das outras através da qualidade dos seus produtos, e uma das formas de obter maiores níveis de qualidade passa por um melhor e mais eficiente procedimento de testes. Com as duas ferramentas apresentadas neste artigo – a metodologia e o benchmark – a CGI fica na posse de algo que permite desde já investir na oferta de um novo e melhor serviço, na medida em que pode dar aos seus clientes a possibilidade de investir num procedimento que é feito com base em regras predefinidas (mas suficientemente flexíveis às necessidades de cada projecto), substituindo assim os actuais métodos utilizados para testar as aplicações (ad-hoc e muito pouco eficientes). Referências Alves, João, Testing Methodology, CGI, 22-Jun-2006 Alves, João, Testing Software Benchmark, CGI, 5-Abr-2006 Implementing an Effective Test Management Process, Mercury, 2005 Rational Unified Process Base Plug-in, Version 7.0, CD-ROM, IBM, 2005 Types of testing in the development process including the V model, Coley Consulting, <http://www.coleyconsulting.co.uk/testtype.htm> Wikipedia contributors, Teste de Software, Wikipédia, a enciclopédia livre, 20-Jun-2006, <http://pt.wikipedia.org/w/index.php?title=Teste_de_software&oldid=2377989> Wikipedia contributors, Rational Unified Process, Wikipédia, a enciclopédia livre, 22-Jun-2006, <http://pt.wikipedia.org/w/index.php?title=Rational_Unified_Process&oldid=2389364> PAGE 1 Figura SEQ Figura \* ARABIC 1 – V-Model Relatório de Testes de Aceitação elatório de Testes de Sistema Relatório de Testes de Integração Relatório de Testes Unitários Plano de Testes Unitários Plano Geral de Testes Plano de Testes de Aceitação Plano de Testes de Sistema Plano de Testes de Integração Estratégia de Testes Desenvolvimento Testes Desenho Detalhado Requisitos Testes de Aceitação Testes de Sistema Testes de Integração Programação Testes Unitários Desenho do Sistema Especificação do Sistema