GESTO DE TESTES

(TEST MANAGEMENT)
Joo Antnio Nico Neto da Costa Alves
CGI Portugal
joao.alves@cgi.com
j_alves12@netcabo.pt
O desenvolvimento de sistemas de informao cada vez mais complexo. A
necessidade de tornar este processo cada vez mais eficiente, com vista reduo 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 gesto da qualidade do trabalho desenvolvido.
Assim sendo, a importncia de planear, executar e documentar testes das aplicaes
desenvolvidas crucial para os departamentos de desenvolvimento e para a
qualidade dos produtos criados.
Surge ento o conceito de gesto de testes, que consiste em quatro aspectos fundamentais: Gesto de Requisitos, Planeamento de Testes, Agendamento e Realizao
de Testes, e Gesto 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: gesto 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 criao de uma metodologia de realizao de
testes, para posteriormente a CGI utilizar nos seus projectos quando no existir uma
orientao concreta determinada pelo(s) cliente(s). Esta metodologia no pretende
definir um procedimento rgido, mas sim fornecer aos seus destinatrios uma orientao
no sentido de melhorar o processo de testes na CGI.
Inicialmente foi feito um levantamento do estado da arte que consistiu na compilao de
vrias metodologias de testes existentes dentro e fora da CGI a nvel mundial, de forma
a definir um procedimento de testes adaptado nossa realidade. Aps este levantamento
seria feita uma consulta aos colaboradores da CGI de forma a obter as suas opinies
acerca deste novo procedimento bem como da sua aplicabilidade na vida real. Ao
mesmo tempo foi feito um benchmarking das vrias ferramentas de testes disponveis
no mercado, de forma a identificar a(s) que melhor podero implementar o
procedimento de testes.
Numa segunda fase do projecto foi feita uma aplicao real da nova soluo, 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 soluo desenvolvida ao longo do projecto.
De uma forma mais esquematizada temos:
A. Criao de uma metodologia
1. Definio de um procedimento de testes para a CGI Portugal
i. Compilao de metodologias
ii. Levantamento das ferramentas apropriadas
iii. Consulta aos colaboradores
2. Aplicao e validao da soluo

Os Conceitos
Antes de definir a metodologia, foi necessrio ainda esclarecer alguns conceitos
relacionados com testes, comeando exactamente por definir o que so testes de
software.
O teste de software uma das fases do processo de engenharia de software que visa
atingir um elevado nvel de qualidade da aplicao desenvolvida. O objectivo, por
paradoxal que parea, 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 aplicao, quando na verdade ele utilizado como um processo
para encontrar defeitos. O conceito de teste de software pode ser compreendido atravs
de uma viso intuitiva ou mesmo de uma maneira formal. Existem actualmente vrias
definies para esse conceito. De uma forma simples, testar software significa verificar
atravs de uma execuo controlada se o seu comportamento ocorre de acordo com o
especificado. O objectivo principal desta tarefa encontrar o maior nmero de erros
2

dispondo do mnimo de esforo, ou seja, mostrar equipa de desenvolvimento se os

resultados esto ou no de acordo com os padres estabelecidos.
Depois da definio deste conceito mais genrico, chegou-se ao conceito base de todo o
trabalho desenvolvido: a gesto de testes.
A gesto de testes um mtodo de organizao de tudo o que se relaciona com testar
uma aplicao (p.e. requisitos de teste, planos de teste, documentao, scripts, ou
relatrios), de forma a permitir um fcil acesso e reutilizao. O objectivo da gesto de
testes o de produzir aplicaes de qualidade em menor tempo.
A maioria das organizaes no possui um processo standard de organizao, gesto e
documentao das suas actividades de teste. Muitas vezes, os testes so conduzidos
como uma actividade ad-hoc, a qual se modifica a cada novo projecto. Sem uma
fundamentao standard para planear e executar testes, bem como para gerir defeitos, o
esforo de teste torna-se no-replicvel, no-reutilizvel, e difcil de medir.
Um processo de gesto de testes correctamente desenhado permite a uma organizao:
1. Conduzir o processo de testes de uma forma melhor, mais rpida e mais barata,
na medida em que realizar actividades de teste sem seguir standards leva
criao de testes, desenho e planos que no so replicveis, e como tal
impossveis de serem reutilizados em futuras iteraes da actividade de testes.
2. Efectuar compilaes diariamente, dado que uma abordagem bem definida e
sistemtica s actividades de teste, e um repositrio centralizado para os testes,
planos e relatrios de execuo permitem um acrscimo de valor realizao
frequente de compilaes.
3. Gerir alteraes aos requisitos. Um esforo de teste completamente baseado nos
requisitos a melhor maneira de garantir que o produto final vai de encontro s
necessidades do utilizador. Sem uma gesto de testes que faa a ligao entre os
planos de teste e os requisitos funcionais da aplicao, bem como permita s
organizaes ligar as alteraes aos requisitos com os test cases (e vice-versa),
praticamente impossvel desenhar testes que verifiquem se o sistema contm a
funcionalidade especificada.
4. Implementar testes escala global, na medida em que adoptando um processo de
teste claramente definido e um mtodo colaborativo intuitivo e fcil de usar,
possvel criar uma equipa de testes virtual distribuda geograficamente.
5. Organizar vrios testes e vrios projectos, mediante um processo sistemtico que
permita s equipas de teste a gesto de mltiplos projectos e a definio clara
dos objectivos de cada um.
6. Conduzir mais do que procurar bugs. Hoje em dia as actividades de teste focamse em verificar que o desenho da aplicao e a sua funcionalidade vo de
encontro aos requisitos de negcio, pelo que o processo de testes necessita uma
definio clara das especificaes do sistema e das restries de negcio da
aplicao.
7. Testar cedo no ciclo de vida, o que permite uma reduo dos custos. Para que os
testes se iniciem ao mesmo tempo que o desenvolvimento, necessrio definir
claramente um conjunto de objectivos e prioridades que permita um melhor
entendimento do desenho de sistema, dos requisitos, e dos objectivos dos testes.

8. Obter visibilidade organizacional atravs da qualidade, que por sua vez apenas
se obtm com um processo de gesto bem estruturado e presente em toda a
organizao.
Independentemente daquilo que a aplicao faz, de como foi escrito, ou da plataforma
em que est a correr, os princpios bsicos da gesto de testes so os mesmos. Inicia-se
com a compilao e documentao dos requisitos de teste e prossegue atravs do
desenho e do desenvolvimento de testes, da execuo de testes, e da anlise dos
defeitos. O processo de testes no linear, e naturalmente difere dependendo das
prticas e metodologias de cada organizao. No entanto, os princpios que esto por
detrs de todos os processos de teste so 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 gesto de testes inerentes metodologia abordam:
1. Preparao da estratgia e do plano de testes, que so criados antes do incio da
construo. So dois documentos que andam lado a lado. Enquanto a estratgia
define a abordagem a adoptar para que os objectivos dos testes sejam atingidos,
o plano quantifica a estratgia em termos de tipo, quantidade e tempo dos
recursos (humanos ou mquinas) necessrios.
2. Anlise de risco, para que sejam identificadas as aplicaes com maior risco, de
modo a que seja planeado e executado um processo de testes mais extenso para
estas aplicaes, e para identificar quais as componentes crticas 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 definio de linhas
gerais acerca de como proceder ao longo de todo o esforo de teste, e acerca dos
processos de reporting.
4. Organizao da equipa de testes, nomeadamente a definio dos papis que cada
membro tem dentro da equipa.
5. Mtricas de teste, que permitem ao gestor do projecto avaliar os nveis de
qualidade, bem como saber o que necessrio para que se atinja um
determinado nvel de qualidade. As mtricas permitem ainda ao gestor de
projecto que este possa tomar decises acerca de continuar ou no com as
actividades de teste.
6. Seguimento de defeitos e nveis de severidade, que devem ser descritos clara e
precisamente. Um defeito pode existir num de trs estados: aberto (descoberto,
mas ainda no corrigido), resolvido (aberto e corrigido, mas ainda no retestado), e fechado (aberto, corrigido e re-testado). Os nveis de severidade so
trs: severidade 1 (problema que tem de ser corrigido e para o qual no 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. Verificao de critrios de entrada/sada dos vrios nveis e sub-nveis de teste.
Critrios de entrada so utilizados para determinar quando que um componente
do sistema est pronto a ser testado. Critrios de sada so utilizados para

determinar se a aplicao foi testada com sucesso num dado nvel, e se o

componente pode seguir para o nvel de teste seguinte.

Modelo Evolutivo vs. Modelo No Evolutivo

De forma a flexibilizar a metodologia, foram criadas duas abordagens aos
procedimentos de testes, em que uma se refere a modelos de desenvolvimento no
evolutivos, o e outro ajusta-se a modelos de desenvolvimento evolutivos.
Como modelo no evolutivo, optou-se pelo V-Model. Este modelo mapeia os tipos de
testes (unitrios, integrao, sistema e aceitao) a cada uma das fases do
desenvolvimento (ver figura 1).
Desenvolvimento

Testes

Requisitos

Estratgia de Testes

Testes de
Aceitao

Especificao
do Sistema

Plano Geral de Testes

Plano de Testes de Aceitao
Plano de Testes de Sistema
Plano de Testes de Integrao

Testes de
Sistema

Desenho do
Sistema

Plano de Testes Unitrios

Testes de
Integrao

Desenho
Detalhado

Testes
Unitrios

Relatrio de
Testes de
Aceitao

Relatrio de Testes
de Sistema

Relatrio de Testes de
Integrao

Relatrio de Testes Unitrios

Programao

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 comeo numa fase mais
inicial de todo o processo de desenvolvimento da aplicao.
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 Unitrios at aos Testes de
Aceitao, o nvel de detalhe cada vez menor, tornando-se mais orientado a uma viso
de negcio.
Tambm na figura 1 temos, para cada uma das fases do processo, o(s) documento(s) a
ser(em) elaborado(s) nessa mesma fase.

Fases
Requisitos

Desenho Detalhado
Programao
Testes Unitrios
Testes de Integrao

Actividades de Teste
Elaborar Plano de Testes de Aceitao
(Especificar Test Cases de Aceitao)
Elaborar Estratgia de Testes
Elaborar Plano de Testes de Sistema
(Especificar Test Cases de Sistema)
Elaborar Plano Geral de Testes
Elaborar Plano de Testes de Aceitao
(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 Integrao
Elaborar Plano de Testes Unitrios
N/A
Executar Testes Unitrios
Executar Testes de Integrao

Testes de Sistema
Testes de Aceitao

Executar Testes de Sistema

Executar Testes de Aceitao

Especificao de Sistema

Desenho de Sistema

No entanto, e tendo em conta a tabela acima, vemos que para o Plano de Testes de
Aceitao e para o Plano de Testes de Sistema, a sua elaborao divide-se em duas
partes.
Deste modo, temos que durante a fase de Requisitos executada a primeira tarefa da
elaborao do Plano de Testes de Aceitao Especificar Test Cases de Aceitao. Esta
servir de input a todas as outras tarefas, bem como aumentar a qualidade do
documento a produzir durante a fase de Especificao de Sistema.
Do mesmo modo temos tambm que a elaborao do Plano de Testes de Sistema est
dividido pela fase de Especificao de Sistema, na qual so especificados os test cases,
e pela fase de Desenho de Sistema, onde so executadas todas as outras tarefas.
No que diz respeito ao modelo evolutivo, a opo 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 concepo,
sendo projectado e documentado recorrendo notao UML (Unified Modelling
Language) para ilustrar os processos em aco.
um processo considerado pesado e, como tal, preferencialmente aplicvel a grande
equipas de desenvolvimento e a projectos de larga escala. No entanto, o facto de ser
amplamente costumizvel torna possvel a sua adaptao a projectos de dimenso mais
reduzida.

Figura 2 - Rational Unified Process (RUP)

A figura 2 d-nos uma viso geral de todo o processo. O grfico identifica as disciplinas
que esto mais activas durante cada fase do processo. Por exemplo, a disciplina
Modelao do Negcio (Business Modelling), a vermelho, demonstra grande actividade
apenas nas fases de Concepo (Inception) e Elaborao (Elaboration), enquanto a
Gesto do Projecto (Project Management), a azul, mostra uma actividade mais
acentuada ao longo de todo o processo, do tempo e dos aspectos dinmicos do RUP.
Deste ponto de vista o processo descrito em ciclos, fases, iteraes e milestones.
O RUP divide-se em quatro fases, sendo estas compostas por iteraes. Enquanto as
iteraes tm prazos finais, as fases tm objectivos. As fases do RUP so:
1. Concepo (Inception), durante a qual definido o business case, ao nvel do
negcio, que complementado por um modelo bsico de use cases, pelo plano
de projecto, e pela anlise de riscos.
2. Elaborao (Elaboration), onde o projecto comea a ganhar forma. Nesta fase
feita a anlise ao sistema, e a arquitectura base do projecto feita uma forma
bsica.
3. Construo (Construction). Nesta fase o foco vai para o desenvolvimento das
componentes e de outras funcionalidades do sistema. nesta fase que o grosso
da programao feita.
4. Transio (Transition). Nesta fase o produto entregue ao utilizador final. Nas
actividades desta fase incluem-se a formao dos utilizadores e a execuo de
testes para validar
Uma das grandes vantagens do RUP est relacionada com a existncia de iteraes.
Dividindo o projecto deste modo proporciona, por exemplo, a mitigao do risco, mas
tambm necessita de um maior acompanhamento e esforo do que a tradicional
abordagem sequencial. O RUP define uma disciplina de Gesto do Projecto (Project
Management) que guia o gestor de projecto atravs da gesto de iteraes. Utilizando

iteraes um projecto ter uma fase de planificao geral, mas ter vrios planos de
iterao.
Utilizando um modelo evolutivo, como o RUP, as actividades de teste sero executadas
de acordo com as vrias iteraes em cada uma das fases do processo.
Deste modo, e tendo em conta a figura 2, as actividades de teste para o RUP so as
seguintes:
Fases
Concepo
Elaborao

Construo

Transio

Actividades de Teste
N/A
Elaborar Estratgia de Testes
Elaborar Plano Geral de Testes
Elaborar Plano de Testes Unitrios
Elaborar Plano de Testes de Integrao
Elaborar Plano de Testes de Sistema
Elaborar Plano de Testes de Aceitao
Executar Testes Unitrios
Executar Testes de Integrao
Executar Testes de Sistema
Executar Testes de Aceitao

Actividades
Entrando mais em detalhe em cada uma das actividades acima mencionadas, temos:
1. Elaborar Estratgia de Testes: tem como objectivo estabelecer uma estratgia
genrica e que indique como o sistema vai ser testado. O documento da
Estratgia de Testes elaborado de forma a minimizar o risco, reduzir os custos
relacionados com as actividades de teste, e garantir uma implementao com
sucesso. As tarefas que so executadas no mbito desta actividade so: priorar
reas de foco, estabelecer nveis alvo de qualidade, escolher sub-nveis de teste,
estimar actividades de teste.
2. Elaborar Plano Geral de Testes: tem como objectivo fornecer um plano geral
para a gesto das actividades de cada sub-nvel de teste (unitrio, integrao,
sistema e aceitao). As tarefas a executar no mbito desta actividade so:
definir critrios de entrada e de sada para cada nvel de teste, estimar nmero de
test cases necessrios, definir procedimentos de escalamento de problemas,
identificar os requisitos do ambiente de testes, rever a organizao da equipa de
testes, elaborar calendarizao genrica.
3. Elaborar Plano de Testes Unitrios: tem como objectivo fornecer um plano
detalhado para a execuo dos sub-nveis de testes unitrios. O propsito dos
sub-nveis de testes unitrios o de identificar e corrigir erros e omisses no
cdigo das componentes, como mdulos ou rotinas, antes de estas serem
integradas com outras componentes, formando todo o pacote. O Plano de Testes
Unitrios deve estar alinhado com todos os outros planos. As tarefas a executar
no mbito desta actividade so: especificar test cases unitrios, actualizar
requisitos de ambiente de testes, rever organizao da equipa de testes, elaborar
calendarizao detalhada.
8

4. Elaborar Plano de Testes de Integrao: tem como objectivo fornecer um plano

detalhado para a execuo dos sub-nveis de testes de integrao. Testes de
integrao verificam a correcta execuo dos componentes que interligam com
outras aplicaes. A comunicao entre componentes (p.e. mdulos) dentro de
um sub-sistema testada num ambiente controlado e isolado interno ao projecto.
No requer a execuo da aplicao como um todo, mas sim de sub-sistemas
individualmente dentro da aplicao. O Plano de Testes de Integrao deve estar
alinhado com todos os outros planos. As tarefas a executar no mbito desta
actividade so: especificar test cases unitrios, actualizar requisitos de ambiente
de testes, rever organizao da equipa de testes, elaborar calendarizao
detalhada.
5. Elaborar Plano de Testes de Sistema: tem como objectivo fornecer um plano
detalhado para a execuo dos sub-nveis de testes de sistema. Testes de sistema
verificam que todos os componentes (software, hardware e rede) de toda a
aplicao so executadas correctamente. Os testes verificam ainda a capacidade
do sistema para ler interfaces de outras aplicaes, bem como gerar interfaces
para outras aplicaes. O Plano de Testes de Sistema deve estar alinhado com
todos os outros planos. As tarefas a executar no mbito desta actividade so:
especificar test cases unitrios, actualizar requisitos de ambiente de testes, rever
organizao da equipa de testes, elaborar calendarizao detalhada.
6. Elaborar Plano de Testes de Aceitao: tem como objectivo fornecer um plano
detalhado para a execuo dos sub-nveis de testes de aceitao. Testes de
aceitao verificam se o sistema vai de encontro especificao dos requisitos
do cliente, bem como validam que o sistema executa o que pretendido. Os
testes de aceitao tm lugar, ou simulam, o ambiente operacional do cliente, e
inclui testes de performance e de segurana. Demonstram ainda que o sistema
satisfaz as expectativas do cliente, para que este o aceite. O Plano de Testes de
Aceitao deve estar alinhado com todos os outros planos. As tarefas a executar
no mbito desta actividade so: especificar test cases unitrios, actualizar
requisitos de ambiente de testes, rever organizao da equipa de testes, elaborar
calendarizao detalhada.
7. Executar Testes Unitrios: o objectivo desta actividade o de identificar, corrigir
e documentar erros e omisses na programao dos sub-componentes, como
mdulos ou rotinas, antes que estes sejam integrados com outros subcomponentes. Testes unitrios permitem ao programador verificar que a
especificao foi correctamente traduzida para a lgica interna do mdulo ou da
rotina, alm de garantirem que o mdulo est pronto para os testes de integrao.
Os resultados dos testes unitrios so documentados no Relatrio de Testes
Unitrios para futura anlise de mtricas. As tarefas que so executadas nesta
actividade so: executar plano de testes unitrios, rastrear defeitos, analisar
resultados, corrigir defeitos e re-testar.
8. Executar Testes de Integrao: o objectivo desta actividade o de integrar os
componentes da aplicao, e de seguida identificar, corrigir e documentar erros
relacionados com o modo como os mdulos (ou sub-sistemas) se interligam, de
forma a garantir que estes esto prontos para os testes de sistema. Testes de
Integrao permitem ao tester verificar a correcta execuo dos componentes da
aplicao que interligam com outras aplicaes. A comunicao entre os
mdulos de um sub-sistema testada num ambiente controlada e isolado,
internamente ao projecto. No requer a execuo da aplicao como um todo,
9

mas sim de sub-sistemas individualmente dentro da aplicao. Os resultados dos

testes de integrao so documentados no Relatrio de Testes de Integrao para
futura anlise de mtricas. As tarefas que so executadas nesta actividade so:
integrar os componentes do software, executar plano de testes de integrao,
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 aceitao. Testes de Sistema permitem ao tester verificar a correcta execuo
de todos os componentes da aplicao, incluindo a capacidade de interligao
com outras aplicaes. Os resultados dos testes de sistema so documentados no
Relatrio de Testes de Sistema para futura anlise de mtricas. As tarefas que
so executadas nesta actividade so: executar plano de testes de sistema, rastrear
defeitos, analisar resultados, corrigir defeitos e re-testar.
10. Executar Testes de Aceitao: o objectivo desta actividade o de demonstrar que
o sistema vai de encontro com todos os critrios de aceitao definidos pelo
cliente, bem como registar os resultados dos testes de aceitao para que sirvam
de referncia no futuro. Testes de Aceitao permitem ao tester verificar que o
sistema satisfaz a especificao dos requisitos do cliente, assim como validar
que executa aquilo que pretendido. Os testes de aceitao so executados no
ambiente operacional do cliente (ou numa simulao do desse mesmo ambiente),
e tipicamente inclui testes de performance, de segurana e de documentao. 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 so
documentados no Relatrio de Testes de Aceitao para futura anlise de
mtricas. As tarefas que so executadas nesta actividade so: executar plano de
testes de aceitao, rastrear defeitos, analisar resultados, corrigir defeitos e retestar.

O Benchmark
O documento de benchmarking elaborado no mbito do projecto Test Management teve
como principal objectivo fazer uma anlise profunda de vrias solues de software de
testes disponveis no mercado. No entanto, o resultado desta anlise no pretendia ser
uma recomendao final, mas sim oferecer empresa um documento que sirva de
referncia para futuras decises no que diz respeito a software de testes.
De modo a fazer a escolha de quais os vendors que iriam ser alvo de anlise, 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 avaliao: Compuware,
IBM/Rational Software, Mercury, Empirix, e Segue.
Para analisar as ferramentas, foram seleccionados seis critrios base:
1. Caractersticas das ferramentas: facilidade de utilizao, costumizao, suporte a
plataformas, linguagem de scripting, base de dados.
2. Capacidades de execuo: controlo, execuo distribuda, lgica de recuperao
da suite, gesto de testes.
3. Capacidades de integrao
10

4. Capacidades de reporting: nvel de detalhe, apresentao de relatrios.

5. Capacidades de testes de performance e anlise: funcionalidades de testes de
carga e stress, funcionalidades de monitorizao de testes de performance.
6. Qualificaes do vendor: requisitos de consultoria, suporte, licenciamento,
preo.

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 aplicao que
suportasse todos os processos de gesto interna da empresa.
Deste modo, foi possvel ento 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 esforo de teste tivesse incio, deparou-se com uma especificidade da
aplicao, que se prendia com o facto de esta ser desenvolvida sobre a ferramenta
Microsoft SharePoint, a qual no possibilita qualquer desenvolvimento de cdigo.
Assim sendo, deixou de fazer sentido a execuo de testes unitrios, pelo que foram
apenas realizados testes de integrao, de sistema e de aceitao. Este pormenor
permitiu ainda demonstrar alguma flexibilidade por parte da metodologia em se adaptar
s contingncias de cada projecto.
Os principais actores presentes ao longo de todo o processo de testes so trs: o cliente,
a equipa de testes e o gestor de projecto. Os dois primeiros ocupam posies
antagnicas dentro da estrutura da equipa: enquanto o cliente ocupa uma posio mais
orientada para o negcio, a equipa de testes, ou o tester, est numa posio mais
operacional. O gestor do projecto est numa posio vertical a todo o esforo de teste,
estando presente ao longo de todas as actividades.
Tendo sido a aplicao PMT desenvolvida mediante uma metodologia no 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 Estratgia de Testes. Este
documento tinha como destinatrios: 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 adeso estratgia de testes; a
equipa de testes, que tem de saber a sua distribuio pelas diferentes actividades, bem
como os mtodos, meios e ferramentas a utilizar. Um dos itens da estratgia de testes
passava pela definio dos sub-nveis de teste a executar. Assim, tnhamos que dentro
dos testes de integrao iriam ser realizados testes funcionais, dentro dos testes de
sistemas, os sub-nveis seriam testes das funes existentes e regresso, testes de
usabilidade e testes de documentao, e dentro dos testes de aceitao, seriam realizados
testes de documentao e testes de regresso.
O segundo documento foi o do Plano Geral de Testes, que tinha como destinatrios, e tal
como a Estratgia: o cliente, que tem de garantir que todas as milestones cumpridas e
que a aplicao foi bem testada; o gestor de projecto, que tem de documentar todos os
requisitos de planeamento de testes, e monitorizar a adeso estratgia e ao plano de
testes; a equipa de testes, que tem de saber as suas responsabilidades nas diferentes
11

actividades, bem como os mtodos, meios e ferramentas a utilizar. Neste documento

foram feitas estimativas para os test cases, tendo sido estimados no total 21 test cases de
integrao, 61 test cases de sistema, e 21 test cases de aceitao. Foram ainda definidas
a mtricas a utilizar ao longo de todo o procedimento: progresso, que confronta o
nmero de test cases planeados com os executados; sucesso, que confronta o nmero de
test cases passados com os falhados; mtricas de sub-nvel, que especificam se os subnveis atingem os nveis de qualidade pretendidos; impacto da varincia, que especifica
a quantidade e a percentagem de defeitos por estado e por severidade.
De seguida foi elaborado o Plano de Testes de Aceitao. Os destinatrios deste
documento so: o cliente, que tem de saber as datas em que tem de rever e aprovar toda
a documentao, bem como participar na seleco de test cases de aceitao; o gestor de
projecto, que tem de documentar os requisitos para o plano de testes de aceitao, e
garantir que o sistema est pronto para testes de aceitao; a equipa de projecto, que tem
de saber as suas responsabilidades nas diferentes actividades de testes de aceitao, os
mtodos, meios ferramentas a utilizar, a calendarizao das actividades, e os
procedimentos para o desenho dos testes. No Plano de Testes de Aceitao 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 destinatrios: o
gestor de projecto, que tem de documentar os requisitos para o plano de testes de
aceitao, 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 aceitao, os mtodos, meios ferramentas a utilizar, a calendarizao 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 esforo de teste foi o Plano de Testes de
Integrao, que tem como destinatrios, e semelhana 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 ento sua execuo. Tal como
definido pelo V-Model, os primeiros testes executados foram os testes de integrao.
Estes testes foram documentados no Relatrio de Testes de Integrao, cujos
destinatrios eram: o gestor de projecto, na medida em que tem de registar e analisar as
mtricas resultantes da execuo dos testes; e o tester, que tem de fazer o rastreio do
sucesso da execuo dos test cases e o estado dos defeitos, bem como documentar as
aces correctivas aplicadas para corrigir os defeitos. Na execuo dos testes de
integrao, 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 integrao foram realizados os testes de sistema, que ficaram
documentados no Relatrio de Testes de Sistema. Os destinatrios do documento eram o
gestor de projecto e o tester, exactamente pelas mesmas razes descritas acima para os
testes de integrao. Neste nvel 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 razo mais que
suficiente para que no estivessem satisfeitos os critrios de sada dos testes de sistema.
Mas devido s restries de tempo, natureza acadmica do projecto, e apenas e s para
efeitos desta prova de conceito, foi decidido prosseguir para os testes de aceitao.

12

A ltima actividade de testes, os testes de aceitao, foi, tal como as restantes,

documentada no Relatrio de Testes de Aceitao. Este documento tinha como
destinatrios, no s o gestor de projecto e o tester, mas tambm o cliente, que tem de
ter conhecimento dos resultados dos testes de aceitao, de forma a dar o seu aval
aplicao. 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 nvel dos testes de sistema. Deste modo, o grau de severidade
destes 3 test cases era tambm grau 1.

O Futuro do Projecto
Aps a concluso da prova de conceito, deu-se como concludo todo o trabalho relativo
ao projecto Test Management.
Deste modo, ser agora feito o handover da metodologia s vrias equipas de teste da
empresa, para que estas possam agora fazer a adaptao dos processos j existentes a
este novo procedimento standard para a execuo de testes.

Concluso
Tal como foi dito no incio deste artigo, tem vindo a ganhar um cada vez maior
protagonismo a necessidade das empresas em diferenciarem-se das outras atravs da
qualidade dos seus produtos, e uma das formas de obter maiores nveis 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
servio, na medida em que pode dar aos seus clientes a possibilidade de investir num
procedimento que feito com base em regras predefinidas (mas suficientemente
flexveis s necessidades de cada projecto), substituindo assim os actuais mtodos
utilizados para testar as aplicaes (ad-hoc e muito pouco eficientes).

13

Referncias
Alves, Joo, Testing Methodology, CGI, 22-Jun-2006
Alves, Joo, 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, Wikipdia, a enciclopdia livre, 20-Jun-2006,
<http://pt.wikipedia.org/w/index.php?title=Teste_de_software&oldid=2377989>
Wikipedia contributors, Rational Unified Process, Wikipdia, a enciclopdia livre, 22Jun-2006,
<http://pt.wikipedia.org/w/index.php?
title=Rational_Unified_Process&oldid=2389364>

14