UNIVERSIDADE DO SUL DE SANTA CATARINA
MAIELE PEROSA RANZAN
RODRIGO SUSIN DE OLIVEIRA
AUTOMAÇÃO DE TESTES DE REGRESSÃO:
UM ...
MAIELE PEROSA RANZAN
RODRIGO SUSIN DE OLIVEIRA
AUTOMAÇÃO DE TESTES DE REGRESSÃO:
UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK ...
MAIELE PEROSA RANZAN
RODRIGO SUSIN DE OLIVEIRA
AUTOMAÇÃO DE TESTES DE REGRESSÃO:
UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK ...
Dedico esse trabalho à minha família que
sempre me apoiou. Ao meu namorado Rafael
que com seu amor me manteve motivada nes...
AGRADECIMENTOS
Maiele Perosa Ranzan agradece
Essa monografia foi elaborada, acima de tudo, com muita dedicação e força de
...
Rodrigo Susin de Oliveira agradece
A toda minha família pelo apoio dado nessa empreitada, principalmente, a meu
pai, minha...
“Você pode encarar um erro como uma besteira a ser esquecida, ou como um resultado que
aponta uma nova direção.” (Steve Jo...
RESUMO
A área de testes está ocupando um espaço cada vez maior nas organizações de
desenvolvimento de software, pois se ob...
ABSTRACT, RÉSUMÉ OU RESUMEN
The test area is occupying a growing space on the software development organization,
because w...
LISTA DE ILUSTRAÇÕES
Figura 1 – Atividades do modelo cascata.................................................................
Figura 46 - Exemplo WebDriver em Java..............................................................................111
Fig...
LISTA DE QUADROS
Quadro 1 - Ferramentas comerciais...........................................................................
SUMÁRIO
1 INTRODUÇÃO.........................................................................................................
3.4.1 Cenário proposto.......................................................................................................
5.4.3 Execução manual dos casos de teste.....................................................................................
16
1 INTRODUÇÃO
No desenvolvimento de software ocorrem situações em que o sistema é entregue
ao cliente com qualidade baix...
17
No processo de desenvolvimento de software a automatização funciona como
recurso para a redução no esforço em atividade...
18
Com a criação dos métodos, o desenvolvimento começou a ser executado e
construído em etapas. O primeiro modelo criado f...
19
1.2 OBJETIVOS
Serão apresentados a seguir os objetivos gerais e específicos dessa monografia.
1.2.1 Objetivo geral
Veri...
20
pouquíssima documentação e sem planejamento, o que culminava em um produto final de
baixa qualidade.
Foi nesse contexto...
21
de ambos, quanto para a empresa em que trabalham, pois irá aprimorar e otimizar as rotinas
de teste.
1.4 ESTRUTURA DA M...
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 ...
23
projeto, a falta de atendimento aos requisitos do cliente, que gerava manutenções constantes,
dentre outros.
Segundo De...
24
consideração recursos, ferramentas, prazos, restrições e outros aspectos que envolvem o
desenvolvimento de uma aplicaçã...
25
2.2.1.1 Metodologias Tradicionais
As metodologias tradicionais também são conhecidas como orientadas à
documentação, po...
26
Figura 1 – Atividades do modelo cascata
Fonte: Adaptado de Pressman (1995, p. 33)
Para Pressman (1995), este modelo, co...
27
Segundo Koscianski e Soares (2007, p.192), “o modelo clássico dominou a forma
de desenvolvimento de software até o iníc...
28
Figura 3 - Modelo Incremental
Fonte: http://inf.unisul.br/~vera/egs/aula01.htm
De acordo com Sommerville (2003, p.44), ...
29
Figura 4 - Atividades da Prototipação
Fonte: Pressman (1995, p. 36)
O protótipo geralmente serve como uma visão prévia ...
30
2.2.1.1.4 Modelo espiral
O modelo espiral surgiu como solução às fragilidades de seus antecessores. Ele
representa o pr...
31
De acordo com Pressman (1995), o modelo espiral pode ser utilizado como forma
de refinar os requisitos, simulações e o ...
32
mas, sim como a equipe irá responder às modificações dos requisitos de um software que
serão frequentes durante o proce...
33
Para Koscianski e Soares (2007), as principais características que diferem a XP
das demais metodologias são:
• Comunica...
34
• Código padronizado: A equipe deve adotar um conjunto de padrões para
o código, onde todos os membros devem concordar ...
35
Para Soares (2004, p.5) “a Scrum apresenta uma abordagem empírica que aplica
algumas ideias da teoria de controle de pr...
36
• Pré-planejamento (pre-game phase): os requisitos encontram-se
ordenados por prioridade no backlog. Nessa fase será de...
37
A qualidade é uma sequência metódica que possui etapas e ferramentas para que
se tenha um processo ou produto dentro de...
38
Figura 8 - Custo de correção dos problemas
Fonte: Bastos et al. (2007, p. 19)
O conceito de qualidade está diretamente ...
39
processo [...] A principal característica dos testes de verificação é o fato de não
envolver o processamento de softwar...
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 ...
41
Bartié (2002, p.149) ainda afirma que esse tipo de teste valida “as interfaces entre
componentes da mesma arquitetura t...
42
2.3.1.5 Tipos de teste
Para a execução dos testes existem diversas técnicas, tais como: testes funcionais
ou caixa-pret...
43
Figura 9 - Visão do teste caixa-preta
Fonte: adaptado de Bartié (2002, p. 107)
Fazem parte dos testes de caixa-preta: 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
funcionalid...
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 ...
46
Figura 10 - Visão do teste caixa-branca
Fonte: Adaptado de Bartié (2002, p. 107)
Os testes de caixa-branca englobam: te...
47
• Servidores web que recebem solicitação de diversos usuários;
• Na indústria;
• Jogos para computador.
2.3.1.5.2.2 Tes...
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 mesm...
49
• Realizar a instalação pela primeira vez;
• Instalar o software em ambientes diferentes;
• Realizar a instalação da ap...
50
organizações não veem a automação de teste com bons olhos e, muitas vezes, essa alternativa
é descartada.
No mercado at...
51
Test Implementation Ferramentas que ajudam na implementação
dos testes. Um exemplo típico seria a geração
automática de...
52
estrutura de aplicação-alvo teste.
Test Coverage Analyzer Análises de cobertura de código.
Test Data Extraction Ferrame...
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-...
54
Um conjunto ou suíte de teste de regressão pode compreender tanto testes de
caixa-branca quanto testes caixa-preta. Uma...
55
3 MÉTODO
Esse capítulo aborda a metodologia presente nessa monografia, apresentando o
tipo de pesquisa que será adotado...
56
De acordo com Menezes e Silva (2005, p. 20), pesquisa qualitativa significa:
[...] um vínculo indissociável entre o mun...
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...
59
Figura 12 - Esboço da Solução
Fonte: Elaborado pelos autores, 2013
3.4 CARACTERÍSTICAS DO ESTUDO DE CASO
Para que se po...
60
3.4.1 Cenário proposto
Como forma de aplicar os conceitos da automação, foi utilizado o protótipo de
sistema web denomi...
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
Próximos SlideShares
Carregando em…5
×

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

582 visualizações

Publicada em

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.

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
582
No SlideShare
0
A partir de incorporações
0
Número de incorporações
97
Ações
Compartilhamentos
0
Downloads
10
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

  1. 1. 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
  2. 2. MAIELE PEROSA RANZAN RODRIGO SUSIN DE OLIVEIRA AUTOMAÇÃO DE TESTES DE REGRESSÃO: UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK SELENIUM 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
  3. 3. MAIELE PEROSA RANZAN RODRIGO SUSIN DE OLIVEIRA AUTOMAÇÃO DE TESTES DE REGRESSÃO: UM ESTUDO DE CASO UTILIZANDO O FRAMEWORK SELENIUM 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
  4. 4. 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
  5. 5. 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.
  6. 6. 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.
  7. 7. “Você pode encarar um erro como uma besteira a ser esquecida, ou como um resultado que aponta uma nova direção.” (Steve Jobs).
  8. 8. 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.
  9. 9. 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.
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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. 16. 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. 17. 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. 18. 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. 19. 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. 20. 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. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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. 31. 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. 32. 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. 33. 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. 34. 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. 35. 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. 36. 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. 37. 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. 38. 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. 39. 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. 40. 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. 41. 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. 42. 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. 43. 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. 44. 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. 45. 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. 46. 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. 47. 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. 48. 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. 49. 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. 50. 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. 51. 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. 52. 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. 53. 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. 54. 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. 55. 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. 56. 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. 57. 57 Figura 11 - Etapas metodológicas Fonte: Elaborado pelos autores, 2013
  58. 58. 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. 59. 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. 60. 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).

×