Automação de Testes de Regressão - Selenium

UNIVERSIDADE DO SUL DE SANTA CATARINA
MAIELE PEROSA RANZAN
RODRIGO SUSIN DE OLIVEIRA
AUTOMAÇÃO DE TESTES DE REGRESSÃO:
UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK SELENIUM
Palhoça
2013

Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.
Orientador: Prof. Flavio Ceci, M.Eng.
Palhoça
2013

Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina.
Palhoça, 29 de junho de 2013.
______________________________________________________
Professor e orientador Flavio Ceci, M.Eng.
Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Prof. Jean Carlo Rossa Hauck, Dr.
Universidade do Sul de Santa Catarina
______________________________________________________
Alessandra Mohr.
Convidada

Dedico esse trabalho à minha família que
sempre me apoiou. Ao meu namorado Rafael
que com seu amor me manteve motivada nessa
etapa da minha vida. Ao nosso orientador
Flávio que foi prestativo e nos ajudou em
todos os momentos.
Maiele Perosa Ranzan
Dedico, com muito carinho, essa monografia à
minha família e, principalmente, à minha
namorada Adriana e à minha mãe Carla
Beatriz que não mediram esforços para a
realização desse trabalho e pela compreensão
que tiveram comigo nos momentos de
dificuldade. E a todos meus amigos que me
apoiaram e me acompanharam na minha vida
acadêmica.
Rodrigo Susin de Oliveira

AGRADECIMENTOS
Maiele Perosa Ranzan agradece
Essa monografia foi elaborada, acima de tudo, com muita dedicação e força de
vontade minha e do meu amigo Rodrigo; porém, muitas pessoas participaram direta ou
indiretamente dela. Nesse espaço, quero agradecer a todos que ajudaram a concluí-la.
Primeiramente, agradeço aos meus pais que sempre me apoiaram em toda a minha
caminhada e que nesse momento foram fundamentais como ponto de equilíbrio e força.
Ao meu namorado Rafael que, com toda sua paciência, compreensão e amor,
tornou-se essencial para que eu conseguisse seguir em frente, perdoando muitos momentos
em que tive que ficar ausente em função desse projeto.
Meus agradecimentos sinceros ao amigo e parceiro dessa jornada, Rodrigo, que
me acompanhou em diversos trabalhos acadêmicos e na presente monografia. Acredito que
sem sua ajuda esse ciclo teria sido muito mais difícil.
Ao nosso Orientador Prof. Flávio Ceci pelo incentivo, simpatia e presteza no
auxílio às atividades e discussões sobre o andamento desse estudo de caso. Com certeza, seu
apoio foi imprescindível e jamais esqueceremos.
A Profª Maria Inês pela tarefa de multiplicar seus conhecimentos ministrando a
disciplina que nos conduziu a essa obra.
Aos colegas que nos forneceram o protótipo para que utilizássemos como base
para a construção do estudo de caso e aos testadores que disponibilizaram seu tempo para
realização dos testes manuais do protótipo.
E, por fim, o meu muito obrigada aos membros da banca por terem aceito nosso
convite, agregando seus conhecimentos.

Rodrigo Susin de Oliveira agradece
A toda minha família pelo apoio dado nessa empreitada, principalmente, a meu
pai, minha mãe, minha irmã e minha namorada que sempre me incentivaram e estiveram ao
meu lado nos momentos difíceis.
Aos meus colegas, José Fernando e Giovani Brunel Paes, que permitiram a
divulgação do protótipo Projector dessa monografia.
Aos colegas, Rodrigo Veleda e Luiz Santana, por disponibilizar a modelagem do
protótipo Projector.
Agradeço aos Testadores que foram prestativos na execução do estudo de caso.
Novamente, agradeço à minha mãe, Carla Beatriz Susin de Oliveira, por fazer a
correção desse trabalho.
À Banda Infinito Restrito que me liberou dos ensaios para trabalhar na
monografia e que, também, me compreendeu nos dias de estresse.
À minha colega e amiga Maiele Perosa Ranzan por ser tão paciente no
desenvolvimento do trabalho e por estar sempre motivada ao longo dessa jornada.
Ao meu amigo e Profº Orientador Flávio Ceci, pelos ensinamentos, estímulo,
apoio e dedicação nessa trajetória.
Enfim, agradeço a todos que direta ou indiretamente participaram do
desenvolvimento da presente monografia.

“Você pode encarar um erro como uma besteira a ser esquecida, ou como um resultado que
aponta uma nova direção.” (Steve Jobs).

RESUMO
A área de testes está ocupando um espaço cada vez maior nas organizações de
desenvolvimento de software, pois se observa que com a mesma é possível aumentar a
qualidade de uma aplicação, gerando maior satisfação para seu cliente final. Existem diversas
técnicas e tipos que classificam os testes de software, dentre os quais o de regressão. Este, por
sua vez, costumeiramente é manual; sendo assim, suscetível a falhas em sua execução. Como
forma de minimizar esse problema, surgiu o conceito de automação de teste, onde existe um
ferramental vasto para sua concepção. Nesse estudo de caso, adotou-se o framework Selenium
que automatizou uma rotina de testes regressivos em um protótipo web, desenvolvido durante
a graduação, por acadêmicos do curso de Sistemas de Informação da Unisul. Os mesmos
testes foram executados manualmente com o apoio de dois participantes que responderam a
um questionário. Os resultados obtidos depois de feita a comparação entre a prática manual e
a automatizada foram satisfatórios, uma vez que se notou um ganho, principalmente, nas
questões de tempo e qualidade do teste aplicando a técnica automática.
Palavras-chave: Teste de software, Automação, Framework Selenium.

ABSTRACT, RÉSUMÉ OU RESUMEN
The test area is occupying a growing space on the software development organization,
because we note that with that it is possible to increase the quality of an application,
generating greater satisfaction to your final client. There are many techniques and kinds of
regression. This, on the other hand, customarily is manual; thus, where there is a vast tooling
to its conception. In this case studies, was adopted the “framework Selenium” which
automated a regression tests routine in a prototype web, developed during graduation, by the
course of Information System Unisul academics. The same tests were manually executed with
the help of two participants that answered a survey. The obtained results after the comparison
was made between the manual practice and the automated were satisfactory results, since a
gain was noted, manly, in things like time and test quality applied the automated technique.
Keywords: Software test, Automation, Framework Selenium.

LISTA DE ILUSTRAÇÕES
Figura 1 – Atividades do modelo cascata.................................................................................26
Figura 2 - Custo de modificação ..............................................................................................26
Figura 3 - Modelo Incremental.................................................................................................28
Figura 4 - Atividades da Prototipação......................................................................................29
Figura 5 - Iterações do modelo espiral .....................................................................................30
Figura 6 - Custo de mudanças nas metodologias ágeis ............................................................32
Figura 7 - Funcionamento do Scrum ........................................................................................35
Figura 8 - Custo de correção dos problemas ............................................................................38
Figura 9 - Visão do teste caixa-preta........................................................................................43
Figura 10 - Visão do teste caixa-branca ...................................................................................46
Figura 11 - Etapas metodológicas ............................................................................................57
Figura 12 - Esboço da Solução.................................................................................................59
Figura 13 - Etapas do questionário...........................................................................................61
Figura 14 - Visão geral do ICONIX.........................................................................................66
Figura 15 - Diagrama de Atores ...............................................................................................68
Figura 16 - Requisitos Funcionais............................................................................................70
Figura 17 - Requisitos não funcionais......................................................................................72
Figura 18 - Tela de cadastro dos projetos.................................................................................73
Figura 19 - Tela de cadastro das atividades..............................................................................74
Figura 20 - Casos de Uso..........................................................................................................75
Figura 21 - Cadastrar Projeto ...................................................................................................76
Figura 22 - Cadastrar Atividade ...............................................................................................77
Figura 23 - Diagrama de Domínio............................................................................................78
Figura 24 - Diagrama de Robustez...........................................................................................79
Figura 25 - Diagrama de Sequência - Login.............................................................................80
Figura 26 - Cadastrar Perfil ......................................................................................................81
Figura 27 - Cadastrar Usuário ..................................................................................................82
Figura 28 - Cadastrar clientes...................................................................................................83
Figura 29 - Emissão de relatórios.............................................................................................84
Figura 30 - Cadastro de marco .................................................................................................85
Figura 31 - Cadastrar projeto....................................................................................................86
Figura 32 - Cadastro de cronograma ........................................................................................87
Figura 33 - Cadastrar atividade ................................................................................................88
Figura 34 - Cadastro de status ..................................................................................................89
Figura 35 - Registro de hora da atividade ................................................................................90
Figura 36 - Consultar andamento do projeto............................................................................91
Figura 37 - Diagrama de Classes..............................................................................................92
Figura 38 - Arquitetura do Projector ........................................................................................94
Figura 39 - Cadastrar projeto no Projector...............................................................................97
Figura 40 - Listagem de projetos no Projector .........................................................................98
Figura 41 - Cadastro de cronograma no Projector....................................................................98
Figura 42 - Cadastro de atividade no Projector........................................................................99
Figura 43 - Listagem das atividades no Projector ....................................................................99
Figura 44 - Fluxograma da elaboração do teste......................................................................101
Figura 45 - Funcionamento Selenium RC..............................................................................109

Figura 46 - Exemplo WebDriver em Java..............................................................................111
Figura 47 - Pacote de entidades..............................................................................................113
Figura 48 - Pacote core...........................................................................................................114
Figura 49 - Arquivos de configuração....................................................................................115
Figura 50 - Pacote testcase .....................................................................................................116
Figura 51 - Pacote util ............................................................................................................117
Figura 52 - Cadastro de Atividade..........................................................................................119
Figura 53 - Cadastro de atividade campos obrigatórios .........................................................120
Figura 54 - Grid de atividades................................................................................................120
Figura 55 - Início da execução ...............................................................................................123
Figura 56 - Acesso ao sistema................................................................................................124
Figura 57 - Execução incorreta...............................................................................................125
Figura 58 - Detecção do bug pelo Testador X........................................................................126
Figura 59 - Testador X finaliza o teste ...................................................................................127
Figura 60 - Testador Y conclui o teste manual.......................................................................128
Figura 61 - Início da execução automatizada.........................................................................129
Figura 62 – Abertura automática no navegador .....................................................................130
Figura 63 - Componente calendário .......................................................................................131
Figura 64 - Automação encontra bug .....................................................................................132
Figura 65 - Teste automatizado de salvar cronograma...........................................................132
Figura 66 - Fim do teste automatizado...................................................................................133
Figura 67 - Log da automação................................................................................................134
Figura 68 - Log da automação apresentando o bug................................................................135

LISTA DE QUADROS
Quadro 1 - Ferramentas comerciais..........................................................................................50
Quadro 2 - Ferramentas acadêmicas.........................................................................................51
Quadro 3 - Comparações entre manual e automatizado.........................................................136
Quadro 4 - Prós e contras da automação ................................................................................138
Quadro 5 - Prós e contras do teste manual .............................................................................138

SUMÁRIO
1 INTRODUÇÃO............................................................................................................................. 16
1.1 PROBLEMÁTICA .......................................................................................................................17
1.2 OBJETIVOS.................................................................................................................................19
1.2.1 Objetivo geral...........................................................................................................................19
1.2.2 Objetivos específicos................................................................................................................19
1.3 JUSTIFICATIVA .........................................................................................................................19
1.4 ESTRUTURA DA MONOGRAFIA ............................................................................................21
2 REVISÃO BIBLIOGRÁFICA..................................................................................................... 22
2.1 A CRISE DE SOFTWARE............................................................................................................22
2.2 ENGENHARIA DE SOFTWARE ...............................................................................................23
2.2.1 Metodologias de Desenvolvimento..........................................................................................24
2.2.1.1 Metodologias Tradicionais..................................................................................................... 25
2.2.1.1.1 Modelo clássico ...................................................................................................................25
2.2.1.1.2 Modelo Incremental.............................................................................................................27
2.2.1.1.3 Prototipação ........................................................................................................................28
2.2.1.1.4 Modelo espiral.....................................................................................................................30
2.2.1.2 Metodologias Ágeis................................................................................................................ 31
2.2.1.2.1 Extreme Programming (XP) ................................................................................................32
2.2.1.2.2 Scrum ...................................................................................................................................34
2.3 TESTES DE SOFTWARE ...........................................................................................................36
2.3.1 Técnicas para Teste de Software ............................................................................................39
2.3.1.1 Teste de unidade..................................................................................................................... 40
2.3.1.2 Teste de integração................................................................................................................. 40
2.3.1.3 Teste de sistema ..................................................................................................................... 41
2.3.1.4 Teste de aceitação................................................................................................................... 41
2.3.1.5 Tipos de teste.......................................................................................................................... 42
2.3.1.5.1 Testes de caixa-preta ...........................................................................................................42
2.3.1.5.1.1 Testes de requisitos .......................................................................................................... 43
2.3.1.5.1.2 Testes de regressão........................................................................................................... 44
2.3.1.5.1.3 Testes de tratamento de erros........................................................................................... 45
2.3.1.5.1.4 Testes de interconexão ..................................................................................................... 45
2.3.1.5.2 Teste de caixa branca ..........................................................................................................45
2.3.1.5.2.1 Testes de estresse ............................................................................................................. 46
2.3.1.5.2.2 Testes de performance...................................................................................................... 47
2.3.1.5.2.3 Testes de recuperação....................................................................................................... 47
2.3.1.5.2.4 Testes de segurança.......................................................................................................... 47
2.3.1.5.3 Testes não-funcionais...........................................................................................................48
2.3.1.5.3.1 Testes de usabilidade........................................................................................................ 48
2.3.1.5.3.2 Teste de instalação ........................................................................................................... 48
2.3.2 Automatização de Testes de Software....................................................................................49
2.3.2.1 Ferramentas para automação de teste..................................................................................... 50
2.3.2.2 Tendências para as ferramentas de automação....................................................................... 52
2.3.2.3 Automação de Teste x Teste de Regressão ............................................................................ 53
3 MÉTODO....................................................................................................................................... 55
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA.......................................................................55
3.2 ETAPAS METODOLÓGICAS....................................................................................................56
3.3 DESENHO DA SOLUÇÃO .........................................................................................................58
3.4 CARACTERÍSTICAS DO ESTUDO DE CASO.........................................................................59

3.4.1 Cenário proposto......................................................................................................................60
3.4.2 Objetivos...................................................................................................................................60
3.4.3 Ferramentas utilizadas............................................................................................................61
3.4.4 Perfil dos profissionais envolvidos..........................................................................................62
3.4.5 Avaliação dos resultados .........................................................................................................62
3.5 DELIMITAÇÕES.........................................................................................................................62
4 PROJETO DE SOLUÇÃO DO PROTÓTIPO........................................................................... 64
4.1 DEFINIÇÃO DE TÉCNICA E METODOLOGIA ......................................................................64
4.1.1 Unified modeling language (UML).........................................................................................64
4.1.2 Iconix.........................................................................................................................................65
4.1.3 Orientação a Objetos (OO) .....................................................................................................66
4.2 DESCRIÇÃO DO PROTÓTIPO UTILIZADO NO ESTUDO DE CASO ..................................67
4.2.1 Atores........................................................................................................................................68
4.2.2 Requisitos..................................................................................................................................69
4.2.2.1 Requisitos Funcionais ............................................................................................................ 69
4.2.2.2 Requisitos Não Funcionais..................................................................................................... 71
4.2.3 Protótipos de Interface ............................................................................................................72
4.2.4 Casos de Uso.............................................................................................................................74
4.2.5 Modelo de Domínio..................................................................................................................78
4.2.6 Diagramas de Robustez...........................................................................................................78
4.2.7 Diagramas de Sequência..........................................................................................................79
4.2.8 Diagrama de Classe..................................................................................................................91
4.3 RESUMO DO CAPÍTULO ..........................................................................................................92
5 AUTOMATIZAÇÃO DE TESTES DE SOFTWARE............................................................... 93
5.1 SISTEMA DESENVOLVIDO PARA O ESTUDO DE CASO...................................................93
5.1.1 Tecnologias utilizadas..............................................................................................................93
5.1.1.1 Enterprise Architect................................................................................................................ 95
5.1.1.2 Eclipse.................................................................................................................................... 95
5.1.1.3 Hibernate................................................................................................................................ 95
5.1.1.4 Java......................................................................................................................................... 96
5.1.1.5 Java Server Faces ................................................................................................................... 96
5.1.1.6 MySQL................................................................................................................................... 96
5.1.1.7 Apache Tomcat ...................................................................................................................... 97
5.1.2 Descrição do sistema................................................................................................................97
5.2 CASOS DE TESTE ....................................................................................................................100
5.2.1 Método ....................................................................................................................................100
5.2.2 Ferramentas utilizadas..........................................................................................................102
5.2.3 Roteiro de teste.......................................................................................................................102
5.2.3.1 Teste Salvar Projeto ............................................................................................................. 102
5.2.3.2 Teste salvar projeto com cliente........................................................................................... 103
5.2.3.3 Teste editar projeto............................................................................................................... 103
5.2.3.4 Teste excluir projeto............................................................................................................. 104
5.2.3.5 Teste cadastrar atividade...................................................................................................... 105
5.2.3.6 Teste cadastrar atividade com cronograma .......................................................................... 105
5.2.3.7 Teste cadastrar atividade completo ...................................................................................... 106
5.2.3.8 Teste de efetuar login com usuário válido............................................................................ 107
5.2.3.9 Teste de efetuar login com usuário inválido ........................................................................ 107
5.2.3.10 Teste de salvar cronograma................................................................................................ 108
5.3 AUTOMATIZAÇÃO DE TESTES............................................................................................108
5.3.1 Ferramentas utilizadas..........................................................................................................112
5.3.2 Automação dos casos de teste................................................................................................112
5.4 ESTUDO DE CASO...................................................................................................................118
5.4.1 Bugs inseridos no sistema......................................................................................................119
5.4.2 Seleção dos atores...................................................................................................................121

5.4.3 Execução manual dos casos de teste.....................................................................................121
5.4.4 Execução automatizada dos casos de teste...........................................................................128
5.4.5 Resultados obtidos .................................................................................................................135
5.5 AVALIAÇÃO DOS RESULTADOS.........................................................................................137
6 CONCLUSÕES E TRABALHOS FUTUROS.......................................................................... 140
6.1 CONCLUSÕES ..........................................................................................................................140
6.2 TRABALHOS FUTUROS .........................................................................................................141
REFERÊNCIAS ................................................................................................................................ 142
APÊNDICES...................................................................................................................................... 146
APÊNDICE A – QUESTIONÁRIO................................................................................................. 147
ANEXOS............................................................................................................................................ 149
ANEXO A – QUESTIONÁRIO DO TESTADOR X ..................................................................... 150
ANEXO B – QUESTIONÁRIO DO TESTADOR Y ..................................................................... 153

16
1 INTRODUÇÃO
No desenvolvimento de software ocorrem situações em que o sistema é entregue
ao cliente com qualidade baixa, ou seja, mesmo respeitando e seguindo corretamente as etapas
de desenvolvimento de software, análise, construção, testes, correções de defeitos e reteste, o
mesmo ainda pode conter erros.
Um problema bastante comum na rotina das organizações são os curtos prazos nos
projetos. Deste modo o sistema acaba sendo entregue às pressas e com poucos testes, não
garantindo sua qualidade e eficiência.
De acordo com o autor de diversos livros na área de qualidade de software,
Molinari (2003), os defeitos encontrados na fase de implantação podem ser até cem vezes
mais caros do que se tivessem sido descobertos antes do software ser entregue ao cliente final.
Para Inthurn (2001, p. 21), desenvolver softwares com qualidade significa:
“alinhamento total entre as necessidades/expectativas dos usuários e especificações geradas.
Alinhamento total entre as especificações aprovadas e o produto construído, e o produto final
com a menor quantidade de erros possíveis.”.
Segundo Hetzel (1987), através do teste consegue-se adquirir confiança no fato de
que um sistema pode ser usado com uma margem de risco aceitável, descobrir erros e
deficiências de um sistema, determinar os recursos do sistema e fornecer informações sobre a
qualidade de um software.
Segundo Casimiro (2011), investindo em teste de software pode-se reduzir em
70% o índice de retrabalho de correções de falhas de produção, reduzir em 50% do tempo de
homologação de uma nova versão, aumentar em 90% o índice de falhas detectadas antes da
produção, diminuir em 95% a terminação anormal de um processo, e aumentar a abrangência
dos testes.
O investimento em teste é de suma importância para garantir uma boa qualidade
no software, porém os testes manuais nem sempre atendem com rapidez e eficácia as
expectativas. Contudo, automatizar alguns processos e etapas do teste pode agilizar a
execução do mesmo, tendo em vista que o teste manual estará sempre exposto a falhas pelo
fato de serem executados por seres humanos.
Para Bartié (2002), a automação de testes requer um esforço inicial, porém
fornece eficiência, rapidez e confiabilidade que pode não ser atingida com procedimentos
manuais.

17
No processo de desenvolvimento de software a automatização funciona como
recurso para a redução no esforço em atividades de testes manuais, que, por muitas vezes, são
repetitivas. Por fim, permite a execução automática de rotinas de teste com o objetivo de
aumentar a qualidade do produto e minimizar falhas humanas.
As seções seguintes explanam a respeito da problemática levantada para o estudo
de caso, os objetivos que se pretende alcançar, uma justificativa para a escolha do tema e a
estrutura da presente monografia.
1.1 PROBLEMÁTICA
Na década de 60, os softwares eram desenvolvidos de forma primitiva não
havendo organização ou planejamento. No processo de construção de uma aplicação havia
muitas dificuldades, pois a demanda e a complexidade dos sistemas cresciam. De acordo com
o engenheiro de software norte-americano Pressman (2004), os problemas que ocorriam
tinham relação com a organização das equipes, uma vez que estas não possuíam total
conhecimento técnico para desenvolver, prestar suporte e dar manutenção em uma solução.
Faltava uma correta análise de requisitos somada a poucos investimentos na questão da
qualidade do sistema.
Apesar das práticas errôneas serem reconhecidas e apontadas, muitas delas ainda
perduram nos tempos atuais. Segundo Koscianski e Soares (2007, p. 172), “sem uma
definição precisa daquilo que se pretende construir, perde-se tempo, mais erros são cometidos
e a qualidade do produto final é incerta”.
Como forma de sanar os problemas e buscar uma solução para a crise, os
princípios da Engenharia de Software foram criados e difundidos. De acordo com Pressman
(2004), todas as deficiências na elaboração e construção de um sistema começaram a ser
sanadas com o surgimento do conceito de Engenharia de Software que trouxe consigo a
oportunidade de novos rumos para as pesquisas em tecnologia.
Segundo o especialista na área e autor de diversos livros, Sérgio Luiz Tonsig
(2008), no ano de 1968, foi realizada uma conferência internacional na Alemanha cujo
objetivo era encontrar soluções para os problemas que assolavam o desenvolvimento de
software; foi a partir desta que o termo “Engenharia de Software” ficou conhecido.

18
Com a criação dos métodos, o desenvolvimento começou a ser executado e
construído em etapas. O primeiro modelo criado foi o Cascata que, segundo Pressman (2001),
é um modelo pesado e composto de atividades sequenciais para levantamento de requisitos,
análise, projeto, implementação, teste, implantação e manutenção.
Pode-se perceber que em grande parte dos métodos existe uma etapa de testes. O
escritor Pressman (2002) destacou que a prática de teste é um fator de extrema importância na
qualidade de uma aplicação, uma vez que representa a revisão das especificações.
Devido à importância dos testes, nas etapas de desenvolvimento, criou-se um
ciclo para o mesmo que é composto por procedimentos iniciais, planejamento, preparação,
especificação, execução e entrega.
No ciclo de execução do teste, o procedimento a ser seguido, geralmente, é
manual. O diretor da Associação Latino-Americana de Teste de Software (ALATS),
Anderson Bastos et al. , destacou em seu livro Base de conhecimento em teste de software
(2007), que os testes devem ser executados por regressão ou por partes toda vez que surgirem
alterações nas aplicações ou novas versões e devem possuir ambiente preparado para tal
rotina.
O teste de regressão tem a necessidade de ser repetitivo e executado a cada
correção de erro ou em caso de novas implementações no sistema. De acordo com Pressman
(2006), o software é modificado cada vez que um novo módulo ou uma nova funcionalidade é
adicionado. Essa modificação pode gerar problemas que não existiam. Por isso, há a
necessidade de executar testes novamente após a realização de modificações para garantir que
não existam efeitos colaterais indesejáveis. Para este tipo de rotina dá-se o nome de testes de
regressão.
Como visto, a quantidade de testes que precisam ser efetuados, muitas vezes, de
forma manual e a necessidade de executar o teste de regressão a cada nova implementação,
transforma a atividade em algo repetitivo. Outros problemas podem ser apontados, tais como:
repetição das mesmas rotinas de teste que torna o serviço oneroso e lento, o tempo gasto na
sua execução e as falhas humanas que podem ocorrer.
Para diminuir a quantidade (custo) dos esforços e minimizar o tempo de execução
dos testes, faz-se necessário a automatização dos testes de regressão.
Em função do que foi exposto, a seguinte pergunta é apresentada: É possível
minimizar custo/esforço e economizar tempo automatizando os testes de software?

19
1.2 OBJETIVOS
Serão apresentados a seguir os objetivos gerais e específicos dessa monografia.
1.2.1 Objetivo geral
Verificar as contribuições dadas pelo uso do framework Selenium ao processo de
automação de testes de regressão a partir de um estudo de caso.
1.2.2 Objetivos específicos
Os objetivos específicos estão descritos a seguir:
• Utilizar uma aplicação web, já existente, como cenário para o estudo de
caso;
• Elaborar os casos de teste para efetuar o teste de regressão de maneira
manual;
• Desenvolver os testes automatizados para atender o cenário proposto;
• Comparar os resultados obtidos a partir do teste de regressão de maneira
manual e automatizado utilizando o framework Selenium.
1.3 JUSTIFICATIVA
A crise de software tornou-se um marco na história do desenvolvimento de
softwares, pois até então essa tarefa era executada de maneira desorganizada, com

20
pouquíssima documentação e sem planejamento, o que culminava em um produto final de
baixa qualidade.
Foi nesse contexto que surgiu a necessidade de modificar esse processo de
desenvolvimento de aplicações, tornando-o mais estruturado, padronizado, documentado e
com um planejamento coerente para que, dessa forma, as necessidades do cliente fossem
atendidas corretamente.
Os testes de software ocorriam integrados ao desenvolvimento, conforme Bastos
et al. (2007, p.11), “Durante as décadas de 1970, 1980 e 1990, os testes eram efetuados pelos
próprios desenvolvedores do software, cobrindo aquilo que hoje chamamos de testes unitários
e testes de integração”.
A qualidade do produto não era assegurada, pois muitos problemas eram
encontrados somente quando os sistemas já se encontravam em produção, tornando sua
correção muito mais cara e onerosa. Ainda de acordo com Bastos et al. (2007), os defeitos de
um software representam um risco para uma organização e pode afetar diretamente a sua
imagem perante seus clientes. Devido a esses fatores os testes começaram a ter uma
importância maior, contribuindo diretamente na qualidade dos produtos.
Como forma de garantir a eficácia de uma aplicação, os testes precisaram ser um
processo paralelo e executado por especialistas na área.
Com o passar dos anos e a adoção cada vez maior dessa prática, diversas
ferramentas surgiram para auxiliar no procedimento dos testes. Notou-se que, em
determinados tipos de teste, a rotina era onerosa e repetitiva e que em algumas situações nem
todos os defeitos do produto eram encontrados previamente, devido à falha humana no
processo de testar. Uma das formas de sanar essa lacuna é o uso de ferramentas que
automatizem as rotinas.
Conforme Bastos et al. (2007) existem recursos computacionais para criação de
dados para testes. Eles apuram tanto as variáveis normais para cada elemento de dado quanto
às variáveis anormais e possíveis erros. É nesse contexto que os autores desse trabalho
pretendem apresentar o framework 1
Selenium, com intuito de utilizá-lo para automatização do
teste de regressão.
O presente trabalho possui uma relevância tanto do ponto de vista pessoal para
seus autores, uma vez que lhes agrega conhecimento a respeito de um tema que é do interesse
1
Para Fayad et al (1999), um framework é um conjunto de classes que constitui um projeto abstrato para a
solução de uma família de problemas.

21
de ambos, quanto para a empresa em que trabalham, pois irá aprimorar e otimizar as rotinas
de teste.
1.4 ESTRUTURA DA MONOGRAFIA
O trabalho é apresentado sistematicamente na seguinte estrutura:
Capítulo 1 – Apresenta uma introdução do assunto com uma problemática, os
objetivos e a justificativa.
Capítulo 2 – Contém uma revisão bibliográfica que possui como foco principal a
área de testes de software e sua automatização.
Capítulo 3 – Nesse é descrito o método utilizado, as etapas e delimitações.
Capitulo 4 – Esse capítulo tem como função apresentar as informações sobre a
modelagem do protótipo de software desenvolvido para a aplicação dos testes automatizados
e manuais.
Capítulo 5 - Desenvolvimento da aplicação de automação de testes utilizando o
framework Selenium e elaboração dos casos de teste para o mesmo. Nessa etapa também será
apresentada a modelagem para o software que será testado.
E, por fim, o Capítulo 6 que possui as conclusões da monografia e ideias para
trabalhos futuros.

22
2 REVISÃO BIBLIOGRÁFICA
Esse capítulo dedica-se a apresentar a fundamentação teórica a respeito dos temas
que cercam a Engenharia de Software, dentre eles serão abordados: a crise de software, os
métodos de desenvolvimento, a prática e os tipos de testes e a automatização dos mesmos.
2.1 A CRISE DE SOFTWARE
Após o surgimento dos sistemas operacionais, que dentre suas inúmeras vantagens
trouxe a possibilidade de integração entre hardware e software, a atividade de programação
de aplicativos tornou-se mais viável, uma vez que ambos foram mais amplamente difundidos.
As interfaces começaram a ficar mais amigáveis para os usuários e os computadores pessoais
tornaram-se mais acessíveis, fazendo parte da rotina tanto das empresas quanto das pessoas
em suas casas.
A evolução dos computadores aconteceu de maneira rápida e isto gerou alguns
problemas, já que o desenvolvimento de software não acompanhou da forma mais correta esta
nova realidade.
Segundo Dijkstra (1972):
A maior causa da crise do software é que as máquinas tornaram-se várias ordens de
magnitude mais potentes! Em termos diretos, enquanto não havia máquinas,
programar não era um problema; quando tivemos computadores fracos, isso se
tornou um problema pequeno e agora que temos computadores gigantescos,
programar tornou-se um problema gigantesco. (DIJIKSTRA, 1972 apud
KOSCIANSKI; SOARES, 2007, p. 21).
O termo “crise do software” surgiu por volta da década de 60 e abrange todo o
conjunto de problemas e deficiências no processo de desenvolvimento de um aplicativo
(definição, codificação, implantação e manutenção). (MAFFEO, 1992).
Na época as aplicações eram desenvolvidas sem um método que as guiasse, ou
seja, a construção do software era desorganizada e não seguia padrões de boas práticas,
tampouco havia a preocupação com a qualidade do que estava sendo entregue ao cliente final.
Isto acarretou em problemas diversos, tais como: a baixa qualidade, os atrasos frequentes no

23
projeto, a falta de atendimento aos requisitos do cliente, que gerava manutenções constantes,
dentre outros.
Segundo Deek et al (2005), os fracassos de projeto; as perdas econômicas; os
atrasos na entrega; o mercados competitivos e uma exigência crescente para a qualidade e
confiabilidade de um aplicativo sem custos abusivos impulsionaram a criação de diversas
práticas para tentar solucionar estes gargalos. A partir dessas necessidades surgiu o que
conhecemos atualmente como “Engenharia de Software”.
2.2 ENGENHARIA DE SOFTWARE
O termo ficou conhecido a partir da década de 60 e segundo Koscianski e Soares
(2007) uma das primeiras vezes que se utilizou o tema “Engenharia de Software”, foi em uma
conferência realizada em 1968, na Alemanha, por uma entidade que a princípio não possuía
relação com a área e que se chamava Comitê de Ciência da NATO (North Atlantic Treaty
Organisation – Organização do Tratado do Atlântico Norte).
Segundo Pressman (1995, p.31):
A engenharia de software é um rebento da engenharia de sistemas e de hardware.
Ela abrange um conjunto de três elementos fundamentais – métodos, ferramentas e
procedimentos – que possibilita ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para a construção
de software de alta qualidade produtivamente.
A fim de associar o termo Engenharia ao conceito de desenvolvimento das
aplicações, o IEEE (Institute of Electrical and Electronics Engineers – Instituto de
Engenheiros Elétricos e Eletrônicos), que é a maior associação profissional do mundo
dedicada a avanços tecnológicos, no ano de 1990, destacou que a Engenharia de Software
possuía uma abordagem sistemática, disciplinada e quantificada ao desenvolvimento,
operação e manutenção de software.
Esta engenharia é dividida em camadas, que possuem como foco principal a
qualidade final do produto. O meio para se chegar até esse objetivo é o constante
aperfeiçoamento do processo de desenvolvimento, que consiste na criação de documentos,
artefatos e marcos que são capazes de representar o contexto do software, levando em

24
consideração recursos, ferramentas, prazos, restrições e outros aspectos que envolvem o
desenvolvimento de uma aplicação (PRESSMAN, 2002).
Como ferramental da Engenharia de Software, elaborou-se as metodologias de
desenvolvimento de software, que são apresentadas com mais detalhes na próxima seção.
2.2.1 Metodologias de Desenvolvimento
O uso de metodologias de desenvolvimento de software pelas organizações
representa uma resposta aos problemas encontrados na concepção de sistemas e também
busca atender às camadas de controle da Engenharia de Software. Conceitualmente, elas são
um conjunto de atividades que apoiam a produção de aplicações. Outra definição dada pelo
autor, acadêmico e consultor na área Ian Sommerville (2003) é a de que modelar um processo
pode ser entendido como “uma representação abstrata [...]. Cada modelo de processo
representa um processo a partir de uma perspectiva particular, de uma maneira que
proporciona apenas informações parciais sobre o processo” (SOMMERVILLE, 2003, p.36).
Segundo Koscianski e Soares (2007), as metodologias podem ser classificadas em
dois grupos: as metodologias tradicionais, que possuem como foco a documentação de cada
etapa do desenvolvimento do software e as metodologias ágeis que são adequadas nos casos
em que a mudança dos requisitos é frequente.
O autor Ian Sommerville (2003) destaca que, mesmo existindo diversas
metodologias para o desenvolvimento, algumas etapas são comuns a todas elas, tais como:
• Especificação: trata-se da definição do funcionamento e características
da aplicação;
• Projeto e Implementação: esta etapa contempla a produção de
diagramas, de acordo com as especificações feitas pelo cliente, que serão
implementados através de linguagens de programação;
• Validação: fase de testes no produto e revisão dos requisitos;
• Evolução: atividades de manutenção na aplicação. Nesse passo ocorre a
adaptação às novas necessidades solicitadas pelo cliente.
As principais metodologias serão apresentadas, de maneira mais detalhada, nas
seções seguintes.

25
2.2.1.1 Metodologias Tradicionais
As metodologias tradicionais também são conhecidas como orientadas à
documentação, pois surgiram de um paradigma de desenvolvimento de software distinto do
que vivemos atualmente, uma vez que eram baseados apenas em mainframes e terminais
(ROYCE, 1970).
Na época, o custo de fazer alterações e correções era muito alto, uma vez que o
acesso aos computadores era limitado e não existiam ferramentas de apoio ao
desenvolvimento do software, como depuradores e analisadores de código. Em razão
disso, o software era todo planejado e documentado antes de ser implementado.
(KOSCIANSKI; SOARES, 2007, p. 191).
Para Pressman (2002), as metodologias tradicionais são aplicadas aos casos em
que os requisitos não sofrem alterações no decorrer do projeto de software.
Dentre os modelos tradicionais encontram-se o clássico ou cascata, o incremental,
a prototipação e o espiral.
2.2.1.1.1 Modelo clássico
O modelo clássico, que também ficou conhecido como cascata, é o mais antigo e
difundido na engenharia de software (PRESSMAN, 1995). Ele traz consigo um paradigma de
desenvolvimento sequencial e possui uma abordagem sistemática.
Na figura 1, pode-se observar o ciclo de desenvolvimento clássico com suas
atividades.

26
Figura 1 – Atividades do modelo cascata
Fonte: Adaptado de Pressman (1995, p. 33)
Para Pressman (1995), este modelo, com o passar dos anos, sofreu severas críticas
e foi colocado em dúvida a sua aplicabilidade, já que os projetos raramente seguem o fluxo
sequencial que o modelo propõe. De acordo com Koscianski e Soares (2007), quanto maior
for a progressão do desenvolvimento do projeto, maior será também o custo das alterações no
mesmo. A figura 2 exemplifica essa situação.
Figura 2 - Custo de modificação
Fonte: http://imasters.com.br/artigo/18732/agile/sem-boas-praticas-de-engenharia-nao-ha-
agilidade

27
Segundo Koscianski e Soares (2007, p.192), “o modelo clássico dominou a forma
de desenvolvimento de software até o início da década de 1990, apesar das advertências dos
pesquisadores da área e dos desenvolvedores, que identificaram os problemas gerados ao se
adotar essa visão sequencial de tarefas”.
Embora esse modelo possua alguns pontos negativos, serviu como base para
diversos paradigmas, que surgiram na sequência além de ser uma solução para a abordagem
informal de desenvolvimento que culminou na crise.
2.2.1.1.2 Modelo Incremental
O modelo incremental derivou do modelo cascata. Esse modelo possui como
conceito principal o desenvolvimento de forma incremental, onde em cada incremento novas
funcionalidades serão adicionadas e modificações podem ser inseridas até que o produto seja
finalizado.
Para Sommerville (2003):
Uma vez identificados os incrementos, os requisitos para as funções a serem
entregues no primeiro incremento são definidos em detalhes, e esse incremento é
desenvolvido [...] Durante esse desenvolvimento, outras análises de requisitos para
os incrementos seguintes podem ocorrer, mas as mudanças nos requisitos para o
incremento atual não são aceitas (SOMMERVILLE, 2003, p.44).
A cada conclusão de um incremento uma prévia é enviada ao cliente, que pode
colocar o sistema em operação.
A figura 3 ilustra o método de desenvolvimento incremental.

28
Figura 3 - Modelo Incremental
Fonte: http://inf.unisul.br/~vera/egs/aula01.htm
De acordo com Sommerville (2003, p.44), “os incrementos dever ser
relativamente pequenos” onde em cada um deve haver uma funcionalidade. Nesse modelo os
requisitos não são detalhados até que a implementação esteja concluída, o que dificulta o
mapeamento dos requisitos solicitados pelo cliente.
2.2.1.1.3 Prototipação
A prototipação é um processo que possibilita ao desenvolvedor criar um modelo
da aplicação que será implementada. (PRESSMAN, 1995).
O mesmo autor ainda afirma que esse modelo pode assumir três formas:
1. O protótipo em papel que apresenta a interação homem-máquina para que
o usuário entenda o processo de interações que irão ocorrer no projeto;
2. Um protótipo de trabalho que mostra uma parte do software;
3. Uma aplicação que executa uma prévia da funcionalidade solicitada pelo
cliente.
A figura 4 apresenta a sequência de atividades para o modelo de prototipação.

29
Figura 4 - Atividades da Prototipação
Fonte: Pressman (1995, p. 36)
O protótipo geralmente serve como uma visão prévia do sistema e se torna muito
útil na identificação de requisitos. (PRESSMAN, 1995).
Assim como o modelo cascata, esse também possui fragilidades e uma delas, na
opinião de Pressman (1995), é a de que o cliente geralmente confunde o protótipo com uma
versão de trabalho e acaba exigindo que o mesmo se torne o produto final.
Ainda que possam ocorrer problemas, a prototipação é um paradigma eficiente da
engenharia de software. A chave é definir-se as regras do jogo logo no começo; ou
seja, o cliente e o desenvolvedor devem ambos concordar que o protótipo seja
construído para servir como um mecanismo a fim de definir os requisitos. Ele será
depois descartado [...] (PRESSMAN, 1995, p.38)
Na seção seguinte, será apresentado o modelo espiral, que surgiu como forma de
unir os pontos positivos tanto do modelo cascata quanto do modelo de prototipação.

30
2.2.1.1.4 Modelo espiral
O modelo espiral surgiu como solução às fragilidades de seus antecessores. Ele
representa o processo como uma espiral, onde cada volta indica uma fase do projeto. Nesse
modelo há um novo elemento: a análise de risco.
De acordo com Sommerville (2003), “os riscos resultam em problemas no projeto,
como a possibilidade de exceder no prazo e no custo previstos; portanto, minimizar riscos é
uma atividade de gerenciamento de projeto muito importante”. (SOMMERVILLE, 2003,
p.46).
Na figura 5 observam-se as iterações do modelo em questão.
Figura 5 - Iterações do modelo espiral
Fonte: Pressman (1995, p.39)
As iterações nesse modelo iniciam-se no centro e avançam para fora da espiral,
sendo que em qualquer etapa da evolução é possível obter protótipos.

31
De acordo com Pressman (1995), o modelo espiral pode ser utilizado como forma
de refinar os requisitos, simulações e o auxílio de outros modelos de desenvolvimento.
Segundo Sommerville (2003):
Não há fases fixas, como especificação ou projeto, no modelo em espiral. [...] A
prototipação pode ser utilizada em uma espiral para resolver dúvidas relativas aos
requisitos e, portanto, reduzir riscos. Essa fase pode ser seguida por um
desenvolvimento em cascata convencional. (SOMMERVILLE, 2003, p.46).
Na próxima seção será apresentada a definição e as principais metodologias ágeis
de desenvolvimento.
2.2.1.2 Metodologias Ágeis
Em fevereiro de 2001, um grupo denominado Aliança Ágil, que era formado por
dezessete pesquisadores dentre eles praticantes de diversas metodologias de desenvolvimento,
assinou em Utah, nos EUA, o Manifesto para o Desenvolvimento Ágil de Software.
De acordo com Ambler (2004, p.23), esse manifesto continha quatro declarações:
Indivíduos e iterações valem mais que processos e ferramentas; um software
funcionando vale mais que documentação extensa; a colaboração do cliente vale
mais que negociação de contrato; responder às mudanças vale mais que seguir um
plano.
Para Koscianski e Soares (2007, p.194):
O Manifesto Ágil não rejeita processos e ferramentas, documentação, negociação de
contratos nem planejamento, mas simplesmente mostra que estes tem importância
secundária quando comparados com os indivíduos, com o software executável, com
a colaboração dos clientes e as respostas rápidas às mudanças.
Esse novo conceito de gestão e desenvolvimento de software possui dentre suas
características a divisão do problema em produtos menores, uma maior interação entre equipe
e cliente e são mais adaptáveis a mudanças. De acordo com Koscianski e Soares (2007,
p.193), “As metodologias ágeis são adequadas para situações em que a mudança de requisitos
é frequente. Para ser realmente considerada ágil, a metodologia deve aceitar a mudança em
vez de tentar prever o futuro”. Dessa forma, o foco da metodologia não é a mudança em si,

32
mas, sim como a equipe irá responder às modificações dos requisitos de um software que
serão frequentes durante o processo de desenvolvimento.
O custo das mudanças no decorrer do projeto de uma aplicação é inferior quando
se utilizam metodologias ágeis. A curva da figura 6 cresce menos ao longo do tempo se
comparada com a da figura 2, que expressava os custos de modificação no modelo cascata. De
acordo com Soares (2004), as metodologias ágeis “... incentivam a mudança nos requisitos,
pois dessa forma é possível realmente entregar ao cliente o produto que ele precisa”.
Figura 6 - Custo de mudanças nas metodologias ágeis
Fonte: Soares (2004)
Na opinião de Koscianski e Soares (2007), as metodologias ágeis mais conhecidas
são a Extreme Programming e a Scrum, ambas serão descritas a seguir:
2.2.1.2.1 Extreme Programming (XP)
A Extreme Programming (XP) possui como foco equipes de desenvolvimento
pequenas e médias e são utilizadas nos casos em que os requisitos sofrem diversas
modificações.

33
Para Koscianski e Soares (2007), as principais características que diferem a XP
das demais metodologias são:
• Comunicação entre os envolvidos é constante;
• O Feedback está sempre presente;
• Abordagem incremental.
A XP utiliza práticas que, à primeira vista, podem parecer incomuns e elas devem
ser aplicadas em forma de conjunto, pois isoladamente não possuem o mesmo efeito.
Para Astels, Miller e Novak (2002), as principais atividades ou “princípios
extremos” da Extreme Programming são:
• Cliente sempre presente: O cliente deve participar ativamente do projeto,
sanando as dúvidas referentes aos requisitos, tomando decisões e
fornecendo o feedback sobre o produto;
• Uso de metáforas: Trata-se de uma representação de um recurso ou
conceito no desenvolvimento do produto, minimizando o uso de alguns
termos técnicos, tornando mais simples o entendimento do problema.
• Planejamento: Os projetos necessitam de um planejamento inicial. A
princípio ele não necessita de muito detalhamento, basta que se tenha
conhecimento dos riscos, o caminho a ser percorrido e o que será feito
para que se alcance o objetivo. O cliente fica responsável pela tomada de
decisões sobre os problemas dos negócios e a equipe de desenvolvimento
possui como responsabilidade a parte técnica.
• Reuniões curtas: As reuniões devem ser breves e diárias, onde o que será
discutido são as atividades que cada membro desempenhou no dia
anterior.
• Testes: A validação do projeto ocorre durante todo o processo. Os testes
são escritos antes do código e uma tarefa não pode ser concluída até que
não haja um conjunto de casos de teste para a mesma.
• Projeto simplificado: A aplicação deve atender aos requisitos atuais. O
projeto deve ser compreensível e o código sucinto.
• Programação em pares: O software deve ser desenvolvido por uma dupla
de programadores, ou seja, ambos trabalharão no mesmo computador.

34
• Código padronizado: A equipe deve adotar um conjunto de padrões para
o código, onde todos os membros devem concordar e seguir.
• Propriedade coletiva: O código da aplicação pertence a todos os
membros da equipe. Dessa forma, todos possuem acesso e são
responsáveis pelo mesmo.
• Integração contínua: o código produzido, depois de ser testado e validado,
será integrado ao sistema que, por sua vez, deve ser testado a cada nova
integração. Assim, o produto é construído de forma gradativa.
• Refatoração: É a melhoria do software internamente sem afetar a estrutura
externa. É uma forma de simplificar o código e minimizar a chance de
defeitos.
• Releases em incrementos pequenos: São versões pequenas do produto
que serão entregues ao cliente. Desse modo, ele fornece o feedback
constante a respeito do software.
• Trabalho semanal de 40 horas: Para a XP o funcionário deve trabalhar
até 40 horas por semana, evitando horas extras.
• Alterações: A equipe deve ser flexível às mudanças que irão ocorrer nos
requisitos do projeto.
A XP, assim como as demais metodologias, possui características positivas e
negativas que deverão ser levadas em consideração pelos gestores no momento de sua
implantação.
Na seção seguinte, será apresentada outra metodologia ágil bastante difundida
atualmente: o Scrum.
2.2.1.2.2 Scrum
O Scrum surgiu em 1990 e foi criado por Jeff Sutherland e sua equipe. De acordo
com Pressman (2006), essa metodologia, assim como o XP, é ideal para projetos que possuam
alterações constantes e prazos curtos.

35
Para Soares (2004, p.5) “a Scrum apresenta uma abordagem empírica que aplica
algumas ideias da teoria de controle de processos industriais para o desenvolvimento de
softwares, reintroduzindo as ideias de flexibilidade, adaptabilidade e produtividade”.
Essa metodologia é semelhante ao XP no que diz respeito ao tamanho das equipes
e a instabilidade dos requisitos.
Dentre os itens característicos do Scrum, está o backlog que seria uma lista com as
pendências, requisitos ou características do projeto. O gerente do projeto avalia quais são as
prioridades, à medida que novos itens são inseridos no escopo. (PRESSMAN, 2006).
O desenvolvimento é feito em ciclos iterativos chamados de sprints, que possuem
duração de até trinta dias com a definição das tarefas de cada membro. As equipes são
chamadas de times e possuem até dez pessoas. As reuniões são curtas, com no máximo 15
minutos, e devem ser executadas diariamente. (KOSCIANSKI; SOARES, 2007).
Dentro de cada time existe um Scrum Master que possui como responsabilidades:
a aplicação dos conceitos do Scrum, conduzir as reuniões, incentivar a colaboração dos
colaboradores dentro do time e minimizar os impedimentos.
A figura 7 ilustra o funcionamento do Scrum.
Figura 7 - Funcionamento do Scrum
Fonte: http://www.heptagon.com.br/scrum
De acordo com Koscianski e Soares (2007), o Scrum possui três fases principais:

36
• Pré-planejamento (pre-game phase): os requisitos encontram-se
ordenados por prioridade no backlog. Nessa fase será definida a equipe de
desenvolvimento, as ferramentas para o mesmo, a identificação das
ameaças para o projeto e possíveis treinamentos.
• Desenvolvimento (game phase): É a fase de construção do software em
sprints onde são controlados os riscos e novas funcionalidades serão
inseridas. O desenvolvimento segue uma métrica: análise, projeto,
implementação e testes.
• Pós-planejamento (post-game phase): Na etapa de pós-planejamento são
executados os testes finais, a integração da aplicação e a documentação
que será entregue ao usuário. Nessa fase são realizadas reuniões para
finalizar o sprint e apresentar o projeto atual para o cliente.
O Scrum fornece uma divisão de tarefas de forma clara, prioriza a comunicação
entre os membros do time, fornece soluções rápidas aos impedimentos que possam surgir,
dentre outras características.
2.3 TESTES DE SOFTWARE
O desenvolvimento de software não é uma tarefa simples de se desempenhar,
dependendo do tamanho e dimensão do problema essa atividade pode se tornar complexa e
custosa. Segundo os autores Delamaro, Jino e Maldonado (2007, p.1), a atividade de
desenvolvimento “[...] pode se tornar bastante complexa, dependendo das características e
dimensões do sistema a ser criado.”.
Além da complexidade na criação dos softwares, existe outro fator importante que
deve ser levado em consideração: a qualidade.
Segundo Pressman:
“Qualidade de software é a satisfação de requisitos funcionais e de desempenho
explicitamente declarados, normas de desenvolvimento explicitamente
documentadas e características implícitas que são esperadas em todo o software
desenvolvido profissionalmente.” (PRESSMAN, 2006, p. 349).

37
A qualidade é uma sequência metódica que possui etapas e ferramentas para que
se tenha um processo ou produto dentro de uma conformidade com a intenção de evitar e
eliminar falhas. (BARTIÉ, 2002).
Para obter qualidade no software desde o início de sua construção são necessários
investimentos. Para Molinari (2003, p. 22 e 23) “o custo total efetivo do gerenciamento de
qualidade é a soma dos quatro fatores: prevenção + inspeção + falha interna + falha externa.”.
A prevenção é o ato de identificar os erros antes que eles apareçam; já o custo de
inspeção tem como foco a medição, avaliação e auditoria dos produtos conforme os padrões e
especificações. O custo de falhas internas é identificado a partir dos testes. O custo de falhas
externa são falhas identificadas pelos clientes, que necessitam de correção.
De acordo com Müller et al (2007), os testes devem fornecer dados que possam
auxiliar a tomada de decisão dentro do projeto, para as fases seguintes do desenvolvimento de
um software ou até mesmo da sua implantação. Portanto, o êxito de um processo de testes
baseia-se em encontrar um defeito e corrigi-lo o quanto antes, assim, os custos de correção
serão menores.
Conforme ilustra a figura 8, o custo da correção de um erro é imensamente maior
quando o software já está em fase de produção.

38
Figura 8 - Custo de correção dos problemas
Fonte: Bastos et al. (2007, p. 19)
O conceito de qualidade está diretamente ligado à prática de testes, conforme
Bartié (2002, p.18) “na verdade, o processo de qualidade de software utiliza-se dos testes em
todo o ciclo de desenvolvimento, de forma a garantir tanto o processo de engenharia quanto o
produto de software desenvolvido.”.
Bartié (2002) afirma que durante o processo de desenvolvimento de software
existem duas fases principais. A primeira consiste em planejar e levantar as informações sobre
o sistema; nesse caso, aplicam-se os testes de verificação, e na segunda fase, onde já existe
um produto em construção executam-se os testes de validação.
A função da verificação é observar se o sistema está de acordo basicamente com
os requisitos funcionais e não funcionais já a validação é a etapa de verificar se a aplicação
está sendo construída da forma correta. Nesse caso, a mesma será avaliada e uma bateria de
testes será executada. (SOMMERVILLE, 2003).
“Os testes de verificação podem ser entendidos como um processo de auditoria de
atividades e avaliação de documentos gerados durante todas as fases do processo de
engenharia de software. As verificações devem ser aplicadas a todos os produtos
(documentos, gráficos, manuais, código-fonte) que são produzidas em cada etapa do

39
processo [...] A principal característica dos testes de verificação é o fato de não
envolver o processamento de softwares.” (BARTIÉ, 2002, p.37).
Os testes de validação podem ser entendidos como um processo formal de avaliação
de produtos tecnológicos que podem ser aplicados em componentes isolados,
módulos existentes ou mesmo nos sistemas como um todo [...] A característica dos
testes de validação é a presença física do software e de seu processamento em um
ambiente [...]. (BARTIÉ, 2002, p.38)
De acordo com Glen Myers citado por Pressman (1995, p. 788), existem três
regras que são os objetivos do teste:
1. A atividade de teste procura descobrir um erro na aplicação;
2. Para um caso de teste ser visto como bom ele deve ter uma grande probabilidade de
achar um erro ainda desconhecido;
3. Um teste que revela um erro ainda não descoberto é chamado de bem sucedido.
Nota-se com base nos objetivos acima citados que para uma atividade de teste ser
considerada bem sucedida, deve reportar o maior número possível de erros. Para Koscianski e
Soares (2007, p. 337) “o objetivo do teste é encontrar defeitos, revelando que o
funcionamento do software em uma determinada situação não está de acordo com o
esperado.”.
Müller et al (2007) defende que a rigorosidade nos testes em sistemas e nas
documentações colaboram para a redução dos riscos causados pela ocorrência de um
comportamento indesejado em ambiente operacional.
Na opinião de Rezende (1999, p.252), a prática de testes “[...] é de fundamental
importância no desenvolvimento de sistemas [...], ela pode garantir o sucesso do mesmo, pois
se todos os requisitos funcionais forem testados, provavelmente o cliente e/ou usuário estará
satisfeito”.
2.3.1 Técnicas para Teste de Software
Em algum momento do projeto de desenvolvimento de uma aplicação os
requisitos serão implementados e deverão estar de acordo com o que foi solicitado pelo
cliente. Nesse momento, os testes, para que essa validação seja feita, são colocados em prática
(BARTIÉ, 2002).

40
De acordo com Pezzè e Young (2008, p.30), “a escolha do conjunto de técnicas de
teste e análise depende das restrições de qualidade, custo, prazo e recursos no
desenvolvimento de um produto em particular”.
As técnicas para teste de software serão apresentadas nas seções seguintes.
2.3.1.1 Teste de unidade
Segundo Bartié (2002), a etapa de testes de unidade é a primeira a ser executada,
pois possui como meta testar partes individuais do sistema.
Esse tipo de teste está relacionado com a estrutura interna do software. Portanto, o
profissional que fará essa etapa deve possuir conhecimento do código; geralmente, são
realizados pelo próprio desenvolvedor.
Nessa estratégia de testes, o objetivo é executar o software de forma a exercitar
adequadamente toda a estrutura interna de um componente, como os desvios
condicionais, os laços de processamento e todos os possíveis caminhos alternativos
de execução. Desta forma, estaremos validando a estrutura interna do componente e
atestando a capacidade de processamento sob os mais variados cenários de
execução. (BARTIÉ, 2002, p.140)
O teste de unidade avalia algumas partes do código-fonte, buscando a validação
dos dados que serão armazenados, bem como a verificação do comportamento que a aplicação
apresentará no momento em que dados incorretos sejam inseridos. (INTHURN, 2001).
2.3.1.2 Teste de integração
Os testes de integração representam a continuidade dos testes unitários. Nessa
etapa, a função principal é avaliar a compatibilidade e integração entre os componentes do
sistema, pois, cada vez que uma alteração é feita, pode comprometer as demais partes da
aplicação. (BARTIÉ, 2002).
Para Molinari (2003) os testes de integração garantem o funcionamento da
aplicação como um conjunto das funcionalidades.

41
Bartié (2002, p.149) ainda afirma que esse tipo de teste valida “as interfaces entre
componentes da mesma arquitetura tecnológica. Essas [...] representam as trocas dinâmicas de
informações que ocorrem entre componentes durante a execução de um software”.
2.3.1.3 Teste de sistema
Os testes de sistema iniciam-se logo após o término dos testes de integração e
devem simular o ambiente, no qual essa aplicação irá ser instalada e validar todas as suas
funcionalidades.
De acordo com Bartié (2002, p.154), “como os testes de sistemas contam com
uma infraestrutura mais complexa de hardware (mais próximo do ambiente real de produção)
[...] deveriam concentrar-se mais nos aspectos de performance, segurança, disponibilidade,
instalação, recuperação, entre outros”.
Para Bastos et al. (2007) esta etapa só poderá ser finalizada quando a equipe de
testes aprovar a ida do software para a produção.
2.3.1.4 Teste de aceitação
Os testes de aceitação representam o último passo do processo de testes. Segundo
Bartié (2002), nessa parte o aplicativo será disponibilizado para o usuário que poderá verificar
se todas as funcionalidades previstas no planejamento inicial encontram-se no produto final.
O mesmo autor ainda faz uma ressalva: “assim como nos testes de sistema, os procedimentos
de aceite deverão ser realizados a cada ciclo de implementação da solução, permitindo
correções antecipadas [...]” (BARTIÉ, 2002, p.157).

42
2.3.1.5 Tipos de teste
Para a execução dos testes existem diversas técnicas, tais como: testes funcionais
ou caixa-preta que compreendem os testes de requisitos, testes de regressão, teste de
tratamento de erro e teste de interconexão; teste estrutural ou caixa-branca que abrangem o
teste de estresse, o teste de performance, o teste de recuperação e o de segurança; por fim,
existem os testes não funcionais que fazem parte destes o teste de usabilidade e o de
instalação.
A seguir são abordados os principais conceitos sobre estes tipos de testes.
2.3.1.5.1 Testes de caixa-preta
Segundo Rios e Trayahú (2006), os testes funcionais ou caixa-preta são realizados
sem que haja necessidade de ter conhecimento do código-fonte e se atentam apenas a
verificação dos requisitos.
Para Bartié (2002, p.105) “não é seu objetivo verificar como ocorrem
internamente os processamentos no software, mas se o algoritmo inserido [...] produz os
resultados esperados”.
A figura 9 ilustra a visão desse tipo de teste.

43
Figura 9 - Visão do teste caixa-preta
Fonte: adaptado de Bartié (2002, p. 107)
Fazem parte dos testes de caixa-preta: os testes de requisitos, testes de regressão,
testes de tratamento de erros e os de interconexão.
2.3.1.5.1.1 Testes de requisitos
Os testes de requisitos, como o próprio nome já diz, atentam-se exclusivamente
aos requisitos solicitados pelo cliente ou usuário final do sistema. Para Bartié (2002, p.107)
“são baseados nos documentos de requisitos e modelados através de especificações funcionais
e suplementares”.
Por pertencerem ao grupo dos testes funcionais não necessitam de conhecimento
da estrutura interna da aplicação.

44
2.3.1.5.1.2 Testes de regressão
As aplicações sofrem constantes modificações, novos módulos são inseridos e
funcionalidades são adicionadas. Cada alteração dessas podem gerar problemas no software.
Nesse caso, há a necessidade da execução de testes após cada nova implementação, como
forma de prevenção para efeitos colaterais indesejáveis. Os testes de regressão são aplicados
toda vez que o produto é modificado.
Segundo Young (2008, p. 454), “algumas vezes mesmo uma pequena alteração
pode produzir resultados inesperados que levam a falhas”. O mesmo autor ainda destaca que a
regressão basicamente é o processo de executar repetidamente os casos de teste que foram
criados para o software.
Esse tipo de teste pode ser subdivido em dois subgrupos: regressão total e
regressão parcial.
Segundo Alexandre Bartié (2002), os testes de regressão total são realizados sem
exceções, trata-se de um processo sem riscos, porém com custo elevado “[...] Essa escolha
deve estar baseada em uma análise crítica na relação custos versus riscos e em um bom
processo de rastreabilidade de requisitos” (BARTIÉ, 2002, p.197).
Os testes de regressão parcial são executados a partir de um subconjunto dos
casos de teste. Para Bartié “esse subconjunto deve ser identificado através de uma afinidade
de negócio existente entre os casos de teste e as alterações realizadas”. (BARTIÉ, 2002,
p.197). Esse tipo de teste possui custos menores, porém o risco de algum caso de teste
importante deixar de ser selecionado é alto, tornando o processo frágil.
Segundo Young (2008, p. 454), destaca uma característica importante quando são
utilizados os testes de regressão:
Alterações na versão do software podem influenciar no formato das entradas e
saídas e os casos de teste podem não ser executáveis sem as alterações
correspondentes. Mesmo modificações simples nas estruturas de dados [...] podem
invalidar os casos iniciais ou os resultados comparáveis com os novos. Além disso,
alguns casos de teste podem ficar obsoletos uma vez que testam funcionalidades do
software que foram modificadas, substituídas ou removidas na nova versão.
Por se tratar de uma atividade repetitiva, nos últimos anos tem-se falado em
automação dos testes de regressão. Esse tema será explicado na seção 2.3.2.

45
2.3.1.5.1.3 Testes de tratamento de erros
Os testes de tratamento de erros, como o próprio nome indica, é a capacidade que
a aplicação possui para tratar e prevenir os possíveis erros que ocorram.
De acordo com Bastos et al. (2007), o responsável por esse tipo de teste deve
possuir como foco: verificar se as condições de erro são reconhecidas pelo sistema, observar
se a responsabilidade pelo processamento do erro foi atribuída ao componente correto e
visualizar o controle que o software possui sobre os erros que surgem no decorrer do
processo.
2.3.1.5.1.4 Testes de interconexão
Os testes de interconexão garantem o funcionamento de aplicações conectadas a
outros softwares. De acordo com Bastos et al. (2007, p. 64), “Os testes de interconexão
devem ser conduzidos sempre que existir uma mudança nos parâmetros entre softwares de
aplicações.”.
2.3.1.5.2 Teste de caixa branca
De acordo com Pressman (1995, p. 793), “o teste de caixa branca é um método de
projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar
casos de teste.”.
Esse tipo de teste também é conhecido como estrutural e, nesse caso, o analista
possui conhecimento do software e de suas estruturas internas. Dessa forma, ele pode escolher
quais componentes serão testados, agregando mais precisão ao teste. (KOSCIANSKI;
SOARES, 2007, p. 343).
A figura 10 apresenta uma visão dos testes de caixa-branca.

46
Figura 10 - Visão do teste caixa-branca
Fonte: Adaptado de Bartié (2002, p. 107)
Os testes de caixa-branca englobam: testes de estresse, teste de performance, teste
de recuperação e o teste de segurança.
2.3.1.5.2.1 Testes de estresse
De acordo com Koscianski e Soares (2007, p. 347), “O teste de estresse é
realizado para submeter o software a situações extremas.”. O mesmo autor afirma que esse
tipo de teste é muito utilizado em aplicações onde a eficiência seja um requisito importante
como nos seguintes casos, por exemplo:

47
• Servidores web que recebem solicitação de diversos usuários;
• Na indústria;
• Jogos para computador.
2.3.1.5.2.2 Testes de performance
Nesse tipo de teste ocorre uma comparação entre a quantidade de transações
efetuadas e o tempo de resposta do sistema em condições extremas. O cenário deve ser
especificado com bastante atenção. Para Bartié (2002) os testes são executados, verificando-se
alguns itens:
• Levantar os requisitos de desempenho;
• Simular uma quantidade de usuários executando a mesma tarefa
simultaneamente;
• Simular a porcentagem de tráfego na rede.
2.3.1.5.2.3 Testes de recuperação
Os testes de recuperação “tem por objetivo avaliar o comportamento do software
após a ocorrência de um erro ou de determinadas condições anormais”. (BARTIÉ, 2002,
p.118). O mesmo autor destaca que uma maneira de simular erros, para esse caso, seria
interromper o acesso à rede ou ao processamento desligando o servidor, por exemplo. Isso
simula qual será a capacidade da aplicação recuperar os dados que estavam sendo processados
naquele momento.
2.3.1.5.2.4 Testes de segurança
Para Bartié (2002, p.116) os testes de segurança “tem por objetivo detectar falhas
de segurança que podem comprometer o sigilo e a fidelidade das informações, bem como
provocar perdas de dados ou interrupções de processamento”.

48
Nesse passo ocorre uma avaliação do software para que se possa saber qual o
nível de segurança para os dados que o mesmo oferece. Um exemplo disso seria tentar acessar
dados de nível gerencial com um perfil de usuário comum. A tentativa de descobrir senhas e
obter backups de informações sigilosas também são técnicas do teste de segurança.
2.3.1.5.3 Testes não-funcionais
Trata-se de outra categoria para teste, o International Software Testing
Qualifications Board (2007) não possui como objetivo a verificação de funcionalidades ou
requisitos, como nos testes de caixa preta ou branca. Nesse caso, observa-se itens como
usabilidade do sistema e o processo de instalação do mesmo.
2.3.1.5.3.1 Testes de usabilidade
O teste de usabilidade analisa os itens do software de acordo com a perspectiva do
usuário final.
Dessa forma, esses testes focalizam a facilidade de navegação entre as telas da
aplicação, a clareza de textos e mensagens que são apresentados ao usuário, o
volume reduzido de interações para realizar uma determinada função, padronização
visual, entre outros aspectos. (BARTIÉ, 2002, p.114).
O objetivo principal é mensurar a facilidade que o usuário terá em manipular o
software de modo intuitivo e simples. Para Bartié (2002) oferecer telas de ajuda também é
uma característica importante de usabilidade.
2.3.1.5.3.2 Teste de instalação
Como o próprio nome já descreve, deve-se verificar o processo de instalação da
aplicação. O ideal seria que o cliente também validasse esse processo.
Para Bartié (2002) pode ser interessante aplicar diversos tipos de instalação
simulando várias situações:

49
• Realizar a instalação pela primeira vez;
• Instalar o software em ambientes diferentes;
• Realizar a instalação da aplicação após a mesma já ter sido instalada;
• Verificar se a instalação atende os requisitos do cliente.
2.3.2 Automatização de Testes de Software
Testar um software é uma sequência de passos minuciosa que pode se tornar
cansativa. Uma alternativa para proporcionar a entrega de produtos confiáveis em menor
tempo é a realização de teste de software de maneira automatizada. (DUSTIN, 2002).
Segundo Pezzè e Young (2008), a automação pode melhorar a eficiência de
algumas das atividades de qualidade, como também se tonar uma necessidade para
implementações de futuras melhorias no processo de testes de software.
Assim, é necessário saber quando automatizar. Molinari (2003) cita que a
automação de teste faz-se necessário nas seguintes situações:
• Quando os testes que utilizam as técnicas de regressão ou de confirmação
repetem constantemente;
• Quando há o uso de testes aleatórios (testes “random” ou “monkey”) que
utilizam caminhos aleatórios gravados por dentro da aplicação e de grande
quantidade de dados de teste;
• Quando os testes de carga, volume, capacidade exigem muita gente para
simular e efetuar o teste;
• Quando se faz teste de componentes (unidade) os quais devem ser retestado
várias vezes.
Para efetuar a automação de testes, investimentos são imprescindíveis; esforços
como análise e planejamento são precisos para conseguir atingir esse objetivo. Molinari
(2003) destaca que automação de teste é um investimento alto, onde existe uma combinação
de pessoas, técnicas, processos, tempo e foco. Por conta desses investimentos, muitas

50
organizações não veem a automação de teste com bons olhos e, muitas vezes, essa alternativa
é descartada.
No mercado atual, existem ferramentas que auxiliam na automação de teste e que
visam diminuir o investimento na prática da automação. Molinari (2003), destaca que
investimentos empregados em automação consistem em escolha do tipo de ferramenta,
verificação na licença da ferramenta, hardware gasto na instalação das ferramentas,
treinamentos, manutenção nos scripts de teste e suporte ao fornecedor.
A seguir, serão expostas algumas ferramentas de automação existentes no âmbito
comercial, acadêmico e após serão exibidos as novas tendências de ferramentas.
2.3.2.1 Ferramentas para automação de teste
De acordo com Molinari (2003), existem ferramentas para automação de testes e
as mesmas são classificadas em dois grupos: as ferramentas comerciais e as acadêmicas.
Uma ferramenta comercial, para Molinari (2003, p.107), “[...] foca as
funcionalidades”. Abaixo, pode-se observar, no quadro 1, uma lista com sua classificação:
Quadro 1 - Ferramentas comerciais
Tipo Descrição
Test Design Ajuda na decisão da escolha do teste que
precisa ser executado
GUI Test Drivers & Capture/Replay Ajudam na execução de teste que façam uso
de uma “graphical user interface”,
independente se a aplicação será Web,
Client-Server, Java, dentre outros.
Load & Performance Ferramentas especializadas em dar “uma
carga pesada de dados” ao sistema, também
conhecido como ferramenta do “test-driver”.
Non-GUI Test Drivers & Test Managers Ferramentas de automação de execução dos
testes com uma interface gráfica. Podem
trabalhar com grandes suítes de testes.

51
Test Implementation Ferramentas que ajudam na implementação
dos testes. Um exemplo típico seria a geração
automática de sub-rotinas para tratamento de
falhas óbvias no programa.
Test Evaluation Ferramentas que ajuda a avaliar a qualidade
dos seus testes. A ferramenta de análise de
cobertura de código. (“code coverage”) seria
um exemplo.
Static Analysis Ferramentas que analisam o programa sem
executá-lo. Ferramentas de métricas
pertencem a esta categoria.
Defect Tracking Ferramentas que ajudam a gerenciar um
“banco de dados” com os defeitos
encontrados.
Fonte: Baseado em Molinari, 2002.
No caso da ferramenta acadêmica, Molinari (2003, p. 107) afirma que a mesma
“[...] foca a sua forma básica de concepção”. Sendo assim, no quadro 2, pode-se observar a
classificação da mesma:
Quadro 2 - Ferramentas acadêmicas
Tipo Descrição
Capture/Replay Captura os comandos executados por
usuários e os executam.
Code Auditors Análise e auditoria de código que está sendo
testado.
Debuggers Ferramentas típicas dos programadores, que
visam retirar erros básicos do código
desenvolvido.
Standards Checkers Ferramentas que permitem verificar padrões
de interface.
Structural Analyzers Ferramentas que permitem analisar a

52
estrutura de aplicação-alvo teste.
Test Coverage Analyzer Análises de cobertura de código.
Test Data Extraction Ferramenta de extração e verificação de
dados para teste.
Test Data Generators Ferramentas de geração de massas de dados
para teste.
Test Management Ferramenta de gerenciamento de teste.
Fonte: Baseado em Molinari, 2002.
2.3.2.2 Tendências para as ferramentas de automação
Segundo Molinari (2003), as novas tendências de ferramentas de automação de
testes estarão focadas em testes funcional, testes de regressão, testes de performance, testes de
carga, ferramentas que atende o planejamento de testes, testes de monitoração e ferramentas
de teste estrutural.
Segundo Fernandes (2006), no mercado, não existem ferramentas que suportam
todos os ambientes de operação de programas. É provável que nenhuma delas seja capaz de
atender todos os requisitos de uma organização, visto que múltiplas tecnologias são
empregadas em diversos projetos.
Conforme a evolução dos sistemas, novos mercados e ferramentas surgirão a
partir de uma boa análise das necessidades de testes e um bom planejamento, tornando-se
possível agregar valores e exibir ganhos efetivo para a organização. Segundo Foote e Yoder
apud Molinari (2003), “Se você pensa que uma arquitetura boa é cara, tente então uma má
arquitetura”.
Segundo Pezzè e Young (2008):
“O foco não está na escolha de um conjunto particular de “melhores” ferramentas
para todos os momentos e situações, mas na continuidade de um processo racional
de identificação e instalação de automações visando obter o melhor resultado à
medida que a organização, o processo e a tecnologia evoluem.”.

53
2.3.2.3 Automação de Teste x Teste de Regressão
Segundo Oliveira (2007, p.46), “um teste de regressão corresponde à re-execução
de um teste outrora realizado com sucesso sob um conjunto de funcionalidades do sistema.”.
A execução de testes de regressão tem o propósito de reavaliar o comportamento
do software, quando ocorrem modificações e a automatização do teste permite a identificação
rápida de defeitos, além de agilizar o processo de depuração e permitir a captura e análise dos
resultados de teste de forma consistente. (BINDER 1999).
Fernandes (2006) afirma que é comum presenciar a falsa expectativa de que todo
teste poderá ser automatizado mediante a compra de determinada ferramenta. Há casos em
que a automação não é possível ou é mais cara que a execução manual dos testes.
Os autores Pezzè e Young (2008) destacam que o julgamento e solução criativa de
problemas permanecem fora do domínio da automação, enquanto tarefas simples e repetitivas
normalmente são fáceis de automatizar.
É preciso, então, analisar e planejar quais os testes automatizar. Segundo Black
(2007) apud Oliveira (2007, p.47), existe algumas técnicas para selecionar subconjuntos de
testes de regressão e são elas:
• Uso de Rastreabilidade: identificar testes relacionados a descrições do
comportamento do sistema, como elementos de especificação de
requisitos, elementos de especificação de projeto ou análise de riscos;
• Uso de Análise de Mudança: nesse caso, devem ser analisadas descrições
estruturadas do sistema para descobrir como os efeitos de mudança se
propagariam através do sistema;
• Uso de Análise de Risco de Qualidade: priorizar testes que verificam áreas
de maior risco.
Para Dustin (2002) o conjunto de teste de regressão necessita ser automatizado e
deve ser executado em um ambiente estável para que sua execução seja aprimorada com o
mínimo possível de recursos. Caso os testes não sejam automatizados, a atividade de testes de
regressão torna-se excessivamente detalhada e repetitiva.

54
Um conjunto ou suíte de teste de regressão pode compreender tanto testes de
caixa-branca quanto testes caixa-preta. Uma prática comum quando se trabalha com
Integração Contínua é automatizar testes de caixa-branca, garantindo uma maior
confiabilidade ao código desenvolvido. (GOIS, 2007).
A automação de teste é um investimento que visa economizar custos futuros no
processo de desenvolvimento de software. Sabe-se que, para automatizar testes, são
necessários esforços. Contudo, o desafio da automação consiste em verificar custos,
identificar os benefícios e, principalmente, efetuar a escolha certa de quais testes serão
automatizados.

55
3 MÉTODO
Esse capítulo aborda a metodologia presente nessa monografia, apresentando o
tipo de pesquisa que será adotado, as etapas metodológicas da pesquisa, um esboço da solução
e as delimitações da pesquisa.
De acordo com Menezes e Silva (2005, p. 25), a metodologia científica pode ser
definida como “[...] o conjunto de processo ou operações mentais que se devem empregar na
investigação. É a linha de raciocínio adotada no processo de pesquisa”.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
De acordo com Menezes e Silva (2005, p. 20), “pesquisa é um conjunto de ações,
propostas para encontrar a solução para um problema, que têm por base procedimento
racionais e sistemáticos. A pesquisa é realizada quando se tem um problema e não se têm
informações para solucioná-lo”.
Existem diversas formas de se definir os tipos de pesquisas, dentre elas temos: a
pesquisa básica, aplicada, quantitativa, qualitativa, exploratória, descritiva, explicativa,
bibliográfica documental, experimental, levantamento, estudo de caso, expost-facto, ação e
participante. (MENEZES E SILVA, 2005, p. 20).
Esse trabalho classifica-se quanto à sua natureza como uma pesquisa aplicada,
quanto sua abordagem como pesquisa qualitativa, tendo como objetivos uma pesquisa
exploratória e de acordo com os procedimentos técnicos, classifica-se como pesquisa
bibliográfica e estudo de caso.
Segundo Menezes e Silva (2001, p. 20) “pesquisa aplicada objetiva gerar
conhecimento para aplicação prática dirigidos à solução de problemas específicos."
Gil (1999, p.42) ainda coloca que a pesquisa “Tem um caráter pragmático, é um
processo formal e sistemático de desenvolvimento do método científico. O objetivo
fundamental da pesquisa é descobrir respostas para problemas mediante o emprego de
procedimentos científicos”.

56
De acordo com Menezes e Silva (2005, p. 20), pesquisa qualitativa significa:
[...] um vínculo indissociável entre o mundo objetivo e a subjetividade do sujeito
que não pode ser traduzido em números. A interpretação dos fenômenos e a
atribuição de significados são básicas no processo de pesquisa qualitativa. Não
requer o uso de métodos e técnicas estatísticas. O ambiente natural é a fonte direta
para coleta de dados e o pesquisador é o instrumento-chave. É descritiva. Os
pesquisadores tendem a analisar seus dados indutivamente. O processo e seu
significado são os focos principais de abordagem.
Do ponto de vista dos objetivos, a presente monografia apresenta uma pesquisa
exploratória que, segundo Menezes e Silva (2005), visa proporcionar maior familiaridade com
o problema, tendo como objetivo torná-lo explícito ou construir hipóteses. Essa pesquisa
envolve levantamento bibliográfico, entrevistas com pessoas com experiências práticas e
análise de exemplos que auxiliem a compreensão do problema.
De acordo com o ponto de vista dos procedimentos técnicos, essa monografia
apresenta duas características: a pesquisa bibliográfica e o estudo de caso. Menezes e Silva
(2005) afirmam que uma pesquisa bibliográfica é aquela que foi elaborada a partir de um
material previamente publicado, sendo exemplos deste: livros, artigos e publicações
disponibilizadas na internet. Os mesmos autores destacam que um estudo de caso pode ser
definido como uma pesquisa que envolve um estudo profundo e exaustivo de um ou poucos
objetos, permitindo o seu amplo e detalhado conhecimento.
3.2 ETAPAS METODOLÓGICAS
Uma das etapas metodológicas iniciais representa a revisão bibliográfica que
serve de base para todo o trabalho. Após, será efetuado em paralelo às tarefas de
desenvolvimento dos testes automatizados e de estudo de uma aplicação web já existente
chamada Projector, que servirá de base, tanto para execução dos testes de regressão manual,
quanto para o teste automatizado. Em seguida, serão colocados em prática os testes manuais e
os automatizados, para que se possa fazer uma análise comparativa. Por fim, serão extraídas
as conclusões de ambos os procedimentos de teste.
A figura 11 ilustra esse processo.

57
Figura 11 - Etapas metodológicas
Fonte: Elaborado pelos autores, 2013

58
3.3 DESENHO DA SOLUÇÃO
Esse projeto utilizará um sistema web chamado Projector, que foi desenvolvido
durante o curso de graduação em Sistemas de Informação como trabalho final da disciplina de
Engenharia de Software, não sendo, portanto, um produto comercial. Essa aplicação consiste
em uma solução para gestão de projetos da área de TI.
O objetivo será aplicar os testes de regressão manuais e automatizados com o
apoio de profissionais da área, a fim de comparar as duas abordagens. Os testes elaborados
pertencem a algumas funcionalidades do Projector.
A rotina manual será escrita em um documento e entregue aos participantes
envolvidos para que os mesmos a executem em um primeiro momento. Em seguida, eles
acompanharão os mesmos testes feitos anteriormente de maneira automática.
Os casos automatizados são criados a partir de um script na ferramenta Selenium.
A figura 12 irá ilustrar essa proposta de solução.

59
Figura 12 - Esboço da Solução
Fonte: Elaborado pelos autores, 2013
3.4 CARACTERÍSTICAS DO ESTUDO DE CASO
Para que se possa avaliar o uso do teste automatizado sobre o uso dos testes
manuais, formulou-se um estudo de caso. Essa seção tem como função apresentar mais
informações sobre o mesmo.

60
3.4.1 Cenário proposto
Como forma de aplicar os conceitos da automação, foi utilizado o protótipo de
sistema web denominado Projector, que possui seu foco em gerenciamento de projetos. Essa
aplicação servirá de base para o desenvolvimento dos testes de regressão automatizados. Nela
foram introduzidos alguns bugs2
propositalmente para que seja possível visualizar dois casos:
• Caso 1: Onde alguma funcionalidade está operando de forma incorreta ao
esperado;
• Caso 2: Quando não ocorre nenhum problema e a funcionalidade está de
acordo com os requisitos.
Haverá a criação de casos de testes manuais, a fim de validar algumas funções do
Projector e as mesmas rotinas serão testadas, utilizando um sistema de automação, de modo
que se possam identificar pontos positivos e negativos de cada abordagem.
3.4.2 Objetivos
O estudo de caso possui os seguintes objetivos:
• Identificar as diferenças entre testes manuais e automatizados, levantando
suas vantagens e desvantagens;
• Colher as informações dos profissionais que utilizarão o sistema através de
um questionário;
• Verificar no contexto dos testes de regressão automatizados qual caso de
teste apresenta maior vantagem utilizando esse procedimento.
2
Bug é um “[...] defeito no software que, caso mantido, pode provocar falhas no sistema.” (HETZEL, 1987, p.
15).

Automação de Testes de Regressão - Selenium

Automação de Testes de Regressão - Selenium

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Automação de Testes de Regressão - Selenium

Semelhante a Automação de Testes de Regressão - Selenium (20)

Automação de Testes de Regressão - Selenium