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 funda-
mentais: 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)

1
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:

A. Criação de uma metodologia
1. Definição de um procedimento de testes para a CGI Portugal
i. Compilação de metodologias
ii. Levantamento das ferramentas apropriadas
iii. Consulta aos colaboradores
2. 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

2
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:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

3
 8. 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:
1. 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.
2. 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.
3. 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.
4. Organização da equipa de testes, nomeadamente a definição dos papéis que cada
membro tem dentro da equipa.
5. 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.
6. 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)
7. 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

4
 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).

Desenvolvimento Testes

Requisitos Testes de Relatório de

Aceitação Testes de
Aceitação

Estratégia de Testes Especificação Testes de Relatório de Testes

do Sistema Sistema de Sistema

Plano Geral de Testes

Plano de Testes de Aceitação Desenho do Testes de Relatório de Testes de
Plano de Testes de Sistema Sistema Integração Integração
Plano de Testes de Integração

Plano de Testes Unitários Desenho Testes Relatório de Testes Unitários

Detalhado Unitários

Programação

Figura 1 – V-Model

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.

5
 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.

6
 Figura 2 - 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:
1. 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.
2. 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.
3. 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.
4. 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

7
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:
1. 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.
2. 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.
3. 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.

8
4. 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.
5. 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.
6. 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.
7. 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.
8. 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,

9
 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.
9. 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.
10. 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:
1. Características das ferramentas: facilidade de utilização, costumização, suporte a
plataformas, linguagem de scripting, base de dados.
2. Capacidades de execução: controlo, execução distribuída, lógica de recuperação
da suite, gestão de testes.
3. Capacidades de integração

10
 4. Capacidades de reporting: nível de detalhe, apresentação de relatórios.
5. Capacidades de testes de performance e análise: funcionalidades de testes de
carga e stress, funcionalidades de monitorização de testes de performance.
6. 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

11
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.

12
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).

13
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>

14