Teste Agil de Software

ESCOLA POLITCNICA
DE PERNAMBUCO
i
Resumo
Superar as expectativas do cliente oferecendo software de alta qualidade tarefa
fundamental das empresas de TI. Para atingir o nvel de qualidade adequado e agregar valor ao
servio imprescindvel a realizao dos testes de software. Tradicionalmente as empresas do
ramo no apresentam condies de implantar um processo de teste, desta forma, utilizam a
tcnica de testar seus softwares atravs de seus desenvolvedores de modo informal, intuitivo e
baseados na experincia prtica de seus profissionais. Outras empresas optam por no realiz-las
pois observam a atividade como entediante e custosa. Desta forma, somente focam na atividade
aps o incio da produo do software quando comeam a surgir os mais variados erros.
Empresas que incorporam em seu processo atividades de teste em software oferecem um
diferencial competitivo em relao a empresas que no utilizam esta atividade. Este trabalho traz
uma boa viso sobre testes de software e prope um processo de teste, utilizando recursos
exploratrios com o intuito de promover resultados a custos reduzidos. A modelagem do processo
foi feito com o auxlio do SPEM para descrever as fases e as atividades do processo, sua
interao com os colaboradores e os artefatos de entrada e gerados. O processo abordado pode ser
adaptado e moldado para ser empregado em qualquer organizao. Garante que testes mnimos
so realizados. Quando necessrio, ele tambm trabalha de forma a encontrar o maior nmero
de erros possvel.
Superar as expectativas do cliente oferecendo software de alta qualidade tarefa fundamental das
empresas de TI. Para atingir o nvel de qualidade adequado e agregar valor ao servio
imprescindvel a realizao dos testes de software.
Tradicionalmente as empresas no apresentam condies de implantar um processo de teste, desta
forma, utilizam a tcnica de testar seus softwares atravs de seus desenvolvedores de modo
informal, intuitivo e baseados na experincia prtica de seus profissionais.
Empresas que incorporam em seu processo atividades de teste em software oferecem um
diferencial competitivo em relao a empresas que no utilizam esta atividade.
Este trabalho prope um processo de teste, utilizando recursos
exploratrios com o intuito de promover resultados a custos reduzidos.
O Resumo monobloco com 250 a 300 palavras

ESCOLA POLITCNICA
DE PERNAMBUCO
ii
Abstract
Overcoming the expectations of the client software offering high quality is fundamental task of
the IT industry. To get the appropriate level of quality and adding value to the service is essential
to carrying out the testing of software. Traditionally companies in the industry haven't able to
establish a process of testing this way, using the technique to test its software through its
developers so informal, intuitive and based on practical experience of its professionals. Other
companies choose to don't implement them because observe the activity as tedious and
expensive. Thus, only focusing on the activity after the start of production of software when they
start to emerge the most varied errors. Companies that incorporate activities in their process of
testing in software offer a competitive differential regarding companies that don't use this activity.
This work provides a good overview on testing of software and proposes a process of testing,
using resources exploration in order to promote results at reduced costs. The modeling of the
process was done with the SPEM help to describe the phases and activities of the process, its
interaction with the staff and the artifacts of entry and generated. The process can be discussed
and shaped adapted to be used in any organization. It ensures that minimum tests are conducted.
When necessary, he also works in order to find the largest possible number of errors.To surpass
clients expectations, offering high quality software is a fundamental task of IT companies. To
meet an adequate quality level, adding value to its services, is of utmost importance to perform
software tests.
In most cases, companies do not present the required conditions or resources to implement a
software testing process. These companies employ the technique of testing its software through
its developers, in an informal and intuitive way, based primarily in the practical experience of its
professionals.
Companies which incorporate in its process software testing activities, offer a competitive edge
when compared to companies which do not use this activity.
This work proposes an a test process, employing exploratory resources, aiming at improving
results, at with a low cost.
Revise o texto em ingls

ESCOLA POLITCNICA
DE PERNAMBUCO
iii
Sumrio
ndice de Figuras v
ndice de Tabelas vi
Tabela de Smbolos e Siglas vii
1 Introduo 9
1.1 Motivao 10
1.2 Objetivos 11
1.3 Metodologia 11
1.4 Contribuio 12
1.5 Estrutura da Monografia 13
2 Testes de Software 14
2.1 Histria da Atividade de Teste 14
2.2 Verificao e Validao 16
2.3 Estratgias Fundamentais dos Testes 17
2.4 Tipos de Testes de Software 18
2.5 Nveis de Testes 19
2.6 Formas de Testar 20
2.6.1 Testes Manuais 20
2.6.2 Testes Automticos 21
2.7 Conceito V de testes 22
2.8 Processo tradicional de teste 23
3 Metodologias de Desenvolvimento de Software 26

3.1 Pessoas versus Processo 27
3.2 XP - eXtreme Programming 28
3.3 Scrum 29
3.4 O Manifesto para Desenvolvimento gil de Software 29
3.5 RUP Rational Unified Process 30
4 O Processo gil de Teste - PAT 31

4.1 SPEM - Software Process Engineering Metamodel 32
4.1.1 Principais Elementos de Definio do Processo 33
4.2 Definio de PAT 35
4.3 Composio 36
4.3.1 Papis 37
4.3.2 Estrutura 40
4.3.3 Planejamento 42
4.3.4 Projeto de Teste 42
4.3.5 Preparao 45
4.3.6 Execuo de Teste 46
4.3.7 Automao 47
4.3.8 Finalizao 47
ESCOLA POLITCNICA
DE PERNAMBUCO
iv
4.3.1 Acompanhamento e Controle 48
4.4 Vantagens e Desvantagens 49
5 Consideraes Finais e Trabalhos Futuros 50

5.1 Trabalhos Relacionados 51
5.1.1 Ambiente 51
5.1.2 Descrio do Processo 51
5.1.3 Benefcios do Processo para Organizao 52
5.2 Trabalhos Futuros 52
5.3 Dificuldades Encontradas 53
5.4 Contribuio 53
ndice de Figuras v
ndice de Tabelas vi
1 Introduo 9
1.1 Motivao 10
1.2 Objetivos 11
1.3 Metodologia 11
1.4 Contribuio 12

3.1 Pessoas Processo 27
3.3 Scrum 29

4.3 Composio 37
4.3.1 Papis 38
4.3.2 Estrutura 41
4.3.5 Preparao 46
4.3.7 Automao 48
4.3.8 Finalizao 48
ESCOLA POLITCNICA
DE PERNAMBUCO
v
5 Consideraes Finais e Trabalhos Futuros 51
5.1.1 Ambiente 52
5.4 Contribuio 54
ndice de Figuras v
ndice de Tabelas vi
1 Introduo 9
1.1 Motivao 10
1.2 Objetivos 11
1.3 Metodologia 11
1.4 Contribuio 12
2 Conceitos Bsicos 14
2.1 Teste 14
2.2 Metodologia gil 15

4.1 Pessoas Processo 33
4.3 Scrum 35

5.2 Composio 39
5.2.1 Papis 40
5.2.2 Estrutura 43
5.2.5 Preparao 48
5.2.7 Automao 50
5.2.8 Finalizao 50
ESCOLA POLITCNICA
DE PERNAMBUCO
vi
6 Concluso 53
6.1.1 Ambiente 54
6.4 Contribuio 56
ESCOLA POLITCNICA
DE PERNAMBUCO
vii
ndice de ImagensFiguras
Figura 2.1: Grfico ilustrando o momento de interromper os testes.................................................15

Figura 2.2: Exemplo ilustrativo de validao e verificao..............................................................16
Figura 2.3: O conceito V de testes de software.............................................................................23
Figura 2.4: 11 passos do Processo de Teste de Software..................................................................25
Figura 4.1: Nveis de modelagem definidos pela OMG...................................................................32
Figura 4.2: Viso Macro do PAT ......................................................................................................41
Figura 4.3: PAT - Planejamento .......................................................................................................42
Figura 4.4: PAT - Checklist de Testes Genricos .............................................................................44
Figura 4.5: PAT - Projeto de Teste ...................................................................................................45
Figura 4.6: PAT - Preparao de Teste..............................................................................................46
Figura 4.7: PAT - Automao............................................................................................................47
Figura 4.8: PAT - Finalizao............................................................................................................48
Figura 4.9: PAT - Acompanhamento e controle................................................................................49
Figura 1: Nveis de modelagem definidos pela OMG....................................................................13
Figura 2: Grfico ilustrando o momento de interromper os testes.................................................19
Figura 3: Validao e verificao...................................................................................................20
Figura 4: O conveito V de testes de software.............................................................................27
Figura 5: 11 passos do Processo de Teste de Software...................................................................29
Figura 6: Viso Macro do PAT.......................................................................................................44
Figura 7: PAT - Planejamento.........................................................................................................46
Figura 8: PAT - Templates de Testes Genricos.............................................................................47
Figura 9: PAT - Projeto de Teste.....................................................................................................48
Figura 10: PAT Preparao de Teste............................................................................................49
Figura 12: PAT - Automao..........................................................................................................51
Figura 13: PAT - Finalizao..........................................................................................................51
Figura 14: PAT Acompanhamento e controle..............................................................................52
ESCOLA POLITCNICA
DE PERNAMBUCO
viii
ndice de Tabelas
Tabela 4.1: Representao grfica dos principais elementos do SPEM........................................... 32

Tabela 1: Representao grfica dos principais elementos do SPEM............................................19
ESCOLA POLITCNICA
DE PERNAMBUCO
ix
Tabela de Smbolos e Siglas
CIN Centro de Informtica UFPE

SPEM - Software Process Engineering Metamodel
OMG - Object Management Group
PAT - Processo gil de Teste.
PML - Process Modeling Language
UML - Unified Modeling Language
XP - eXtreme Programming
IEEE - Institute of Electrical and Electronics Engineers)
DSDM - Dynamic System Development Method
RAD - Rapid Application Development
RUP - Rational Unified Process
ESCOLA POLITCNICA
DE PERNAMBUCO
x
Agradecimentos
Este trabalho, desenvolvido durante aproximadamente quatro meses, fruto dos conhecimentos
adquirido durante cinco anos no curso de Engenharia da Computao, do Curso Seqencial de
Formao Complementar realizado pelo Centro de Informtica (CIN) em parceria com a Motorola
e da colaborao de amigos que estiveram ao lado durante esse perodo.
Agradeo a minha famlia pelo apoio e motivao que me incentivaram a ir sempre busca
de meus objetivos.
Agradecer tambm ao meu orientador Mrcio Lopes Cornlio pela disposio, ajuda
pacincia e orientaes.
ESCOLA POLITCNICA
DE PERNAMBUCO
11
Captulo
Introduo
A importncia do software tem crescido cada vez mais nas organizaes e na sociedade. A cada
dia ele desempenha atividades mais importantes, que trazem benefcios e agregam valor ao meio
no qual atua. Geralmente, essas atividades podem ser realizadas pelo homem. Porm, algumas
delas s podem ser executadas por computadores. A tendncia que o mundo se torne cada vez
mais dependente dos softwares.
Determinadas atividades desempenhadas por computadores tm impacto direto na sade
financeira de uma instituio. Outras delas esto extremamente relacionadas vida. Tornam-se
cada vez mais necessrios produtos com alto nvel de qualidade e que satisfaam o cliente. Por
outro lado, os softwares que esto disponveis no mercado, em sua grande maioria, apresentam
falhas, havendo a necessidade de disponibilizar verses novas do sistema apenas com correes
de erros que, enquanto no forem corrigidos, afetam a funcionalidade, o desempenho, a
segurana, a confiabilidade e a usabilidade do sistema, tendo impacto direto no ambiente no qual
ele atua e podendo trazer conseqncias graves.
ESCOLA POLITCNICA
DE PERNAMBUCO
12
Informaes de mercado dizem que mais de 90% dos sistemas so liberados com graves
defeitos [1]. Objetivando o controle da qualidade dos softwares torna-se necessrio a implantao
de um conjunto de atividades voltadas para encontrar defeitos nesses sistemas. Porm, em muitos
casos, as atividades de testes so informais, sem metodologia e responsabilidades definidas.
A insuficincia de testes um dos principais motivos de falhas nos Projetos de
Desenvolvimento de Software [2]. Um processo de teste bem definido e eficiente unido a uma
equipe de teste independente so fundamentais para garantir a qualidade do produto e encontrar
os erros antes que a aplicao entre em produo. O custo para corrigir os erros em um sistema j
implantado cem vezes maior que o custo que se teria para corrigir esses mesmos erros em fase
de desenvolvimento [3].
Atualmente, as metodologias geis [4] ganharam repercusso por serem boas no
gerenciamento do desenvolvimento de software, incorporando testes unitrios ao processo de
desenvolvimento, realizando testes caixa-branca em seu processo, no havendo uma ateno
maior em testes de sistema.
Um modelo de processo de software uma representao das atividades do mundo real de
um processo de produo de software [5]. A modelagem de processos de software atualmente
uma grande fonte de pesquisa na qual a comunidade acadmica e as empresas tm aplicado
diversos esforos, a fim de aprimorar a expressividade e a percepo do processo como um todo.
A modelagem de um processo deve ser conduzida de modo a possibilitar o entendimento e
a padronizao do mesmo. A notao escolhida, SPEM (Software Process Engineering
Metamodel), o meta-modelo mais difundido e aceito, proposto pela da OMG(Object
Management Group) para a descrio de um processo concreto de desenvolvimento de software
[6].
Este trabalho prope definir e modelar um processo gil de teste criando um processo para
suprir uma necessidade de mercado. Dentre as estratgias de testes existentes, ser abordada a
forma exploratria e baseada em caso de uso. Acreditamos, que para a equipe de teste ser uma
equipe de sucesso no deva depender da metodologia utilizada no processo de desenvolvimento
do software, para com isso atender a demanda de projetos que necessitam de teste . Pois , onde
est a referncia?
ESCOLA POLITCNICA
DE PERNAMBUCO
13
1.1Motivao
Empresas necessitam de equipe de testes para comprovar que seus produtos cheguem aos clientes
com nvel de qualidade adequado ao objetivo da empresa, porm uma equipe de teste que
trabalha com testes tradicionais, seguindo o RUP, que por ser detalhista na construo de artefatos
e na quantidade de papeis envolvidos no processo, pode deixar a equipe bastante custosa para a
empresa burocratizando atividades que poderiam ser feitas de forma gil focando no objetivo
principal. Encontrar erros e produzir relatrios de resultado de teste deve ser o foco de uma
equipe de teste funcional cobrindo assim uma deficincia dos testes unitrios das metodologias
geis de desenvolvimento e no sendo muito burocrticas como as metodologias mais
conservadoras.
1.2Objetivos
O objetivo deste trabalho de graduao apresentado neste documento definir e modelar um
Processo gil de Teste (PAT). Uma metodologiaUm processo que planeje e organize as atividades
a serem realizadas, que garanta que o sistema est de acordo com determinado padro, que
possibilite uma melhor distribuio dos recursos utilizados e um aumento na deteco dos erros.
Esse processo visa aumentar a garantia de qualidade, pois ser realizado ao longo do processo de
desenvolvimento, e o controle de qualidade, visto que far verificaes para comprovar que o
sistema est de acordo com o que foi especificado pelo cliente.
1.3Metodologia
O projeto ser iniciado com a reviso bibliogrfica, enfocando os pontos destacados na
abordagem proposta:
Contextualizar a rea de Testes de software apresentando tipos, estratgias, nveis
de teste, tcnicas e boas prticas na rea.
Introduzir conceitos de projetos geis.
Apresentao de modelagem de processo
ESCOLA POLITCNICA
DE PERNAMBUCO
14
Em seguida ser proposta o modelo de processo de teste de software. Essa etapa
compreende:
Apresentar uma metodologia gil para desenvolvimento de software.
Relatar a importncia dos testes exploratrios.
Definir testes em par. Dois conceitos devem ser abordados.
o Testes apenas com a equipe de teste, objetivando homogeneidade do
conhecimento
o Participao do lder de desenvolvimento para melhor entendimento da
viso do cliente e para definio, caso ainda no tenha, do escopo negativo
de teste.
Criao de checklist para testes exploratrios, guiando o testador na execuo dos
testes.
Definir estratgia para escolha por testes exploratrios ou criao de projetos de
teste.
Com base na abordagem, sero realizadas atividades, com iteraes de uma semana,
ilustrando a aplicao dos conceitos introduzidos, relatando as dificuldades e a importncia
processo de testes. As principais atividades so:
1. Reviso Bibliogrfica
2. Planejamento da monografia
3. Planejamento para o estudo do trabalho relacionado
4. Modelar o processo
5. Realizao do trabalho relacionado e coleta de resultados
6. Analise dos Resultados
7. Escrita da Monografia
1.4Contribuio
Este trabalho de graduao vai procurar desenvolver um processo de teste, com
caractersticas de processos geis, para suprir uma necessidade de mercado. Dentre as estratgias
de testes existentes, devemos abordas abordar a forma exploratria e baseada em caso de uso.
ESCOLA POLITCNICA
DE PERNAMBUCO
15
Ser feita uma modelagem do processo com o auxlio do SPEM (Software Process
Engineering Metamodel) para descrever as fases e as atividades, sua interao com os
colaboradores e os artefatos de entrada e sada.
Iremos fornecer uma boa viso de testes de software e tentaremos construir um processo
que garanta que testes bsicos sejam testados de forma rpida, possibilitando uma melhor
distribuio dos recursos e o aumento na deteco de erros. Um guia de cenrios de testes que
abrange testes de campo, negcio, usabilidade, segurana ser construdo. Uma planilha de
execuo que instancia o guia de cenrios de testes ser concebida. O guia ser genrico o
suficiente para suprir a necessidade de um projeto que seja apresentado a equipe de teste. O guia
tem por objetivo auxiliar na execuo e poder ser alterado para adaptar-se a qualquer requisito
ou projeto.
O processo deve ser flexvel o suficiente para ser adaptado e moldado para ser empregado
em qualquer organizao objetivando tornar a atividade de teste menos informais. Quando
necessrio, ele trabalha de forma a encontrar o maior nmero de erros possvel, mesmo que isto
signifique aumento no esforo.
1.5Estrutura da Monografia
Este documento foi estruturado em captulos da seguinte maneira, aps esta introduo:
Captulo 2 Apresenta uma viso geral dos conceitos bsicos necessrios para o
entendimento desta monografia. Neste captulo definimos: Teste, Metodologia gil e SPEM.
Captulo 32 Testes de Software -Coloque o nome do captulo - Apresenta uma viso
geral sobre teste de software, mostrando modelos de teste tradicionais, a evoluo das atividades
de testes, os conceitos, estratgias, tipos e nveis de testes e algumas formas de testar.
Captulo 43 Metodologias de Desenvolvimento de Software - Apresenta conceitos e
exemplos de algumas metodologias geis de desenvolvimento de software.
Captulo 54 O Processo gil de Teste - PAT - Com base no que foi apresentado nos
captulos anteriores, este captulo prope um processo para testes de forma gil.
Captulo 5 Consideraes Finais e Trabalhos Futuros - 65 Apresenta as consideraes
finais, relata um trabalho relacionado alm de propor trabalhos futuros.
ESCOLA POLITCNICA
DE PERNAMBUCO
16
Captulo
Conceitos Bsicos
Antnio, retire este captulo. Como falei, os conceitos j so abordados nos captulos seguintes. A
seo sobre SPEM pode ficar no captulo da proposta do processo.
Este captulo apresenta os conceitos bsicos necessrios para o entendimento desta monografia.
Vamos apresentar o conceito de Teste, Metodologia gil e SPEM.
2.1Teste
A atividade de teste nem sempre foi bem aceita pela indstria em geral, algumas empresas
querem construir seus produtos a custos reduzidos para obter altos lucros e esquecem da
importncia da qualidade. A concorrncia e a diversidade do mercado foram mudando com o
decorrer dos anos e seguindo este caminho houve mudanas na forma de pensar dos fabricantes.
Com o passar dos anos e da coleta de informaes descobriu-se a necessidade de se testar
o que produzido para garantir que o produto seja bem sucedido. Dependendo do foco do
produto devem ser realizados testes de grande, mdia e baixa granularidade.
ESCOLA POLITCNICA
DE PERNAMBUCO
17
Atualmente, em carros de corrida, como na frmula 1, o tempo de teste bem maior que o
tempo que os carros passam correndo, esta mesma proporo apresentada no lanamento de um
nibus espacial. Esta caracteristica de ter um grande tempo de testes em comparao ao tempo
que o produto ser efetivamente usado primordial para a execuo de um bom trabalho. Para
esses dois exemplos a atividade de testes no uma escolha, ela se tornou essencial para o
sucesso do produto. Quanto mais cedo s falhas forem encontradas menos tempo ser
desperdiado tendo como conseqncia maior satisfao de todos os entusiastas do projeto.
2.2Metodologia gil
Metodologias geis tm como caracterstica principal a diminuio da burocracia, em
comparao a metodologias tradicionais. Estas metodologias despertaram o interesse em toda a
extenso da indstria do software. Nesta seo iremos explorar os motivos para as metodologias
geis serem benquistas, focando no somente em sua agilidade, mas tambm em sua natureza
adaptvel e na sua tendncia em colocar as pessoas em primeiro lugar.
A prtica do desenvolvimento de software uma atividade catica em sua maior parte,
normalmente com foco em apenas duas atividades: codificar e consertar. [7] O software escrito
sem um plano definido e o projeto do sistema repleto de vrias decises de curto prazo. Isso
funciona muito bem se o sistema pequeno, mas medida que o sistema cresce, torna-se cada
vez mais difcil adicionar novos recursos a ele. Defeitos subseqentes se tornam cada vez mais
dominantes e cada vez mais difceis de serem eliminados. Um sinal tpico de um sistema desse
tipo uma longa fase de testes depois que o sistema est finalizado. Esta longa fase de testes
entra em confronto direto com o cronograma, pois testes e depurao so atividades cujos tempos
so impossveis de serem estimados.
Ns convivemos com este estilo de desenvolvimento, mas tambm temos a alternativa de
usar metodologias tradicionais. Metodologias impem um processo disciplinado no
desenvolvimento de software, com o objetivo de torn-lo mais previsvel e mais eficiente foca-se
mais no planejamento que no prprio desenvolvimento.
Metodologias tradicionais no tm sido percebidas como sendo particularmente bem-
sucedidas. Elas tm sido notadas menos ainda por serem populares. A crtica mais freqente que
estas metodologias so burocrticas. H tanta coisa a se fazer para seguir a metodologia que o
ritmo de desenvolvimento fica mais lento. [7]
ESCOLA POLITCNICA
DE PERNAMBUCO
18
Como uma reao a tais metodologias, um novo grupo surgiu nos ltimos anos. Durante
algum tempo elas foram conhecidas como Metodologias Leves, mas agora o termo mais aceito
Metodologia gil. Para muitas pessoas o apelo das metodologias geis a reao delas
burocracia das metodologias tradicionais. Estas novas metodologias tentam criar um equilbrio
entre nenhum processo e muito processo, provendo apenas o suficiente de processo para obter um
retorno razovel.
O resultado disso tudo que os mtodos geis tm algumas mudanas de nfase
significativas em relao aos mtodos tradicionais. A diferena mais evidente que metodologias
geis so menos centradas em documentao, normalmente enfatizando uma quantidade menor
de documentos para uma dada tarefa. De vrias maneiras, elas so mais voltadas ao cdigo-fonte
do programa: seguindo um caminho que diz que a parte-chave da documentao o prprio
cdigo-fonte.
Metodologias geis so adaptativas ao invs de predeterminantes. Metodologias de
engenharia tendem a tentar planejar uma grande parte do processo de desenvolvimento
detalhadamente por um longo perodo de tempo. Este mtodo tem um bom funcionamento at o
surgimento da necessidade de mudana. Ento a natureza de tais mtodos a de resistir
mudana. Para os mtodos geis, entretanto, mudanas so bem-vindas. Eles tentam ser processos
que se adaptam e se fortalecem com as mudanas, at mesmo ao ponto de se auto-modificarem.
Mtodos geis so orientados a pessoas ao invs de serem orientados a processos. O
objetivo dos mtodos tradicionais de definir um processo que ir funcionar bem,
independentemente de quem os estiverem utilizando. Mtodos geis afirmam que nenhum
processo jamais ser equivalente habilidade da equipe de desenvolvimento. Portanto, o papel do
processo dar suporte equipe de desenvolvimento e seu trabalho.
O SPEM um metamodelo proposto pela OMG Object Management Group para a descrio de
um processo de software ou uma famlia relacionada de processos. Diferente da maioria das
Linguagens de Modelagem de Processos (PML- Process Modeling Language) o SPEM surge
como uma proposta de unificao entre as diferentes metodologias propostas para modelagem de
processos. O SPEM utiliza a orientao a objeto para modelar uma famlia relacionada de
processos de software e usa a Unified Modeling Language (UML) como notao. A Figura 1
mostra as quatro arquiteturas de modelagem definidas pelo OMG.
ESCOLA POLITCNICA
DE PERNAMBUCO
19
Figura 1: Nveis de modelagem definidos pela OMG
O SPEM encontra-se no nvel M2 da arquitetura de quatro camadas da OMG e seu metamodelo

definido usando um subconjunto da UML de modo semelhante da UML. Este subconjunto da
UML corresponde s facilidades implementadas e apoiadas pelo MOF. Pela proposta do SPEM
um processo executado aquele, na produo no mundo real ou como o processo ordenado,
sendo nivelado no nvel M0. A definio do processo correspondente est nivelada em M1. O
SPEM pode ser usado para definir todos os tipos de processos, incluindo os que estejam
focalizados no uso especfico da UML. Instncias para orientar subclasses para descrever prticas
com a UML podem ser criadas com ferramentas para um processo UML especfico. A UML
definida por um metamodelo, que definido como uma instncia do metamodelo MOF. Um
subconjunto da notao grfica da UML usado para descrever este metamodelo. O metamodelo
SPEM foi elaborado similarmente, e formalmente definido como uma extenso de um
subconjunto da UML chamado SPEM-Foundation.
Principais Elementos de Definio do Processo
Os elementos de definio do processo ajudam na demonstrao de como o processo ser
executado. Descrevem ou restringem o comportamento geral do processo em execuo, e so
utilizados para auxiliar o planejamento, a execuo e o monitoramento do processo. So
divididos em trs grandes grupos: Pacote da Estrutura do Processo, Pacote dos Componentes do
Processo e Pacote do Ciclo de Vida do Processo.
Um Process pode ser visto como uma colaborao entre papis para alcanar um objetivo. Para
guiar sua execuo, determina-se a ordem na qual as atividades devem ser executadas. Tambm
existe a necessidade de definir o modelo do processo no tempo, utilizando-se para isso a estrutura
Lifecycle em termos de fases e iteraes. Um Process um ProcessComponent que pode ser
apresentado como um processo completo.
Um ProcessComponent elemento de convenincia de descries do processo que consistente
internamente e pode ser reutilizado com outros ProcessComponents para montar um processo
completo.
Um ProcessComponent importa um grupo no arbitrrio de elementos de definio de processo,
modelados no SPEM pelo ModelElements.
ESCOLA POLITCNICA
DE PERNAMBUCO
20
Um Lifecycle de processo definido como uma seqncia de fases que alcanam uma meta
especfica, definindo o comportamento completo de um processo que ser executado em um dado
projeto ou programa.
Um Workdefinition um tipo de Operation que descreve o trabalho executado no processo. Suas
subclasses so Activity, Phase, Iteration, e Lifecycle. Um WorkDefinition pode ser composto de
outros WorkDefinitions, estando diretamente relacionados aos WorkProducts que so usados
atravs da classe ActivityParameter, especificando se so usados como entrada ou como sada dos
elementos de trabalho.
O ProcessPerformer representa de forma abstrata o processo inteiro ou um de seus
componentes, e usado para WorkDefinitions prprias que no tm mais um proprietrio
especifico.
O ProcessPerformer tem uma subclasse, ProcessRole. Um ProcessRole define responsabilidades
sobre WorkProducts especficos, e sobre os papis que executam e auxiliam em atividades
especficas. Um ProcessPerformer o executor de WorkDefinitions agregadas de alto nvel que
no podem ser associadas com ProcessRoles individuais.
A cada WorkDefinition pode ser associada uma Precondition e uma Goal. As Preconditions e
Goals so Constraints, onde a Constraint expressa na forma de uma expresso booleana
seguindo sintaxe semelhante quela de uma condio de proteo na UML. A condio
expressa em termos dos estados dos WorkProducts que so os parmetros da WorkDefinition ou
de uma WorkDefinition inclusa.
Uma Activity a subclasse principal da WorkDefinition. Ela descreve uma parte do trabalho
executado por um ProcessRole: as tarefas, operaes, e aes que so executadas por um papel
ou com a qual o papel pode auxiliar. Uma atividade pode consistir de elementos atmicos
chamados Steps. Uma Activity podendo fazer uso dos ProcessRoles adicionais que so os
assistentes na Activity.
Alguns dos elementos do SPEM podem ser representados graficamente atravs de cones outros
existem como metainformao e no possuem representao grfica.
Tabela 1: Representao grfica dos principais elementos do SPEM

Esteretipo Representao
WorkProduct
WorkDefinition
Guidance
Activity
ProcessRole
ProcessPackage
Process
ESCOLA POLITCNICA
DE PERNAMBUCO
21
Document
UMLModel
ESCOLA POLITCNICA
DE PERNAMBUCO
22
Captulo
Testes de Software
O mercado est cada vez mais competitivo e as empresas buscam estratgias para assumirem um
papel de destaque. Melhorar a qualidade do produto final e reduzir os custos do desenvolvimento
deste produto so importantes objetivos das organizaes. Visando aumentar a qualidade do
produto a atividade de teste de software visa reduzir os custos do desenvolvimento e
principalmente da manuteno, minimizando os defeitos do produto final tendo como premissa a
satisfao do cliente.
3.1Histria da Atividade de Teste

Em 1950, Alan Turing escreveu o primeiro artigo cientifico que abordava questes de teste de
software. No seu artigo ele definia o teste operacional para demonstrar o comportamento da
inteligncia de um programa semelhante ao ser humano Para passar pelo teste o sistema deve
possuir habilidades humanas num nvel capaz de enganar um interrogador humano.
ESCOLA POLITCNICA
DE PERNAMBUCO
23
Em 1957, foi criado o conceito de Teste de Software para deteco de erros ao final do
processo de desenvolvimento. Antes deste conceito a atividade de teste em software era uma
simples tarefa de percorrer o cdigo e corrigir erros j conhecidos.
Em 1970, quando o conceito de Engenharia de Software passou a ser utilizado como
modelo para as organizaes o processo de desenvolvimento de software passou a ter mais
relevncia.
Em 1972 houve a primeira conferncia sobre teste na Universidade da Carolina do Norte.
Mas um trabalho mais completo s foi produzido em 1979 por Glenford Myers. Neste trabalho a
atividade de teste foi definida como um processo de trabalho com a inteno de encontrar erros.
At esse momento, o objetivo do teste era somente provar o bom funcionamento de uma
aplicao. Todos os esforos da atividade estavam voltados para a comprovao desse fato e
conseqentemente poucos defeitos eram encontrados. Myers props que se o objetivo do teste for
encontrar erros, uma quantidade maior de problemas ser encontrada. Uma vez que vrios
cenrios sero buscados para testar o comportamento do aplicativo em vrias circunstncias. Essa
nova viso revolucionou a forma de abordar o problema, no entanto, os testes continuavam a
serem executados no final do processo de desenvolvimento.
Os primeiros conceitos de qualidade de software surgiram no incio dos anos 1980. Nesses
novos conceitos, desenvolvedores e testadores trabalham juntos desde o incio do processo de
desenvolvimento. Agora a atividade de teste ocorre de forma paralela ao processo de
desenvolvimento com planejamento, analise anlise, implementao e execuo especficos.
As primeiras ferramentas para realizar as atividades teste s comearam a ser fabricadas
em 1990. Elas possibilitam a execuo de teste que no podiam ser feitos manualmente. Como
testes de carga, desempenho, entre outros.
Segundo a IEEE (Institute of Electrical and Electronics Engineers) Standard Glossary of
Software Engineering Terminlogy, teste de software um processo de exercitar um software ou
componente sobre condies especficas, observando ou gravando os resultados, e realizando
uma avaliao sobre algum aspecto.
impossvel ter um produto livre de erros devido ao nmero enorme de cenrios
possveis. Porm, aps uma bateria de testes a probabilidade de encontrar erros graves, que
inviabilizem uma entrega, mnima e muito pequena para os erros em geral. O momento certo de
parar de testar o momento em que o custo para testar e corrigir os erros mais caro que o custo
da falha ocorrer em produo [11]. A Figura 2.1 mostra o momento de interromper os testes.
ESCOLA POLITCNICA
DE PERNAMBUCO
24
Figura 2.1: Grfico ilustrando o momento de interromper os testes
A criticidade do sistema quem define a quantidade de testes. Quanto mais crtico for o
sistema mais testes tero que ser executados para garantir a qualidade dele. Um exemplo a
comparao do tempo de parar os testes entre um software de locadora e um software de
controlador de vo. Ocorrendo um erro em produo no software da locadora tem um custo muito
menor do que encontrar erro em produo no software de controlador de vo.
Segundo Myers, quanto mais tarde um erro descoberto mais caro ele . Ele aplica a
Regra de 10 aos custos de correo do erro. Ou seja, quando um erro no encontrado em uma
fase do processo de desenvolvimento, os custos de correo so multiplicados por 10 para cada
fase que ele se propaga. Isso significa dizer que erros encontrados em produo so
extremamente caros.
3.2Verificao e Validao
Existem muitas diferenas entre o que o cliente necessita, e o que o analista projeta. A
Figura 2.2 exemplifica bem o que acontece durante a construo de um sistema.
ESCOLA POLITCNICA
DE PERNAMBUCO
25
Figura 32.2: Exemplo ilustrativo de validao e verificao
Os testes de verificao so tipos de teste que geralmente so realizados sobre os

documentos que so produzidos durante o ciclo de desenvolvimento. Essas atividades so
iniciadas antes da codificao do sistema, elas comeam na fase de requerimento e continuam
atravs da codificao do produto. O teste consiste na realizao de inspees, revises e/ou
auditorias sobre os produtos gerados em cada etapa do processo, evitando que dvidas e assuntos
mal resolvidos passem para a prxima fase do processo de desenvolvimento.
A verificao tem por objetivo provar que o produto vai ao encontro dos requerimentos
especificados. Ela garante a qualidade do software na produo e na manuteno.
Os testes de validao tambm so aplicados diretamente no software. Eles podem ser
aplicados em componentes isolados, mdulos existentes ou em todo o sistema. Esse tipo de teste
avalia se o sistema atende aos requisitos e especificaes analisadas nas fases iniciais do projeto,
se ele vai ao encontro dos requerimentos do usurio.
Testes de verificao e validao so complementares, eles no so atividades
redundantes. Eles possuem objetivos e naturezas distintas, contribuem para a deteco de erros e
aumentam a qualidade final do produto.
ESCOLA POLITCNICA
DE PERNAMBUCO
26
3.3Estratgias Fundamentais dos Testes
Para executar os testes de validao existem duas estratgias: estratgia caixa branca e a
estratgia caixa preta. A utilizao destas estratgias determinando para aumentar a
probabilidade de deteco de erros presentes no produto.
Essas estratgias no so complementares. Se as duas estratgias forem combinadas de
forma apropriada o resultado final ser um software de melhor qualidade.
Os testes caixa branca so baseados na arquitetura interna do software, por isso, so
conhecidos como caixa branca. Eles identificam defeitos nas estruturas internas do programas
atravs da simulao de situaes que exercitem adequadamente todas as estruturas utilizadas na
codificao. Logo, necessrio que o testador tenha conhecimento suficiente sobre a arquitetura
interna e conhea a tecnologia utilizada no software.
O objetivo desses testes garantir que todas as linhas de cdigo e condies foram
executadas pelo menos uma vez, e esto corretas. Alguns mtodos so aplicados nos testes de
caixa branca, exemplo: Mtodo de Cobertura de Linhas de Cdigo, Mtodo de Cobertura de
Caminhos, Mtodos de Cobertura de Desvios Condicionais e Mtodo de cobertura de Laos.
Esses testes so difceis de implementar e so altamente eficientes na deteco de
problemas. Uma caracterstica desse tipo de teste que ele pode ser modelado, estruturado e
executado pelos desenvolvedores.
Estratgia caixa preta utiliza tcnicas para garantir que o software atende os requisitos do
sistema. Esses testes no verificam os processamentos internos, se a soluo adotada foi a melhor,
mas verificam se o sistema produz o resultado esperado. Ela no se preocupa com o cdigo, testa
as entradas e as sadas da aplicao.
Para adoo da estratgia de teste caixa preta no necessrio conhecer a tecnologia
utilizada nem a arquitetura do sistema. Isso facilita a modelagem dos testes. O que necessrio
o conhecimento dos requisitos, o comportamento esperado do sistema para que se possa avaliar
se o resultado produzido o correto.
Eles so conhecidos como mais simples de implementar que os de caixa branca.
3.4Tipos de Testes de Software

necessrio dividir os testes em tipos, para que seja escolhido o que deve ser testado, sua
prioridade e criticidade. Esta tarefa ajuda bastante quando gerente for preparar as sutes de teste.
ESCOLA POLITCNICA
DE PERNAMBUCO
27
Existem os testes de interface que testam a interao do usurio com o sistema verificando
o posicionamento correto dos itens da tela e a facilidade de uso do sistema. Ex.: caso seja
necessrio executar vrios cliques no mouse para desempenhar alguma funcionalidade isto deve
ser reportado para o analista em busca de minimizar muitos cliques.
O teste mais reconhecido pelo cliente o teste funcional este teste se caracteriza pela
necessidade do conhecimento do negcio do sistema para que os cenrios das regras de negcio
sejam simulados. Este teste verifica se as funcionalidades se comportam de acordo com a
documentao de especificao funcional, ou seja, se no existe diferena entre os requisitos
funcionais e o comportamento da aplicao. Valores de entrada e sada so utilizados para a
avaliao do comportamento do software. Esses testes so caracterizados pelo foco em negcios.
Outro teste que deve ter uma especial ateno so os testes de desempenho, eles verificam
se o tempo de resposta de uma determinada situao condizente com tempo especificado nos
requisitos definidos. Eles analisam o sistema sob condies reais de acesso simultneo ou de
carga de dados. As situaes de pico mximo previstas so comparadas como os valores-limite
especificados nos requisitos. J os de carga verificam se o sistema suporta a quantidade de
usurios requeridos. Ele avalia o comportamento do sistema para um volume de usurios
simultneos que simule uma quantidade real. Em geral teste de desempenho e de carga se
confundem, mas podemos dizer que o de desempenho se refere medio de tempo.
O teste de estresse parecido com os testes de carga, porm levando o sistema alm do
seu limite, ele destinado a avaliar como o software se comporta em condies anormais, testa o
aplicativo em situaes inesperadas. O teste pode envolver cargas extremas de trabalho, memria
insuficiente, hardware e servios indisponveis ou recursos compartilhados limitados.
Testes de volume do enfoque a parmetros de sobrecarga. Ao ser testada a aplicao
submetida a grandes quantidades de dados. Nesse teste o volume de dados incrementado
sucessivamente at que o limite mximo que a infra-estrutura est preparada para processar seja
atingido. O objetivo conhecer os limites do software e comparar com os requisitos
especificados.
Teste de Configurao verificam se a aplicao funciona como esperado em diferentes
ambientes de software e hardware, ou seja, o aplicativo testado em vrias configuraes de
software e hardware. Esses diferentes ambientes so os ambientes previstos na fase de elicitao
de requisitos.
ESCOLA POLITCNICA
DE PERNAMBUCO
28
Os testes de instalao tm por objetivo garantir que a instalao do sistema ocorrer
corretamente em diferentes ambientes de software e hardware e em diversas condies (falta de
energia, falta de espao em disco). Recomenda-se que este teste seja executado pelo usurio.
Teste de Integridade um tipo de teste que verifica a robustez, a resistncia falhas do
objeto do teste e a integridade dos dados armazenados.
Teste de segurana focam em encontrar falhas na segurana do sistema que podem
provocar perdas de dados, interrupes de processamento, comprometimento do sigilo e
fidelidade das informaes.
Testes de Documento focam na documentao do sistema. Os testes analisam a
completude e a clareza dos documentos.
Os ataques segurana do sistema podem ter origens internas ou externas e podem ser
realizados por profissionais descontentes, quadrilhas especializadas, hackers.
3.5Nveis de Testes
H quatro nveis de teste e sua diviso se deve pela granularidade dos componentes
testados e indivduos responsveis por eles.
O primeiro nvel a ser discutido o teste de unidade. Seu objetivo testar um pedao do
cdigo. Os testes so aplicados nos menores componentes de cdigo e testam unidades
individuais como: funes, classes, componentes. Eles podem testar a estrutura interna,
funcionalidade, segurana dos componentes. Para a realizao desses testes requerido um
conhecimento da estrutura interna do software. Geralmente esses testes so realizados por
desenvolvedores.
Outro nvel seria os testes de integrao onde so avaliadas as interaes entre partes do
software. So realizados no final de cada iterao e comprovam que duas ou mais funes,
componentes juntos funcionam corretamente. Esse teste requer um conhecimento da arquitetura
interna do software. Eles podem testar interfaces e dependncias entre componentes.
Os testes de sistema so executados no sistema como um todo e em um ambiente teste,
mas esse ambiente tem que ser muito parecido com o de produo. No necessrio
conhecimento da arquitetura interna do software. Os testes devem ser executados por uma equipe
de testes independente. Nesses testes tanto os requisitos funcionais quanto os no funcionais
podem ser testados.
ESCOLA POLITCNICA
DE PERNAMBUCO
29
Por fim temos os testes de aceitao ou homologao que so feitos pelos usurios finais.
Os testes so realizados no sistema como um todo. O usurio valida se o sistema est pronto e
pode ser usado por usurios finais, se as funes do sistema esto funcionando corretamente. A
usabilidade e a segurana do software tambm podem ser testadas.
3.6Formas de Testar
A forma de testar pode ser dividida de duas, Testes Manuais e Testes Automticos.
3.6.1 Testes Manuais

Para facilitar o entendimentos vamos dividir os testes manual em dos subgrupos, Testes
Sistemticos e Testes Exploratrios. Este ltimo o mais utilizado.
Testes sistemticos so testes predefinidos executados seguindo os passos do Projeto de
Teste. Com base em algum documento que especifique o funcionamento ideal do sistema o
projetista de teste cria o projeto de teste com todos os fluxos idias e os de exceo para serem
testados nos ciclos de execuo.
Esses testes geralmente so empregados em instituies que seguem um processo de teste
e possuem uma equipe de testes independente. Esses testes so recomendveis para projetos
aderentes a um processo de desenvolvimento, que apresentao documentao de qualidade, alm
de tempo e recurso disponveis. Esses testes verificam formalmente se o sistema est de acordo
com a sua especificao, permitem identificar as dependncias entre os testes atravs da matriz de
rastreabilidade. Nesse tipo de teste as atividades acontecem em paralelo com as atividades de
desenvolvimento. Outras caractersticas desses testes so: elaborados por pessoas que possuem o
perfil de testador, alta cobertura dos testes e so facilmente reproduzidos. Qualquer pessoa que
for testar o produto usando testes sistemticos vai executar os mesmos testes e da mesma forma,
uma vez que o passo a passo para execuo dos testes est documentado.
Os testes exploratrios so testes onde o testador executa e projeta o teste ao mesmo
tempo. Nem sempre utilizando documentao especifica. Os casos de teste so criados no
momento da execuo. Na maioria das vezes eles so criados de maneira intuitiva. Poucos casos
de testes so executados.
Os testes exploratrios ajudam muito quando o projeto no contm documentao
especifica do sistema ou de baixa qualidade ou desatualizada. Essa tcnica traz resultados
rpido, sendo assim, indicada quando o prazo curto, o requisito no critico ou muito simples.
ESCOLA POLITCNICA
DE PERNAMBUCO
30
Para que os testes exploratrios sejam eficientes necessrio a utilizao de um pequeno
processo de teste especifico para testes exploratrios.
Estudar a documentao do sistema e problemas de sistemas similares ajuda na deteco
de falhas. Toda informao do sistema serve para ganho de conhecimento e de elaborao de caso
de teste, logo um treinamento ministrado pelo lder do projeto pode esclarecer possveis dvidas.
aconselhvel a execuo do fluxo bsico da funcionalidade e a interao entre os
requisitos.
3.6.2 Testes Automticos

Testes automticos tem tm por objetivo executar casos de teste de forma automtica. Sua
principal vantagem a execuo de vrios casos de teste sem a necessidade da presena de uma
pessoa monitorando o processo.
Essa automao inclui a automao do processo de planejamento dos testes, permite
aumentar a profundidade e abrangncia dos casos de testes envolvidos, viabiliza a execuo de
alguns tipos de testes, como o caso dos testes de carga e estresse. Porm, os projetos de
automao de teste devem ser implementados com muito cuidado. A seleo da ferramenta de
automao de teste, bem como o que dever ser automatizado ou no, devem ser analisados
analisada de forma clara porque dependendo das tcnicas de teste utilizadas, o retorno de
investimento pode ser negativo ou positivo.
A automao s deve ser realizada quando existe um processo maduro na organizao e
na equipe de testes, conscientizao por parte da organizao e os testes levam muito tempo para
serem executados manualmente.
3.7Conceito V de testes
comum pressupor que testes so realizados em todo o processo de desenvolvimento. O
ciclo de vida de testes e o de desenvolvimento so totalmente interdependentes, sendo que o ciclo
de testes dependente da concluso dos produtos das atividades do ciclo de desenvolvimento. A
aplicao destes ciclos de vida e das suas interdependncias, na ordem de execuo das suas
atividades, gerando os produtos previstos um pr-requisito para viabilizar o processo de
desenvolvimento de software.
A experincia tem demonstrado que no foram alcanados bons resultados quando os
testes so feitos pelas pessoas do prprio grupo de desenvolvimento de um projeto, uma vez que
ESCOLA POLITCNICA
DE PERNAMBUCO
31
muito difcil fazer estas pessoas atuarem ao mesmo tempo como desenvolvedores e testadores,
de forma independente isenta e adotando metodologias diferentes para cada funo. Foi
constatado que os desenvolvedores tendem a encobrir os seus prprios enganos de forma que a
eficcia dos testes vai depender da capacidade destas pessoas de atuar com estas duas
metodologias de forma isenta e independente.
O conceito de ciclo de vida de testes ilustrado na Figura 42.3. A figura mostra que os
processos de desenvolvimento e testes iniciam simultaneamente. A equipe que desenvolve o
sistema inicia o processo de desenvolvimento do sistema e a equipe que est conduzindo os testes
comea o planejamento do processo de testes. Ambas as equipes comeam no mesmo ponto usam
as mesmas informaes. A equipe de desenvolvimento tem a responsabilidade de capturar e
documentar os requisitos para os propsitos do desenvolvimento do sistema e a equipe de testes
usa os mesmo requisitos para os propsitos de testar o sistema. Em apropriados pontos do
processo de desenvolvimento, a equipe de testes utilizar as tcnicas de testes, como base para
avaliar os produtos do processo de desenvolvimento com o objetivo de descobrir defeitos.
No conceito V de testes, os procedimentos de fazer e chegar convergem do inicio at o
fim do projeto. O grupo que EXECUTA, trabalha com o objetivo de implementar o sistema e a
equipe que CHECA, simultaneamente, executa procedimentos de testes visando minimizar ou
eliminar riscos. Com esse enfoque, se os grupos trabalharem juntos e de forma integrada, o alto
nvel de riscos que caracteriza os projetos de desenvolvimento de software, ir decrescer a um
nvel aceitvel que permita a concluso do projeto com sucesso.
Incio da Incio dos Testes

Implementao
Verificao
Validao
Correes
Completadas
Figura 42.3: O conceito V de testes de software

ESCOLA POLITCNICA
DE PERNAMBUCO
32
3.8Processo tradicional de teste
O processo de teste de software tradicional segue o conceito V mencionado na seo
anterior e apresentado de forma mais detalhada na Figura 52.4. A parte esquerda do V
representa o ciclo de desenvolvimento de software e a parte da direita, alguns dos passos do
processo de teste de software.
Os primeiros cinco passos usam a tcnica de verificao como o principal meio para
avaliar a correo dos produtos do desenvolvimento de software. Por outro lado. A tcnica de
validao usada para testar o software durante as atividades de construo a implantao. Os
resultados de ambos devem ser registrados na documentao dos testes. Validao e verificao
devem ser usados usadas para desenvolvimento e manuteno de software.
1) Acesso ao Plano de Desenvolvimento pr- requisito para a construo do Plano
de Testes. Durante esse passo, os testadores verificaro a completeza e correo do
plano de desenvolvimento. Baseado neste plano ser possvel estimar a quantidade
de recursos necessrios para testar a soluo a ser implementada.
2) Desenvolvimento do Plano de Testes A preparao do Plano de Testes segue os
mesmo padres da preparao do plano de desenvolvimento. A estrutura dos
planos a mesma, mas o contedo ir variar em funo do grau de risco associado
com o software que est sendo desenvolvido.
3) Inspeo ou Teste dos Requisitos do Software Avaliao dos requisitos do
software atravs da tcnica de verificao. Requisitos incompletos, inexatos ou
inconsistentes conduzem a insucesso da maioria do desenvolvimento de software.
4) Inspeo ou Teste do Desenho do Software Avaliao do desenho do software
(interno e externo) atravs da tcnica de verificao. Os testadores estaro
interessados em verificar se o desenho atinge os objetivos dos requisitos, bem
como se eficaz e eficiente para operar no hardware previsto.
5) Inspeo ou Teste da Construo do Software O mtodo para construir o
software a partir do desenho do sistema determinar o tipo e a extenso dos testes
que sero necessrios. Quanto mais a construo se tornar automatizada, menos
testes sero requeridos durante esta fase.
6) Execuo dos testes Envolve testar o cdigo em estado dinmico. A abordagem,
mtodos e ferramentas que foram especificadas no Plano de Testes sero usadas
ESCOLA POLITCNICA
DE PERNAMBUCO
33
pra validar o atendimento dos cdigos executveis aos requisitos do software as
suas especificaes do desenho.
7) Teste de Aceitao Avaliao da aplicabilidade e usabilidade do software pelo
usurio. Alm dos requisitos documentados, os usurios geralmente testam outras
funes no documentadas e as suas expectativas.
8) Informao dos Resultados dos Testes Informao sobre os testes um processo
contnuo. importante que os defeitos sejam informados aos setores envolvidos o
mais rpido possvel, de foram que as correes sejam feitas com o menor custo
possvel.
9) Teste da Instalao do Software Visam verificar a interoperabilidade com o
sistema operacional, com outros softwares relacionados e com os procedimentos
operacionais.
10) Teste das Mudanas no Software Embora as atividades sejam consideradas como
o passo 10, estas cobrem as mudanas durante o processo de implementao e
aquelas que iro ocorrer aps o software estar implantado.
11) Avaliao da Eficcia dos Testes As melhorias no processo de testes podem ser
melhor verificadas pela avaliao da eficcia dos testes ao trmino de um projeto.
ESCOLA POLITCNICA
DE PERNAMBUCO
34
DEFINIO DOS PASSO 1

REQUISITOS DO Acesso ao Plano de
Desenvolv. e Situao
SOFTWARE
PASSO 2
Desenvolvimento
do Plano de Testes
PASSO 3
CONSTRUO Testes dos
DO SOFTWARE Requerimentos do
Software
PASSO 4
Tete do Desenho do
Software
PASSO 5
INSTALAO DO Teste da Construo
SOFTWARE do Software
PASSO 6
Execuo e Registro
dos Testes
PASSO 7
Teste de Aceitao
OPERAO E
MANUTENO
DO SOFTWARE PASSO 8
Informao dos
Resultados dos Testes
PASSO 9
Instalao do
Software
PASSO 10
Teste das
MudnasMudanas
do Software
PASSO 11
Avaliao da
Eficcia dos Testes
Figura 52.4: 11 passos do Processo de Teste de Software

ESCOLA POLITCNICA
DE PERNAMBUCO
35
3.9Vale a pena ao final de cada captulo colocar uma
seo de Resumo do Captulo onde voc vai
mencionar o principal objetivo do captulo
finalizado.Resumo do Captulo
Este captulo explanou o tema testes de software objetivando introduzir o leitor aos
principais conceitos de teste. Apresentamos alm dos conceitos, caractersticas, tipos e
estratgias, formas de teste e o conceito V de teste assim como a forma tradicional de testar.
ESCOLA POLITCNICA
DE PERNAMBUCO
36
Captulo
Metodologias de Desenvolvimento de
Software
A inspirao comum para a maioria das metodologias so as reas da Engenharia Civil e/ou
Mecnica. Tais reas enfatizam o planejamento antes da construo. Engenheiros destas reas
trabalharo em uma srie de desenhos que indicam precisamente o que precisa ser construdo e
como todas as coisas devem se encaixar. Muitas das decises so tomadas antes do incio da
execuo. Um exemplo prtico que a deciso da forma com que o peso ira ser distribudo ao
passar um veculo em alta velocidade em uma ponte feita medida que os desenhos so
produzidos.
Previsibilidade uma propriedade muito desejvel. Entretanto, quando acreditamos que
podemos ser previsveis quando na verdade no podemos, leva a situaes de perda de controle
nas situao onde o plano falha. Voc v a realidade lentamente distanciando-se do plano. Por
muito tempo, voc pode fingir que o plano ainda vlido. Mas em algum ponto, o distanciamento
fica muito grande e o plano simplesmente cai em pedaos.
ESCOLA POLITCNICA
DE PERNAMBUCO
37
Ento, como controlamos um mundo imprevisvel? O mais importante, e ainda mais
difcil, saber com preciso onde estamos. Precisamos de um mecanismo honesto de feedback
que possa dizer-nos com preciso qual a situao em intervalos freqentes.
A chave para este feedback o desenvolvimento iterativo. Esta no uma idia nova.
Desenvolvimento iterativo j existe por algum tempo sob vrios nomes diferentes: incremental,
evolucionrio, em estgios, espiral. A chave para o desenvolvimento iterativo freqentemente
produzir verses que funcionam do sistema final, que contm um subconjunto dos recursos
requeridos. Estas verses so bastante limitadas em funcionalidade, mas devem ser fiis s
demandas do sistema final. Elas devem ser totalmente integradas e cuidadosamente testadas
como se fossem a entrega final.
O ponto que no existe nada como um sistema testado e integrado para trazer uma dose
de realidade a qualquer projeto. Documentos podem esconder todo tipo de falhas. Cdigo-fonte
no-testado pode esconder muitas falhas. Mas quando as pessoas sentam em frente a um sistema
e trabalham com ele, as falhas se tornam verdadeiramente aparentes: tanto em termos de defeitos
como em termos de requisitos mal-interpretados.
Desenvolvimento iterativo faz sentido em processos previsveis tambm. Mas essencial
em processos flexveis, pois um processo flexvel precisa ser capaz de lidar com mudanas nas
funcionalidades requisitadas. Isso leva a um estilo de planejamento onde os planos de longo
prazo so bastante fluidos, e os nicos planos estveis so os de curto prazo, feitos para uma
nica iterao. O desenvolvimento iterativo lhe d uma fundao firme em cada iterao onde
voc pode basear seus planos futuros.
Uma pergunta comum o quo longa uma iterao deve ser e qual o tamanho ideal para
cada iterao. Pessoas diferentes daro respostas diferentes. eXtreme Programming (XP) sugere
interaes entre uma e trs semanas. SCRUM sugere a durao de um ms. Em Crystal, vai ser
maior. A tendncia, entretanto, fazer cada iterao o to curta quanto possvel. Isso prov
feedback mais freqente, para que voc possa saber com mais freqncia onde est.
4.1Pessoas versus Processo

Executar um processo flexvel no fcil. Particularmente, exige uma equipe bastante
eficaz de desenvolvedores. A equipe precisa ser efetiva tanto na qualidade de seus indivduos,
quanto em como essa equipe interage como um time de verdade. Existe tambm uma sinergia
ESCOLA POLITCNICA
DE PERNAMBUCO
38
importante: no apenas a adaptatividade requer uma equipe mais forte, mas tambm a maioria
dos bons desenvolvedores prefere um processo adaptativo.
Um dos objetivos das metodologias tradicionais desenvolver um processo onde as
pessoas envolvidas so partes substituveis. Com tais processos, voc pode tratar pessoas como
recursos que esto disponveis de vrias formas. Voc tem um analista, alguns programadores,
alguns especialistas em testes, um gerente. Os indivduos no so to importantes, somente suas
funes. Desta forma se voc planeja um projeto, no importa qual analista ou quais especialistas
em testes voc vai ter, apenas que voc saiba quantos deles voc ter, para saber o quanto o
nmero de recursos afetar seu planejamento.
Mais isso levanta uma questo-chave: as pessoas envolvidas em um desenvolvimento de
software so peas substituveis? Uma das principais caractersticas das metodologias geis que
elas rejeitam tal premissa.
4.2XP - eXtreme Programming

As razes do XP esto na comunidade Smalltalk, e em particular na colaborao estreita
entre Kent Beck e Ward Cunningham no final da dcada de 1980. Ambos refinaram suas prticas
em diversos projetos durante a dcada de 90, estendendo suas idias para uma abordagem do
desenvolvimento de software que fosse tanto adaptativa, quanto orientada a pessoas.
O passo crucial para a passagem da prtica informal para metodologia ocorreu na
primavera de 1996. Kent foi chamado para revisar o progresso no projeto C3, o controle de folha
de pagamento da Chrysler. O projeto estava sendo desenvolvido em Smalltalk por uma empresa
terceirizada, e estava em problemas. Devido baixa qualidade do cdigo, Kent recomendou jogar
tudo fora e reiniciar do zero. O projeto ento foi reiniciado sob sua liderana e, desde ento, se
tornou a bandeira e o campo de treinamento para o XP.
A primeira fase do C3 foi muito bem-sucedida e este entrou em produo no incio de
1997. O projeto continuou desde ento e entrou em dificuldades posteriormente, o que resultou
no cancelamento de qualquer desenvolvimento adicional em 1999
XP comea com quatro valores: comunicao, feedback, simplicidade e coragem. Depois
disso, so construdas 12 prticas que os projetos XP devem seguir. Muitas dessas prticas so
tcnicas antigas e testadas, entretanto muitas vezes esquecidas por muitos - inclusive pela maioria
dos processos planejados. Alm de ressuscitar essas tcnicas, XP as tem como um todo sinrgico,
onde cada tcnica refora as outras.
ESCOLA POLITCNICA
DE PERNAMBUCO
39
Uma das tcnicas mais notveis, pelo menos inicialmente atraente para mim, a forte
nfase nos testes. Enquanto todos os processos mencionam a verificao atravs de testes, a
maioria a faz de forma pouco enftica. Entretanto, XP a coloca na base do desenvolvimento, com
cada programador escrevendo testes medida que escrevem cdigo de produo. Os testes so
integrados em um processo de integrao contnua e construo (build), o que leva a uma
plataforma altamente estvel para desenvolvimento futuro.
XP desenvolveu uma liderana muito ampla, alguns destes lderes provenientes do projeto
C3 original. Como resultado, existem muitas fontes para mais informaes. Kent Beck escreveu
Extreme Programming Explained, o manifesto-chave para XP, que explica todo o raciocnio por
trs da metodologia e contm explicaes suficientes para que as pessoas saibam se esto
interessadas em seguir adiante. Nos ltimos anos houve um crescimento epidmico de livros de
XP, vrios deles muito similares, no sentido que descrevem todo o processo do ponto de vista dos
vrios pioneiros na adoo do XP.
4.3Scrum
Scrum divide um projeto em iteraes (chamadas de sprints) de 30 dias. Antes de iniciar
um sprint, voc define a funcionalidade requerida para o sprint e ento deixa a cargo do time para
implementar tais funcionalidades. O ponto estabilizar os requisitos durante o sprint.
Entretanto, a administrao no perde o envolvimento durante o sprint. Todo dia, a equipe
tem uma pequena reunio (15 minutos), chamada de scrum, onde ela passa por tudo que vai fazer
no prximo dia. Em particular, eles fazem transparecer os impedimentos administrativos:
impedimentos que dificultam o avano, e que a gerncia precisa resolver. Eles tambm reportam
o que est sendo feito para que a gerncia tenha uma atualizao diria sobre em que ponto o
projeto se encontra.
A literatura sobre Scrum foca principalmente no planejamento iterativo e em processos de
acompanhamento. muito parecida com outras metodologias geis em diversos aspectos, e deve
funcionar bem com as prticas de programao do XP.
ESCOLA POLITCNICA
DE PERNAMBUCO
40
4.4O Manifesto para Desenvolvimento gil de
Software
Com tantas similaridades entre essas metodologias, houve um razovel interesse em
alguma forma de trabalho coletivo. Dessa forma, os representantes de cada uma dessas
metodologias foram convidados para um workshop de dois dias em Snowbird, Utah em fevereiro
de 2001.
O resultado o Manifesto para Desenvolvimento gil de Software, uma declarao de
valores comuns e princpios de processos geis. H tambm um desejo de colaborar ainda mais
no futuro, para encorajar no somente tecnlogos, mas tambm pessoas de negcios para usar e
requerer abordagens geis para o desenvolvimento de software.
O manifesto era apenas isso, uma publicao que agia como um ponto de partida para
aqueles que compartilhavam as mesmas idias bsicas. Um dos frutos deste esforo foi a criao
de uma entidade mais permanente, a Aliana gil. A Aliana gil uma organizao sem fins
lucrativos que procura promover o conhecimento e discusso sobre todas as metodologias geis.
Muitos dos lderes do movimento gil que mencionei, so tambm membros da Aliana gil.
4.5RUP Rational Unified Process

O Rational Unified Process (RUP) foi desenvolvido por Philippe Kruchten, Ivar Jacobson
como o complemento de processo ao UML. RUP uma plataforma processual, e como tal pode
acomodar uma vasta variedade de processos. De fato, essa minha principal crtica ao RUP -
algo que pode ser tudo acaba no sendo nada. Eu prefiro um processo que lhe diga o que fazer ao
invs de um que lhe oferea opes interminveis.
Como resultado dessa mentalidade de plataforma processual, RUP pode ser usado em uma
maneira bastante tradicional, como desenvolvimento em cascata, ou tambm de forma gil. Logo,
como resultado voc pode usar RUP como um processo gil ou como um processo tradicional -
tudo depende de como voc o adapta para seu ambiente.
Craig Larman um forte defensor de se utilizar RUP de maneira gil. Seu excelente livro
introdutrio sobre desenvolvimento orientado a objetos contm um processo bastante
fundamentado em seu pensamento RUP. Sua viso que muito da corrente atual a favor das
metodologias geis nada mais que o aceite do desenvolvimento orientado a objetos, que j foi
capturado no RUP. Uma das coisas que Craig faz investir os primeiros dois ou trs dias de uma
ESCOLA POLITCNICA
DE PERNAMBUCO
41
iterao de um ms com todo o time, usando UML para esboar o trabalho a ser feito durante a
iterao. Isso no um plano de projeto que no pode ser desviado, mas sim um esboo que d
perspectiva s pessoas de como fazer as coisas durante a iterao.
Outra abordagem ao RUP gil o processo dX, de Robert Martin. O processo dX uma
instncia totalmente conforme com RUP, que simplesmente idntica ao XP (vire dX de ponta-
cabea para entender a brincadeira). dX foi projetada para pessoas que tem que usar RUP, mas
gostariam de estar usando XP. Como tal, tanto XP como RUP e, portanto, um bom exemplo de
um uso gil do RUP.
4.6Resumo do Captulo
Este captulo abordou o tema de metodologias de desenvolvimento de software. Uma
introduo geral apresentada e em seguida alguns metodologias e suas caractersticas.
Faa a mesma coisa aqui coloque uma seo de Resumo do Captulo.
ESCOLA POLITCNICA
DE PERNAMBUCO
42
Captulo
O Processo gil de Teste - PAT
Acreditamos que um processo de teste bem definido e eficiente unido a uma equipe de
teste independente so fundamentais para garantir a qualidade do produto e encontrar os erros
antes que o software entre em produo. O objetivo de um processo de testes com metodologia
prpria minimizar os riscos causados por defeitos provenientes do processo de desenvolvimento
[1].
Infelizmente, muitas organizaes no possuem um processo de teste bem definido e
eficiente, sendo as atividades de teste informais, sem uma metodologia e responsabilidades
definidas. Na maior parte das vezes essas atividades so realizadas de maneira ad-hoc. Embora
saibamos da importncia da atividade de testes, muitas empresas do ramo optam por no realiz-
las pois observam a atividade como entediante e consumidora de tempo. Desta forma, somente
focam na atividade aps o incio da produo do software quando comeam a surgir os mais
variados erros.
importante salientar que uma metodologia gil prev teste em software, porm em um
nvel diferente do proposto neste trabalho. Metodologias geis, em sua maioria, executam testes
do tipo caixa branca com viso do cdigo fonte, como testes unitrios, que so executados pela
ESCOLA POLITCNICA
DE PERNAMBUCO
43
equipe de desenvolvimento e no por uma equipe independente de teste. A utilizao desta
tcnica diminui a quantidade de erros em software, mas no os elimina. A utilizao de Testes do
tipo caixa preta executados por uma equipe especializada na deteco de erros complementa as
tcnicas de deteco de erro da equipe de desenvolvimento.
Para auxiliar na modelagem do processo usamos o SPEM (Software Process Engineering
Metamodel).
5.1SPEM - Software Process Engineering Metamodel

O SPEM um metamodelo proposto pela OMG Object Management Group para a descrio de
um processo de software ou uma famlia relacionada de processos. Diferente da maioria das
Linguagens de Modelagem de Processos (PML- Process Modeling Language) o SPEM surge
como uma proposta de unificao entre as diferentes metodologias propostas para modelagem de
processos. O SPEM utiliza a orientao a objeto para modelar uma famlia relacionada de
processos de software e usa a Unified Modeling Language (UML) como notao. A Figura 4.1
mostra as quatro arquiteturas de modelagem definidas pelo OMG.
Figura 4.1: Nveis de modelagem definidos pela OMG
O SPEM encontra-se no nvel M2 da arquitetura de quatro camadas da OMG e seu

metamodelo definido usando um subconjunto da UML de modo semelhante da UML. Este
subconjunto da UML corresponde s facilidades implementadas e apoiadas pelo MOF. Pela
proposta do SPEM um processo executado aquele, na produo no mundo real ou como o
processo ordenado, sendo nivelado no nvel M0. A definio do processo correspondente est
ESCOLA POLITCNICA
DE PERNAMBUCO
44
nivelada em M1. O SPEM pode ser usado para definir todos os tipos de processos, incluindo os
que estejam focalizados no uso especfico da UML. Instncias para orientar subclasses para
descrever prticas com a UML podem ser criadas com ferramentas para um processo UML
especfico. A UML definida por um metamodelo, que definido como uma instncia do
metamodelo MOF. Um subconjunto da notao grfica da UML usado para descrever este
metamodelo. O metamodelo SPEM foi elaborado similarmente, e formalmente definido como
uma extenso de um subconjunto da UML chamado SPEM-Foundation.
5.1.1 Principais Elementos de Definio do Processo

Os elementos de definio do processo ajudam na demonstrao de como o processo ser
executado. Descrevem ou restringem o comportamento geral do processo em execuo, e so
utilizados para auxiliar o planejamento, a execuo e o monitoramento do processo. So
divididos em trs grandes grupos: Pacote da Estrutura do Processo, Pacote dos Componentes do
Processo e Pacote do Ciclo de Vida do Processo.
Um Process pode ser visto como uma colaborao entre papis para alcanar um objetivo.
Para guiar sua execuo, determina-se a ordem na qual as atividades devem ser executadas.
Tambm existe a necessidade de definir o modelo do processo no tempo, utilizando-se para isso a
estrutura Lifecycle em termos de fases e iteraes. Um Process um ProcessComponent que
pode ser apresentado como um processo completo.
Um ProcessComponent elemento de convenincia de descries do processo que
consistente internamente e pode ser reutilizado com outros ProcessComponents para montar um
processo completo.
Um ProcessComponent importa um grupo no arbitrrio de elementos de definio de
processo, modelados no SPEM pelo ModelElements.
Um Lifecycle de processo definido como uma seqncia de fases que alcanam uma
meta especfica, definindo o comportamento completo de um processo que ser executado em um
dado projeto ou programa.
Um Workdefinition um tipo de Operation que descreve o trabalho executado no
processo. Suas subclasses so Activity, Phase, Iteration, e Lifecycle. Um WorkDefinition pode ser
composto de outros WorkDefinitions, estando diretamente relacionados aos WorkProducts que so
usados atravs da classe ActivityParameter, especificando se so usados como entrada ou como
sada dos elementos de trabalho.
ESCOLA POLITCNICA
DE PERNAMBUCO
45
O ProcessPerformer representa de forma abstrata o processo inteiro ou um de seus
componentes, e usado para WorkDefinitions prprias que no tm mais um proprietrio
especifico.
O ProcessPerformer tem uma subclasse, ProcessRole. Um ProcessRole define
responsabilidades sobre WorkProducts especficos, e sobre os papis que executam e auxiliam em
atividades especficas. Um ProcessPerformer o executor de WorkDefinitions agregadas de alto
nvel que no podem ser associadas com ProcessRoles individuais.
A cada WorkDefinition pode ser associada uma Precondition e uma Goal. As
Preconditions e Goals so Constraints, onde a Constraint expressa na forma de uma expresso
booleana seguindo sintaxe semelhante quela de uma condio de proteo na UML. A condio
expressa em termos dos estados dos WorkProducts que so os parmetros da WorkDefinition ou
de uma WorkDefinition inclusa.
Uma Activity a subclasse principal da WorkDefinition. Ela descreve uma parte do
trabalho executado por um ProcessRole: as tarefas, operaes, e aes que so executadas por um
papel ou com a qual o papel pode auxiliar. Uma atividade pode consistir de elementos atmicos
chamados Steps. Uma Activity podendo fazer uso dos ProcessRoles adicionais que so os
assistentes na Activity.
Alguns dos elementos do SPEM podem ser representados graficamente atravs de cones
outros existem como metainformao e no possuem representao grfica. Onde est a chamada
desta tabela no texto?
Tabela 14.1: Representao grfica dos principais elementos do SPEM

Esteretipo Representao
WorkProduct
WorkDefinition
Guidance
Activity
ProcessRole
ProcessPackage
Process
ESCOLA POLITCNICA
DE PERNAMBUCO
46
Document
UMLModel
ESCOLA POLITCNICA
DE PERNAMBUCO
47
5.2Definio de PAT
O PAT um processo desenvolvido para suprir uma necessidade do mercado. Ao iniciar
uma equipe independente de teste a empresa observa poucas opes para ter retornos positivos
rpidos. Isto acontece pelo fato da equipe ter a necessidade de colher dados para a gerao de
informao provando assim a necessidade do seu trabalho.
Propomos neste trabalho uma equipe de teste independente e eficiente, onde os valores do
sucesso no esto apenas no processo, mas tambm se encontram nas pessoas. A homogeneizao
da informao uma premissa deste processo.
Teste em par ideal para deixar a equipe de teste mais homognea em se tratando do
conhecimento do sistema. Esse tipo de teste foi baseado em uma das prticas de XP, a
programao em par. Os testes em par consistem na execuo do teste por dois testadores que
utilizam o mesmo computador. Como em XP, os pares no so fixos e podem mudar ao longo do
dia, essas mudanas so importantes para a disseminao do conhecimento. Os testes em par
contribuem para um espao de aprendizado contnuo dentro da equipe. Os mais experientes ou
quem tem mais conhecimento sobre um assunto termina passando informaes valiosas para seus
pares. Essa prtica procura potencializar o que existe de melhor em cada um e eliminar as falhas.
A idia que enquanto um testador executa o teste o outro presta ateno, faz perguntas,
sugere idias, toma nota, etc. Essa prtica pressupe uma comunicao contnua entre os
testadores que forma o par. Atravs da conversa eles analisam cenrios, discutem as melhores
alternativas.
Esse tipo de prtica ajuda o testador a se manter focado no teste. No necessrio
interrupes para se tomar nota, tirar dvidas, consultar manual ou documentao, replicar o erro
em outra mquina. Essas atividades podem ser realizadas pelo outro testador. Ela tambm
melhora a reportagem dos erros, pois facilita a reproduo e tudo que reportado revisado por
outra pessoa. Como o conhecimento transmitido de uma forma prtica, esta prtica um bom
treinamento para novatos. necessrio observar que um esforo maior deve ser estimado nesta
prtica j que duas pessoas esto alocadas em uma atividade. Existe pelo menos um
conhecimento tcnico e um conhecimento sobre as informaes do projeto. Testes em par
permitem que algum que acabou de entrar na equipe conhea rapidamente o sistema, pois o
conhecimento transmitido pelo parceiro medida que a atividade executada.
ESCOLA POLITCNICA
DE PERNAMBUCO
48
O A prtica de teste em par pode ser desenvolvida tendo como participantes um testador e
uma pessoa com conhecimento profundo do sistema, o lder do projeto por exemplo. Duas
pessoas com focos to diferentes tendem a somar qualidades no final do processo. Enquanto o
foco de um est em mostrar como a funcionalidade deve se comportar a do outro busca falhas e
caminhos alternativos. Esta prtica ajuda tanto no processo de teste como no processo de
desenvolvimento. Testadores absorvem a forma de pensar dos desenvolvedores e os
desenvolvedores absorvem a forma de pensar dos testadores, ocorrendo assim maior cuidado no
desenvolvimento das funcionalidades tendo o objetivo no apenas nos fluxos principais, mas
tambm nos fluxos alternativos e de exceo que podem levar a erros no sistema.
Outra forma de facilitar a execuo dos testes e de certa forma padronizar os testes que
so executados por diversos testadores a adoo de uma planilha de testes genricos. Nessa
planilha existir a maior parte dos cenrios de testes que podem ser executados por uma
determinada funcionalidade, campo para indicar se o cenrio passou ou falhou campos para os
registros abertos. Tambm importante ter informaes do sistema como: verso, funcionalidade,
executor, data de execuo, tempo total gasto, registros aberto s. Alm dos nmeros de registros
passados, falhos e bloqueados. Guardar essas informaes torna-se importante na execuo de
reteste, na gerao de relatrios e na deteco da localizao de falhas na execuo dos testes.
Documentar o erro encontrado e essencial para ajudar em regresses futuras e para
garantir que o erro no ocorre mais nas prximas verses.
5.3Composio
Em toda equipe organizada, existe uma diviso de tarefas entre os membros. Um papel
constitui um conjunto de responsabilidades que determina qual ser o comportamento de uma
pessoa em algum momento do processo. No PAT, recomenda-se a presena de sete papis:
Gerente de Teste, Lder de Teste, Gerente de Projeto, Lder de Projeto, Projetista de Teste,
Executor de Teste e Desenvolvedor.
A alocao dos papis deve ser feita de acordo com as necessidades e escopo do projeto,
levando-se em conta as habilidades e caractersticas de personalidade das pessoas envolvidas no
processo. A equipe de teste deve ser estruturada de forma a se obter a maior produtividade
possvel.
ESCOLA POLITCNICA
DE PERNAMBUCO
49
essencial que todos os papis estejam presentes na equipe, pois caso contrrio pode
ocorrer que algumas etapas importantes do processo sejam esquecidas ou no recebam a ateno
necessria.
Um papel no corresponde necessariamente a uma pessoa da equipe, ou seja, uma mesma
pessoa pode desempenhar vrios papis simultaneamente. A palavra mais importante da sigla PAT
talvez seja a palavra gil. Um indivduo que exerce o papel de projetista em um determinado
projeto, pode ser executor e lder em outro. Vrias combinaes so possveis. Tendo apenas o
cuidado de no haver sobrecarga de responsabilidades de algum membro da equipe.
5.3.1 Papis
Gerente de Projeto o responsvel por coordenar as atividades da equipe de

desenvolvimento. O gerente deve ser capaz de gerenciar o desenvolvimento e tomar decises
referentes aos riscos e rumos do projeto. Em relao ao PAT as principais competncias do
gerente so:
Conduzir os planejamentos e as aes dos desenvolvedores O gerente deve
garantir que os desenvolvedores estejam executando corretamente suas atividades,
e no tempo estabelecido, para assegurar o bom andamento do projeto.
Tornar a documentao do projeto sempre atualizada e acessvel - A documentao
do projeto deve estar disponvel e atualizada para que possa ser consultada a
qualquer momento pela equipe de teste.
Priorizar as funcionalidades Deve especificar quais partes do sistema so de
maior urgncia.
Lder de Projeto o responsvel pela interface da equipe de desenvolvimento com a

equipe de teste. Ele coordena a equipe de desenvolvimento, atualiza o cronograma e mantm o
Gerente informado do status do projeto. As principais responsabilidades do lder do projeto so:
Ajudar a coordenar a equipe de desenvolvimento O lder de projeto deve ajudar
na elaborao da estratgia de desenvolvimento.
Alertar o gerente sobre possveis desvios no cronograma Manter o gerente do
projeto ciente do andamento do processo de desenvolvimento, sugerindo solues
para possveis desvios.
ESCOLA POLITCNICA
DE PERNAMBUCO
50
Monitorar e ajudar na montagem do ambiente disponvel para teste o lder deve
ter o conhecimento necessrio para ajudar a equipe de infra a preparar o ambiente,
quando necessrio ou montar de fato o ambiente para teste quando no existe a
necessidade da equipe de infra.
Manter o lder de teste informado do andamento da execuo muito importante
o lder de teste estar devidamente informado do andamento do desenvolvimento de
de possveis desvios.
Lder de Teste o responsvel pela interface da equipe de teste com a equipe de
desenvolvimento. Muitas vezes, na execuo de teste do sistema, surgem dvidas e a pessoa
responsvel por eliminar as dvidas dos desenvolvedores o lder de teste. As principais
responsabilidades do lder de teste so:
Ajudar a elaborar o plano de teste ajuda o gerente de teste a elaborar o plano de
teste. Sendo o especialista no sistema na equipe de teste. O lder de teste deve
responder as dvidas da equipe de teste sobre o sistema, no sabendo responde-la
ele ser o encarregado de procurar as respostas com a equipe de desenvolvimento.
Manter equipe informada sobre desenvolvimento alteraes no cronograma e
possveis atrasos no ambiente para teste deve ser reportado a equipe.
Elaborar a estratgia de teste o lder o responsvel pela estratgia de teste. Ele
aloca e coordena os recursos para desenpenhardesempenhar determinado papel.
Contactar equipe de desenvolvimento quando necessrio quando um testador ou
projetista necessita de ajuda na execuo de sua tarefa seja por falta de informao
ou por problemas no ambiente, o lder o encarregado de analisar e procurar
solues para aquele problema.
Ajudar na gerao de relatrios o lder tem a responsabilidade de coletar dados
para o gerente quando solicitado.
Gerente de Teste o papel do gerente de teste gerenciar as sutes de teste a ser
realizado no produto. As principais responsabilidades do gerente de teste so:
Elaborar plano de teste o gerente o principal responsvel pela elaborao do
plano de teste. De posse deste artefato o lder de teste prepara a estratgia de teste
para sua equipe.
ESCOLA POLITCNICA
DE PERNAMBUCO
51
Monitorar a equipe de teste O gerente tem o papel de monitorar o andamento das
execues, no deixando margens para que nenhum recurso fiar ocioso nem
sobrecarregado.
Coletar e analisar mtricas As mtricas so informaes que permitem a anlise
do andamento do projeto pelo gerente. O gerente deve coletar mtricas
periodicamente junto ao lder e utiliz-las para melhorar o processo.
Presidir as reunies de acompanhamento dos projetos O gerente deve realizar
semanalmente reunies de acompanhamento com a equipe, onde deve garantir que
a equipe seja tenha um conhecimento macro mnimo de todos os projetos, para que
o custo de uma mudana de papeis e projetos no seja alto.
Desenvolvedor o papel do desenvolvedor consiste em criar scripts de testes para os
casos de teste verificando a existncia de falhas em seu cdigo e na sua correo. As principais
responsabilidades do desenvolvedor so:
Auxiliar o lder de teste na elaborao da estratgia de teste O desenvolvedor
deve participar da elaborao da estratgia de teste para identificar possveis
dificuldades na automao de algum requisito do ciclo.
Analisar e modelar o caso de teste - O desenvolvedor deve analisar o caso de
teste a ser implementado e model-lo da melhor forma possvel. Modularizando
comportamentos distintos e evitando retrabalhos.
Manter a integrao contnua de cdigo Em projetos onde h mais de um
desenvolvedor necessrio que o cdigo gerado por cada um seja integrado com o
cdigo produzido pelos demais, para identificar eventuais conflitos. Esta
integrao deve ocorrer de forma contnua para evitar a perpetuao de conflitos
entre partes do software at etapas posteriores, onde estes conflitos sero mais
difceis de serem resolvidos.
Projetista de teste o papel do projetista de analisar a documentao e construir o
projeto de teste. Artefato necessrio para a execuo dos testes. No projeto de teste esto contidos
os casos de testes que cobrem as funcionalidades testadas. As principais responsabilidades do
projetista de teste so:
Elaborar o projeto de teste O projetista deve elaborar o projeto de teste para ser
vivel a execuo de testes no sistema.
ESCOLA POLITCNICA
DE PERNAMBUCO
52
Correo do projeto de teste- Havendo alterao nos artefatos usados para a
elaborao do projeto de teste, o lder de teste deve avisar ao projetista para
efetuar as devidas correes, mantendo assim a integridade dos projetos de teste.
Executor de testes este papel deve ser considerado um dos mais importantes em uma
equipe de teste. Nele est empregado a responsabilidade de validar fluxos e regras de negcio. O
executor de testes o responsvel por executar os casos de testes criados pelo projetista de teste.
Tem o dever de registrar o status do testes e efetuar os retestes quando solicitado.
Executar o projeto de teste com o artefato de projeto de teste em mos o
executor deve efetuar seus testes com o olhar critico. Havendo qualquer quaisquer
duvidas dvidas sobre a elaborao do projeto de teste e do comportamento do
sistema deve ser reportado.
Manter lder do projeto informado do andamento do projeto O executor deve
manter o lder informado do status da execuo, caso o sistema esteja bastante
instvel os testes devem ser interrompidos e o lder do projeto deve ficar
encarregado de informar equipe de desenvolvimento e monitorar a resoluo dos
resultados.
5.3.2 Estrutura
O tamanho de uma iterao em processo gil motivo de discusso e divergncias.
Acreditamos que para o processo gil de teste ser positivo deva ser planejada a iterao de acordo
com a equipe de desenvolvimento. Caso o projeto tenha uma equipe de desenvolvimento madura,
com planejamento de curto, mdio e longo prazo, as iteraes devem ser planejadas em duas ou
trs semanas. Caso o projeto tenha uma equipe de desenvolvimento gil ou que necessite alterar o
cronograma constantemente o planejamento deve ser feito com iteraes de uma semana. Vale
salientar que a equipe de teste presta servios a vrios projetos e a alocao de recursos depende
da demanda de todo. Iteraes longas so inviveis a uma equipe de teste que deseja agradar seus
clientes. A equipe de teste trabalha sobre demanda, todos os projetos devem ter ateno especial,
sempre que requisitado.
No macro-fluxo esto representados os processos do PAT Processo gil de Teste:
Planejamento, Projeto de Teste, Preparao, Execuo De Teste, Finalizao e Acompanhamento
e Controle. Como descrito na Figura 6.
ESCOLA POLITCNICA
DE PERNAMBUCO
53
Figura 4.26: Viso Macro do PAT
A fase de Planejamento composta de atividades de perfil gerencial, que se preocupam

em avaliar e relacionar informaes a serem executadas em prazo, custo e recursos. limitados
visando execuo de objetivos predeterminados.
A fase de Projeto de Teste se preocupa com a inteligncia dos testes com base na
complexidade e relevncia do Requisito para o Sistema, levando em consideraes tambm
variveis como prazo, recurso e necessidade do cliente. Para isso, so criados elementos que
possibilitam esta definio, como: cenrios de teste e casos de teste.
A fase de Preparao o momento em que os testes so agrupados em sutes de acordo
com a estratgia de testes e criados ciclos de execuo.
A fase da Execuo de Teste tem como objetivo a execuo dos testes planejados,
projetados e organizados nas fases de Planejamento, Projeto de Teste e Preparao,
respectivamente.
A fase de Automao tem como objetivo preparar scripts e executar teste de forma
automtica visando garantir que mudanas realizadas em outros requisitos no tiveram impacto
no requisito testado.
Na fase de Finalizao, aps a execuo de testes de sistema, os gerentes e lderes do
projeto devero avaliar os critrios de concluso e xito e resultados de teste para definir se o
produto ser ou no liberado para o usurio final.
O processo de Acompanhamento e Controle um processo de apoio, com atividades de
monitoramento do andamento das atividades de cada fase. Suas atividades ocorrem ao longo das
fases.
ESCOLA POLITCNICA
DE PERNAMBUCO
54
5.3.3 Planejamento
Observa-se que o objetivo principal desta fase o desenvolvimento do plano de projeto
de teste. O gerente de teste o princialprincipal responsvel pela elaborao deste artefato. Vrios
fatores podem influenciar na elaborao do plano de projeto de teste, a importncia dos
requisitos, a proximidade de uma entrega, a influncia de outros projetos na equipe so exemplos
de fatores que podem influenciar na deciso do gerente.
A Figura 7 esquematiza o fluxo da fase de planejamento, seu principal responsvel e
alguns dos artefatos que podem influenciar na construo do plano de projeto de teste.
Figura 4.37: PAT - Planejamento
5.3.4 Projeto de Teste

Definido o plano de projeto de teste para a iterao chega a hora de classificar os
requisitos pela complexidade e importncia, para com isto dar incio a elaborao dos casos de
teste. Nesta fase o plano de projeto de teste pode ser alterado para dar incio ao desenvolvimento
do Cronograma de Teste.
Nesta fase importante que o gerente de teste especifique junto ao gerente de projeto os
critrios de concluso e xito do sistema, para ser validado nas prximas fases a concluso dos
testes.
ESCOLA POLITCNICA
DE PERNAMBUCO
55
Na atividade de classificar requisitos por complexidade e importncia interessante
salientar que dependendo do resultado desta classificao, da anlise dos artefatos fornecidos para
o requisito e da demanda que teste tem o Gerente de Teste junto com o Lder de Teste avaliam a
necessidade de criar casos de teste especficos para o requisito ou se vai usar casos de teste
genricos.
Para executar testes exploratrios o testador deve se basear em algum template, evitando
que esquea de testar alguma fluxo do sistema para isso uma boa prtica usar uma planilha de
testes genrica que contem alguns fluxos que podem ser apresentados durante o sistema. de
primordial importncia documentar os resultados dos testes tendo assim um caminho para a
execuo de retestes e de relatrios quando for solicitado. A Figura 8 apresenta um modelo de
como pode ser representada a planilha de testes genricas usada para guiar os testes exploratrios.
ESCOLA POLITCNICA
DE PERNAMBUCO
56
Figura 84.4: PAT Checklist de Testes Genricos
importante usar uma ferramenta de controle de mudanas para facilitar a documentao,

a gerao de relatrio e a integrao com a equipe de desenvolvimento para uma avaliao do
defeito de forma rpida e precisa.
O projeto de teste sendo construdo de forma especfica necessita de documentao rica
em detalhes e atualizada, caso seja possvel ter tal artefato como entrada para a elaborao de
ESCOLA POLITCNICA
DE PERNAMBUCO
57
casos de teste deve ser considerado um custo ligeiramente mais alto na preparao do projeto de
teste, porm ter um resultado mais expressivo na execuo dos testes.
A ltima atividade do projeto de teste a identificao dos cenrios de testes. Esta
atividade se faz necessria para a criao de ciclos de teste e de regresso. Na fase de execuo o
lider de teste deve solicitar testes de tudo que foi projetado porm, havendo uma urgncia na
entrega dos resultados o ciclo pode ser populado contendo apenas os cenrios de negcio, cenrio
este que contm os casos de teste com os principais fluxos e regras de negcio da funcionalidade,
por exemplo.
A Figura 9 representa a fase de Projeto de Teste.
Figura 94.5: PAT Projeto de Teste
5.3.5 Preparao
Esta fase consiste nas atividades de criao de sutes de teste e na criao de ciclos de
teste. O lder de teste o responsvel por esta fase, ele pode agrupar os cenrios e criar sutes de
teste que podem ser executadas ou no pelos testadores. Os ciclos de teste so as sutes
preparadas para a execuo. Esta distino entre sute e ciclos de teste fez-se necessria para o
melhor aproveitamento e organizao dos ciclos de execuo.
A Figura 10 representa esta fase.
ESCOLA POLITCNICA
DE PERNAMBUCO
58
Figura 4.206: PAT Preparao de Teste
5.3.6 Execuo de Teste

A fase de execuo refere-se tanto para testes automticos como a testes manuais. A nica
atividade dessa fase a Execuo de Teste, nela o testador executa os testes do ciclo populado
pelo lder na fase anterior.
Esta a principal atividade da equipe de teste e deve ser considerada como a mais
importante do processo. A seguir a Figura 11 representa a fase.
Figura 4.311: PAT Execuo de Teste

ESCOLA POLITCNICA
DE PERNAMBUCO
59
5.3.7 Automao
Nesta fase apresentada apresentado o papel do desenvolvedor. Este desenvolvedor no
deve ser confudidoconfundido com o desenvolvedor da equipe de desenvolvimento, ele
responsvel pela criao de scripts de teste para execuo de testes automticos. Apesar de ser
interessante, o desenvolvedor no necessariamente entende da arquitetura do sistema a ser
automatizado.
O gerente de teste executa nova avaliao com base no cronograma de teste e na planilha
de execuo. Caso a equipe esteja atrasada ou os testes iniciais obtiveram muitas falhas, o gerente
pode abolir a criao de scripts de teste para dado requisito.
O principal papel desta fase o desenvolvedor que vai traduzir os casos de teste em
scripts de automao.
A Figura 12 representa a fase.
Figura 134.6: PAT - Automao
5.3.8 Finalizao
Fase consiste na atividade de levantar lies aprendidas objetivando a melhoria contnua
do processo. Figura 13 exemplifica a fase.
ESCOLA POLITCNICA
DE PERNAMBUCO
60
Figura 144.8: PAT - Finalizao
5.3.1 Acompanhamento e Controle

Esta fase ocorre em paralelo as outras. Existe para garantir que as demais fases trabalhem
de forma correta.
A atividade de acompanhar status do projeto necessria para o gerente de teste saber se o
que foi planejado est sendo cumprido e realizar ajustes na sua estimativa em teste.
A atividade de gerar relatrio existe para suprir a necessidade do cliente, gerente de
projeto e gerente de teste em saber o status do produto objetivando estimar esforo para futuras
iteraes. O gerente de projeto necessita saber se o produto encontra-se robusto para estimar
esforo para correo ou para desenvolvimento de outras funcionalidades, caso o sistema
encontre vrios pontos de melhoria o gerente deve alocar recursos para corrigir os registros de
defeito abertos. O gerente de teste nessecitanecessita de relatrios para estimar novos ciclos de
execuo de teste, planejando execuo de teste em outros requisitos ou criando ciclos de
regresso.
ESCOLA POLITCNICA
DE PERNAMBUCO
61
Figura 154.9: PAT Acompanhamento e controle
5.4Vantagens e Desvantagens
O PAT no tem obrigatoriedade de documentos formais, apenas de documentao mnima
para gerar relatrios, estimar esforo e para execuo de retestes. Exemplificando o que foi dito
o fato que pode ser considerado como plano de projeto de teste a ata de reunio onde foi
estabelecido todo o escopo da equipe de teste. E-mails, e papis assinados pelos colaboradores
podem ser usados como artefato de entrada para uma atividade. Esta agilidade torna o processo
menos burocrtico, trazendo um retorno significativo mais rapidamente. No existe uma
documentao padro para a maioria dos artefatos do processo.
O PAT utiliza a flexibilidade das metodologias geis, bem como o processo iterativo e
fortemente baseado no feedback, se adaptando e moldando a cada iterao. Ele tambm d
prioridade a pessoas e no ao processo visto que um de seus focos so os testes exploratrios e
para serem bem executados necessitam de pessoas bem treinadas.
ESCOLA POLITCNICA
DE PERNAMBUCO
62
Este captulo props e detalhou cada fase de um processo de teste que utiliza testes
exploratrios e tem caractersticas geis. Apresentou um guia de cenrios de testes de sistema que
pode ser utilizado para vrias funcionalidades de vrios projetos. E com base nesse guia montou
uma planilha de execuo que contm informaes relevantes para analisar a situao e
acompanhar a evoluo de um sistema. Alm de fornecer dados para estimativas de esforo. Foi
explanado neste capitulo um metamodelo para descrio de processo de software, o SPEM, que
foi utilizado para descrever o processo proposto bem como suas fases e atividades.
ESCOLA POLITCNICA
DE PERNAMBUCO
63
Captulo
Concluso Consideraes Finais e

Trabalhos Futuros
Este trabalho de graduao abordou a importncia e os ganhos obtidos quando os produtos

so testados antes de chegarem aos clientes. Vrios conceitos e informaes relevantes sobre teste
de software foram apresentados.
O trabalho procurou desenvolver um processo de teste para suprir uma necessidade de
mercado. Foram utilizadas estratgias geis. Dentre as estratgias de testes existentes, foram
abordadas a forma exploratria e baseada em caso de uso.
Foi feito uma modelagem do processo com o auxlio do SPEM para descrever as fases e
as atividades do processo, sua interao com os colaboradores e os artefatos de entrada e gerados.
O trabalho traz uma boa viso sobre testes de software. O processo garante que testes
bsicos so realizados de forma rpida, ajuda a explorao, possibilita uma melhor distribuio
dos recursos e o aumento na deteco de erros. Um guia de cenrios de testes que abrange testes
de campo, negcio, usabilidade, segurana foi construdo. O guia desenvolvido bem genrico e
ESCOLA POLITCNICA
DE PERNAMBUCO
64
pode ser usado em vrios projetos. Uma planilha de execuo que instancia o guia de cenrios de
testes foi concebida. A planilha fornece informaes bsicas para a medio e anlise dos testes.
O processo abordado pode ser adaptado e moldado para ser empregado em qualquer
organizao. Ele torna a atividade de teste menos informais. Garante que testes mnimos so
realizados e preserva as vantagens da utilizao da tcnica que so: resultados rpidos,
necessidade de pouco tempo e pouco recurso. Quando necessrio, ele tambm trabalha de forma
a encontrar o maior nmero de erros possvel, mesmo que isto signifique aumento no esforo.
6.1Trabalhos Relacionados
Um processo de Teste semelhante ao exposto neste trabalho foi aplicada aplicado em uma
empresa no inicio incio do ano de 2008. Nesta seo sero descritos o ambiente do estudo de
caso, o processo, anlise de resultados, benefcios para a organizao e a anlise crtica do
processo pelos usurios.
6.1.1 Ambiente
A organizao onde o processo foi aplicado uma empresa nacional de Tecnologia da
Informao. Os processos possuem certificado ISO 9001:2000 e o processo de desenvolvimento
tambm compatvel com o CMMI Nvel 2.
O processo de teste ocorre em paralelo ao processo de desenvolvimento e um processo
maduro e independente.
6.1.2 Descrio do Processo

Inicialmente o projeto foi estruturado em Fases e Pacotes e os requisitos distribudos entre
elas. Foi projetado duas fases a primeira com trs pacotes e a segunda com 4 pacotes. Cada
pacote tem um conjunto de requisitos.
importante salientar que os registros de defeito encontrados foram reportados com o
auxilio da ferramenta de cdigo aberto Mantis BugTracking System. [16]
A equipe de teste estudada composta de 8 pessoas que eram distribudas de acordo com
a demanda dos projetos. Todos, em algum momento, executaram e projetaram casos de teste no
sistema.
ESCOLA POLITCNICA
DE PERNAMBUCO
65
Com base nas estrias de uso deu-se incio ao desenvolvimento do software e ao incio
das atividades com a elaborao do projeto de teste com casos de testes genricos, baseando-se
no foco da estria.
Os primeiros requisitos foram simples, o fato de existirem apenas para dar suporte aos
requisitos principais do sistema logo, no foi necessrio detalhar seu funcionamento e estrias
foram suficientes para descrever sua importncia. Logo, foi usado usada a planilha de testes
genricos para a execuo de teste nesses requisitos.
A equipe de teste encontrou nesta fase inicial 166 registros de defeitos sendo 70 de
negocio apenas executando testes exploratrios, porm consultando a equipe de anlise e os
principais fluxos com base na planilha de testes genricos.
A fase 2 tiveram menos requisitos, mas com maior importncia para o sistema. Alguns
requisitos foram homologados atravs de documentos de caso de uso, que possui um
detalhamento maior da funcionalidade se comparado as estrias. A equipe de teste no projetou
casos de teste especficos para os requisitos, houve um atraso na entrega e foi solicitado que a
equipe a execuo de caso de teste genrico. O resultado dos testes foram satisfatrios, mesmo
no projetando caso de teste especfico foram encontrados 156 registros de defeitos sendo 79
registros de negcio, nmeros significativos para os principais requisitos do sistema.
O cliente encontrou 12 erros no sistema. Destes 6 foram erros encontrados por teste que
foi implementado e testado por teste mas que por um erro no processo de desenvolvimento
escapou para o cliente e 6 foram erros que a equipe de teste no encontrou. Este nmero foi
aceitvel pela baixa gravidade dos erros e por ter sido em fluxos de difcil previso.
Para este projeto no foi utilizado automao.
6.1.3 Benefcios do Processo para Organizao

Foi considerado um caso de sucesso. Vrios erros foram encontrados e reportados antes de
chegar ao cliente. A utilizao do processo foi bem vista na organizao, inclusive pelos
desenvolvedores. Utilizando o processo tradicional da empresa, a equipe de teste no iria
participar deste projeto, pois a estimativa do esforo de teste era alto e ultrapassava o oramento
do projeto. No planejamento, o custo de testes era estimado de forma a seus nmeros serem
inviveis ao oramento do projeto. Com a utilizao deste processoNa prtica do processo viu-se
que o custo de teste pode ser baixo, tornando o custo-benefcio atrativo para vrios projetos,
inclusive de pequeno e mdio porte que antes no poderiam usar os recursos de teste.
ESCOLA POLITCNICA
DE PERNAMBUCO
66
6.2Trabalhos Futuros
Ao elaborar este trabalho surgiu a necessidade de se utilizar uma ferramenta especfica
para armazenamento, controle e gerenciamento de caso de teste, com escopo em gerao de
relatrio e em automao. Isto aumentaria a velocidade com que os testes so executados e a
coleta de mtricas de teste.
Deve ser adicionado ao escopo do processo de teste proposto neste trabalho, testes de
suporte, carga, volume, estresse, configurao, instalao e integridade. Alm desses
imprescindvel que verses futuras aumentem o escopo dos testes de segurana.
Fornecer templates para todos os artefatos do processo. Por se tratar de um processo gil,
tais artefatos no necessitam seguir fielmente o template, porm tal padronizao torna o processo
mais robusto e mais organizados.
6.3Dificuldades Encontradas
As maiores dificuldades foram na utilizao do processo descrito na seo acima,
trabalhos relacionados, na empresa. Por a empresa possuir um processo de teste maduro, houve a
resistncia em se tentar algo com caractersticas geis.
Na elaborao do processo, a principio, no tnhamos conhecimento em como modelar e
apresentar esta modelagem. Depois de um estudo foi proposto o SPEM que foi aceito pelo
orientador. A ferramenta a qual foi criado o processo, Microsoft Office Visio tambm foi um
desafio para seu entendimento. Tivemos que pensar em uma forma de documentar os testes
exploratrios, pois no inicio incio os testes exploratrios criavam registros de defeitos, mas no
se tinha registros de quais funcionalidades o testador passou, com isso foi idealizado um checklist
para guiar os testes exploratrios.
6.4Contribuio
Criou-se uma modelagem de um processo de teste com o auxlio do SPEM para descrever
as fases e as atividades, sua interao com os colaboradores e os artefatos de entrada e gerados.
O trabalho trouxe uma boa viso sobre testes de software.
Um guia de cenrios de testes que abrange testes de campo, negcio, usabilidade,
segurana foi construdo.
ESCOLA POLITCNICA
DE PERNAMBUCO
67
Conceito de teste em par com sua particularidade no processo foi apresentado.
Apresentao de um processo que pode ser instanciado em uma empresa.
Este captulo relata a o resultado de um processo com caractersticas geis em uma
empresa. Foi descrito o ambiente, o processo, anlise dos resultados, benefcios para a
organizao e a anlise crtica do processo pelos usurios.
.
ESCOLA POLITCNICA
DE PERNAMBUCO
68
Bibliografia
[1] POL M., et al. Software Testing - A Guide to the TMap, ed. Approach - Addison-Wesley,
2006. 592p
[2] JONES, T.Capers. Patterns of Software System Failure and Success,,ed. Intl Thomson
Computer Pr, 1995. 292p.
[3] RIOS, Emerson; MOREIRA, Trayah, Teste De Software, 2 ed. Alta Books, 2006. 768p
[4] SCHWABER, Ken; Agile Project Management with Scrum, ed. Microsoft Press, 2004. 163p
[5] ARAUJO, Rodrigo. Construo Grfica de Processos de Desenvolvimento e Gerao de uma
Ontologia de Processo de Software. 2005. 73f. Trabalho de Concluso de Curso
(Graduao) Curso de Cincia da Computao, Centro de Informtica UFPE, Recife,
2005. Disponvel em: < http://www.cin.ufpe.br/~tg/2005-1/rma.pdf>. Acesso em: mar.
2008.
[6] OMG - Software Process Engineering Metamodel Specification verso 1.1, Disponvel em:
http://www.omg.org/technology/documents/formal/spem.htm Acesso em: Maro de 2008
OMG - Software Process Engineering Metamodel Specification verso 1.1, Disponvel
em: http://www.omg.org/technology/documents/formal/spem.htm Acesso em: Maro de
2008
[7] Java Magazine edio 33, Desenvolvimento gil Um Guia sobre os Processos geis de
Desenvolvimento
[8] Pressman, R. Engenharia de Software McGraw-Hill, (2001)
[9] FILHO, Manoel. Um estudo comparativo entre SPEM e BPMN como padres para
modelagem de Processos de Software. 2007. 91f. Trabalho de Concluso de Curso
(Graduao) Curso de Cincia da Computao, Centro de Informtica UFPE, Recife,
2007. Disponvel em: < http://www.cin.ufpe.br/~tg/2007-1/mgcasf.pdf>. Acesso em: mar.
2008
ESCOLA POLITCNICA
DE PERNAMBUCO
69
[10] GENVIGIR, C. E., SANTANNA, N., FILHO, B.F.L. Modelagem de Processos de
Software Atravs do SPEM - Software Process Engineering Metamodel - Conceitos e
Aplicao. In: III WORCAP 2003
[11] GENVIGIR, C. E., SANTANNA, N., FILHO, B.F.L. Modelagem de Processos de
Software Atravs do SPEM - Software Process Engineering Metamodel -Conceitos e
Aplicao.
[12] JACINTO, Shirley. Modelagem dos processos de Gerenciamento de Tempo do PMBok
utilizando SPEM e BPMN. 2007. 93f. Trabalho de Concluso de Curso (Graduao)
Curso de Cincia da Computao, Centro de Informtica UFPE, Recife, 2007. Disponvel
em: < http://www.cin.ufpe.br/~tg/2007-2/ssj.doc>. Acesso em: mar. 2008
[13] MARAL, Ana; FREITAS, Bruno. Estendendo o SCRUM segundo as reas de Processo
de Gerenciamento de Projetos do CMMI, Publicado em: CLEI 2007: XXXIII Conferencia
Latinoamericana de Informtica, San Jose, Costa Rica
[14] MENDES, Rodrigo. MODELAGEM ODELAGEM E AVALIAO DO CMMI NO
SPEM PARA DEFINIO DE UM META-PROCESSO DE SOFTWARE. 2004. 83f.
Trabalho de Concluso de Curso (Graduao) Curso de Cincia da Computao, Centro
de Informtica UFPE, Recife, 2004. Disponvel em: < http://www.cin.ufpe.br/~tg/2004-
2/rcm2.pdf>. Acesso em: mar. 2008.
[15] TELES, Vinicius, Extreme Programming, ed. Novatec, 2004. 320p
[16] Mantis BugTracking System, Disponvel em: http://www.mantisbt.org/ Acesso em: julho
de 2008

Teste Agil de Software

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Teste Agil de Software

Hochgeladen von

Copyright:

Verfügbare Formate

ESCOLA POLITCNICA

O Resumo monobloco com 250 a 300 palavras

Revise o texto em ingls

3 Metodologias de Desenvolvimento de Software 26

4 O Processo gil de Teste - PAT 31

5 Consideraes Finais e Trabalhos Futuros 50

3 Metodologias de Desenvolvimento de Software 26

4 O Processo gil de Teste - PAT 31

4 Metodologias de Desenvolvimento de Software 32

5 O Processo gil de Teste - PAT 37

Figura 2.1: Grfico ilustrando o momento de interromper os testes.................................................15

Tabela 4.1: Representao grfica dos principais elementos do SPEM........................................... 32

Tabela de Smbolos e Siglas

CIN Centro de Informtica UFPE

Figura 1: Nveis de modelagem definidos pela OMG

O SPEM encontra-se no nvel M2 da arquitetura de quatro camadas da OMG e seu metamodelo

Tabela 1: Representao grfica dos principais elementos do SPEM

3.1Histria da Atividade de Teste

Figura 2.1: Grfico ilustrando o momento de interromper os testes

Figura 32.2: Exemplo ilustrativo de validao e verificao

Os testes de verificao so tipos de teste que geralmente so realizados sobre os

3.4Tipos de Testes de Software

3.6.1 Testes Manuais

3.6.2 Testes Automticos

Incio da Incio dos Testes

Figura 42.3: O conceito V de testes de software

DEFINIO DOS PASSO 1

Figura 52.4: 11 passos do Processo de Teste de Software

4.1Pessoas versus Processo

4.2XP - eXtreme Programming

4.5RUP Rational Unified Process

O Processo gil de Teste - PAT

5.1SPEM - Software Process Engineering Metamodel

Figura 4.1: Nveis de modelagem definidos pela OMG

O SPEM encontra-se no nvel M2 da arquitetura de quatro camadas da OMG e seu

5.1.1 Principais Elementos de Definio do Processo

Tabela 14.1: Representao grfica dos principais elementos do SPEM

Gerente de Projeto o responsvel por coordenar as atividades da equipe de

Lder de Projeto o responsvel pela interface da equipe de desenvolvimento com a

Figura 4.26: Viso Macro do PAT

A fase de Planejamento composta de atividades de perfil gerencial, que se preocupam

Figura 4.37: PAT - Planejamento

5.3.4 Projeto de Teste

Figura 84.4: PAT Checklist de Testes Genricos

importante usar uma ferramenta de controle de mudanas para facilitar a documentao,

Figura 94.5: PAT Projeto de Teste

Figura 4.206: PAT Preparao de Teste

5.3.6 Execuo de Teste

Figura 4.311: PAT Execuo de Teste

Figura 134.6: PAT - Automao

Figura 144.8: PAT - Finalizao

5.3.1 Acompanhamento e Controle

Figura 154.9: PAT Acompanhamento e controle

Concluso Consideraes Finais e

Este trabalho de graduao abordou a importncia e os ganhos obtidos quando os produtos

6.1.2 Descrio do Processo

6.1.3 Benefcios do Processo para Organizao

Das könnte Ihnen auch gefallen