SlideShare uma empresa Scribd logo
1 de 12
Baixar para ler offline
Melhoria do desenvolvimento de software utilizando
práticas de Integração Contínua e Testes Automatizados
Alex Warmling1
, Anita Maria da Rocha Fernandes1
1
Curso de pós-graduação em Qualidade e Engenharia de Software – Universidade do
Vale do Itajaí (UNIVALI) – Florianópolis – SC – Brasil
alexw@edu.univali.br, anita.fernandes@univali.br
Abstract. With the growth of web applications increasing each year, new
practices in software development have been emerging. Their goal is always to
facilitate the work of technical team either through new processes or new tools
to assist in operations. This paper aims to show how the use of some
continuous integration and test automation techniques can help the
development team produce software with more confidence and quality, making
it better and more reliable for the end user.
Resumo. Como o crescimento das aplicações web vem aumento a cada ano,
novas práticas no desenvolvimento de software estão surgindo. O objetivo
delas é sempre o de facilitar o trabalho da equipe técnica, seja através de
novos processos ou novas ferramentas para suportar a operação. Este artigo
visa mostrar como a aplicação de algumas técnicas de Integração Contínua e
automação de testes podem auxiliar a equipe de desenvolvimento a produzir
software com mais confiança e qualidade, tornando-o melhor e mais confiável
para o usuário.
1. Introdução
O desenvolvimento de software vem evoluindo a anos e atualmente com a ascensão da
internet no país, as aplicações web estão cada vez maiores, mais complexas e contando
com um número cada vez mais expressivo de usuários. Com o intuito de agilizar o
desenvolvimento e garantir mais qualidade nos produtos de software, empresas vem
investindo em novas práticas/métodos de trabalho, como Integração Contínua (CI –
Continuous Integration), Entrega Contínua (CD – Continuous Delivery) e automação de
testes que antes eram feitos de forma manual, sendo desta maneira mais suscetíveis a
erros. Através destas práticas, hoje é possível automatizar boa parte das tarefas do
desenvolvimento de um software, entre elas o build, o teste e o deploy de uma
aplicação. Isso faz com que o processo e o próprio software tenham menos erros, pois
além de o processo estar automatizado, existem testes automáticos implementados para
todas as camadas do software, como unitários e integração. Com essa prática as
empresas conseguem descobrir possíveis falhas antes que cheguem ao cliente final,
evitando prejuízos financeiros e de imagem.
Porém, essas técnicas demandam também bastante trabalho e investimento por
parte da empresa, pois não podem ser implementadas da noite para o dia. Algumas terão
um custo maior para a empresa, que precisa enxergar a longo prazo o benefício do uso
de cada uma detas técnicas. Outros métodos precisam de concentimento e apoio da
equipe para que sejam implantados e funcionem, como as práticas ágeis descritos no XP
(eXtreme Programming) e no SCRUM, por exemplo.
Sendo assim, este estudo tem como objetivo comprovar como o uso de testes de
software automatizados aliados a outras técnicas de integração continua e entrega
contínua podem contribuir para a construção de um software melhor e com mais
qualidade, em uma equipe que já utiliza algumas práticas do XP e do SCRUM no seu
processo de desenvolvimento.
2. Metodologia
Inicialmente realizou-se o levantamento do processo atual de desenvolvimento de
software da empresa alvo. Este levantamento foi realizado através de pesquisa
documental, entrevista não estrutura com os colaboradores e também através da
observação direta das atividades que eram realizadas. Para mapear o fluxo destas
atividades utilizou-se a ferramenta Bizagi.
Após o mapeamento das atividades foi realizado então um estudo bibliográfico
sobre práticas ágeis, focando nos aspectos da integração contínua, entrega contínua e
automação de testes. Estas práticas prevêem várias atividades e aspectos que devem ser
observados e obedecidos pelo time no seu processo de desenvolvimento de software,
como por exemplo, manter um sistema de controle de versão, seja ele centralizado ou
distribuído, onde todo o time deve se preocupar com a qualidade do que está sendo
desenvolvido e principalmente que se tenha sempre uma versão funcional do sistema ao
final do dia.
Ao final deste estudo bibliográfico e das observações realizadas, foram
propostas algumas mudanças no processo de desenvolvimento, para que fosse possível
analisar se houveram ou não melhorias em relação ao que estava sendo utilizado
anteriormente.
2.1 Sobre a empresa alvo
O trabalho de análise do processo de desenvolvimento de software foi realizado em uma
empresa privada de Florianópolis, que a 6 anos se dedica à pesquisa, desenvolvimento e
inovação em soluções de personalização voltadas para o comércio eletrônico tanto
nacional quanto internacional.
A empresa possiu alguns produtos que são construídos de forma separada, onde
cada produto tem um time específico responsável, porém compartilham uma mesma
base de dados. Como cada produto tem um time responsável, as técnicas de
gerenciamento e de desenvolvimento dos produtos podem ser distintas, uma vez que
estes times tem autonomia para decidir a forma de trabalho, mais buscasndo sempre que
algumas práticas estejam alinhadas em todos os times. Alguns destes times já utilizam
as técnicas e práticas de integração contínua, outros ainda estão iniciando timidamente e
é neste grupo que este artigo tomará foco.
O processo de desenvolvimento do time alvo inicia com o levantamento de
requisitos pelo analista de negócio da empresa. Como geralmente os projetos são
parecidos, poucas novidades surgem entre um projeto e outro, desta maneira o processo
é bastante simples. Porém, isto tem gerado alguns problemas durando o
desenvolvimento, pois não se tem uma ordem exata para a sequencia de cada tarefa
dentro de um time técnico. Após o levantamento dos requisitos adicionais, o
desenvolvedor valida-os e então começa a codificar. Quando a codificação do requisito
está pronta, ele gera um build e disponibiliza para a equipe de testes executar os casos
de testes. Estes testes são na grande maioria manuais, onerando muito o tempo do
testador.
Após os testes, possíveis erros são reportados para o desenvolvedor realizar as
devidas correções ou caso não tenha nenhum ocorrência de erros o pacote pode ser
liberado para publicação. Então em seguida, o desenvolvedor publica este pacote em
produção, para que os testes de layout sejam feitos no ambiente real do cliente, porém
sem ainda habilitar a aplicação. Com os testes de layout realizados e se tudo estiver
correto, o analista de negócios comunica o cliente da publicação e solicita a aprovação
para habilitar a aplicação.
A Figura 1 apresenta o processo citado acima.
Figura 1. Processo de desenvolvimento objeto do estudo
3. Revisão bibliográfica
Neste capítulo, serão vistos alguns conceitos necessários para a compreensão das
práticas que foram abordadas como proposta deste artigo. Primeiramente, fala-se um
pouco sobre metologias ágeis, abordando aspectos do manifesto ágil. Em seguida, tem-
se uma breve descrição sobre os conceitos de integração contínua e entrega contínua,
mostrando alguns aspectos positivos da adoção destas práticas no dia a dia de trabalho.
Para finalizar são então apresentados alguns aspectos sobre a automação de testes e um
breve resumo sobre as ferramentas utilizadas para realização das melhorias.
3.1 Práticas ágeis
Os métodos ágeis nasceram na décade de 90, sendo que os mais conhecidos atualmente
são o XP e o SCRUM. O intuito destes métodos/práticas é produzir software com mais
qualidade, com menos tempo de desenvolvimento e de forma mais econômica. A
utilização destes métodos muitas vezes é expressa de forma equivocada, pois leva as
pessoas a pensarem que o Agile development 1
é sinônimo de agilidade, mas não, é
apenas uma outra metodologia que prevê outros tipos de práticas e que se bem aplicadas
podem resultar em um projeto mais rápido [Wells 2009].
O Manifesto Ágil publicado em 2001 é o Marco da grande disseminação destes
métodos por todo o mundo, onde descreve a essência de um conjunto de abordagens
para melhorar o desenvolvimento de software. O Manifesto Ágil (2001) está baseado em
4 princípios que passam a valorizar:
 Indivíduos e interações mais que processos e ferramentas;
 Software em funcionamento mais que documentação abrangente;
 Colaboração com o cliente mais que negociação de contratos; e
 Responder a mudanças mais que seguir um plano.
3.2 Integração Contínua
Uma das práticas que os métodos ágeis mencionam é a Integração Contínua. Segundo
Fowler (2006), a integração contínua é uma prática de desenvolimento de software,
onde os membros de uma mesma equipe integram seu trabalho com frequênca. Com
isto, ainda segundo Fowler (2006), fica mais fácil e rápido descobrir erros nas
aplicações, pois os builds e os testes são automatizados, permitindo que a correção dos
problemas ocorra mais rapidamente e se entregue um software de melhor qualidade.
Para Humble e Farley (2010), o objetivo da integração continua é deixar o
software sempre em um estado funcional. Afirmando ainda que a Integração Contínua
inclui uma mudança grande de paradigma, dizendo que:
“Sem integração contínua, o seu software
está quebrado até que alguém prove que ele
funciona, geralmente durante a fase de
testes ou de integração. Com a integração
contínua, o seu software está
comprovadamente funcionando e você sabe
quando ele quebra podendo corrígi-lo
imediatamente.”
3.3 Entrega Contínua
Para que a Integração Contínua faça sentido, a prática de Entrega Contínua também
deve ser adotada. Fowler (2013) define Entrega Contínua como sendo uma disciplina de
desenvolvimento de software onde o mesmo é construído de tal forma que pode ser
entregue a qualquer momento.
Segundo Fowler (2013), os principais benefícios desta prática são:
 Menor risco de implantação: uma vez que você faz entregas menores e rodou os
testes automáticos, há menos coisas com chance de conter algo errado;
1
É uma alternativa para a gestão de projetos tradicional, dando ênfase em capacitar pessoas a colaborar e
tomar decisões em equipe, além de planejamento, testes e integração contínuas.
 Progresso crível: onde é preferível se ter o pacote em produção do que apenas
acreditar que o desenvolvedor o fez pois marcou a tarefa como completa; e
 Feedback2
do usuário: pois como as entregas são menores e mais rápidas você
descobre antes se o caminho que está tomando está alinhado com as expectativas
do usuário final.
3.4 Testes automatizados
Rouse (2014) define que teste de software automatizado é um processo em que
ferramentas de software executam testes, através de um roteiro, sobre uma outra
aplicação de software, verificando seus requisitos antes que esta seja liberada para
produção. Rouse (2014) diz ainda que o objetivo do teste automatizado é simplificar ao
máximo o trabalho da equipe de qualidade, sintetizando o maior número de testes no
menor número de scripts possível.
Para Dustin et al (1999), estes testes equivalem a um esforço de
desenvolvimento que deve envolver sempre uma estratégia e planejamento de metas,
definição de requisitos, análise, projeto, desenvolvimento, execução e avaliação.
Segundo Crispin e Gregory (2009), existem diversas razões para automatizarmos
os testes, que são:
 Testes manuais são geralmente lentos;
 Os processos manuais são propensos a erros;
 Automação deixa as pessoas com mais tempo para fazer o seu melhor trabalho;
 Fornecem maior segurança para que sejam realizadas quaisquer alterações no
software;
 Fornecem feedback muito mais cedo e com mais frequência;
 Testes são a documentação viva do software; e
 Geralmente a automação oferece um bom retorno sobre o investimento feito.
Mas para que possamos implementar estas práticas com sucesso, alguns outros
softwares de apoio devem ser utilizados neste processo. Ferramentas que possam apoiar
a automação dos builds de integração, outras para que o código-fonte seja compartilhado
com toda a equipe, outras para que se possa automatizar os testes, dentre outras
ferramentas de gestão que apoiam as práticas ágeis.
3.5 Controle de versão
Sistemas de controle de versão, conhecidos também como sistemas de gerenciamento de
cóodigo fonte ou sistemas de controle de revisão, são um mecanismo utilizado para
manter versões diferentes de cada arquivo do código-fonte de um software. Deste modo
quando você modifica um arquivo, ainda pode acessar suas versões anteriores. São
também um mecanismo colaborativo para que pessoas envolvidas no mesmo projeto
possam trabalhar paralelamente [Humble e Farley 2010].
2
Informação sobre a reação de um usuário ou produto utilizado como base para melhoria.
Para este estudo utilizaremos a ferramenta GitHub, pois é um serviço hospedado
na nuvem, diminuindo a complexidade de alguém na empresa ter a preocupação com a
manutenção de um servidor de controle de versao, largamente utilizado atualmente com
quase 19 milhões de repositórios. Permite ainda que sejam feitos o cadastro de issues3
,
milestones4
e ainda revisão por pares dos commits5
realizados, práticas estas que estão
contidas nas metodologias ágeis [GitHub 2014].
3.6 Servidor de Integração Contínua
Estes softwares possuem duas funcionalidades basicamente, o primeiro é poder executar
por periodos longos um fluxo de trabalho simples em intervalos regulares. O segundo é
fornecer uma visão rápida e simples dos resultados dos processos que foram então
executados, notificando sobre o sucesso ou falha dos builds6
e testes. Estes serviços
normalmente disponibilizam uma interface web para que possamos olhar com mais
clareza tudo o que está acontecendo no momento ou também nos permitindo olhar para
o passado [Humble e Farley 2010].
Figura 2. Screenshot do Jenkins com processos já executados
Para este estudo de caso iremos utilizar a ferramenta Jenkins (Figura 2), um
serviço de integração continua open-source, sendo o seu uso gratuito. Possui uma
interface web amigável, é de fácil instalação e manutenção, possuindo vários plugins
que facilitam ainda mais o trabalho como por exemplo, o plugin para o github, onde
estaram armazenados os projetos deste estudo e também plugins de framworks de testes,
possibilitando uma visualização mais rápida do resultado dos testes.
4. Estudo de Caso
O estudo de caso foi realizado com base em sistemas Web de grande complexidade,
onde para cada cliente de um produto, um projeto especifico de layout precisa ser
3
Problema encontrado, as vezes também chamado de erro.
4
Marca fases importante no ciclo de um projeto.
5
Salvar o código desenvolvido.
6
Ato de construir algo.
montado, porém o backend7
é quase sempre o mesmo. As etapas de desenvolvimento da
aplicação e de testes eram bastante trabalhosas, uma vez que não eram utilizadas muitas
ferramentas que automatizassem tais processos.
Esse excesso de trabalho manual acabava gerando sempre uma lista grande de
defeitos encontrados na aplicação, pois o desenvolvedor não se atinha a criar testes
unitários ficando todo o teste da aplicação a cargo do testador que fazia grande parte
deste trabalho também de forma manual. Considerando isso, podemos facilmente
perceber que existia uma grande demora entre uma implementação ou correção de uma
feature8
até o momento que ela entraria de fato em produção, algo em torno de 6 horas,
e ainda sem garantir que a grande maioria dos defeitos seria encontrada. A Figura 3
ilustra os passos necessários para realização de um deploy, depois que o testador tivesse
dado seu aval.
Figura 3. Processo de deploy manual da aplicação
Como todo trabalho manual que é realizado está sujeito a erros, este tipo de
atividade também pode incorrer em erros, seja trocando o nome de um diretório ou o
número de uma versão. Outro problema era em relação aos testes da aplicação, que eram
todos feitos de forma manual, testando todas as regras de negócio, funcionalidades e
tempo de resposta por exemplo.
Como solução dos problemas citados e também para tornar mais produtivo o
trabalho no time foram então sugeridas algumas práticas de integração contínua para que
7
Parte de um programa que não é diretamente acessada pelo usuário.
8
Funcionalidade de um software.
pudessemos analisar se haveria uma real melhoria na qualidade e no tempo de execução
das tarefas. No contexto do time estudado, algumas práticas faziam mais sentido e estas
serão explanadas a seguir.
4.1 Automação de testes
O primeir ponto abordado pela equipe foi em relação a criação de uma suite de testes
para automatizar parte deste trabalho. O ideal seria que todo o código desenvolvido
fosse coberto por testes, porém como estávamos iniciando essa atividades, optou-se pela
realização de testes unitários para verificarmos qual seria o ganho com esta prática.
A proposta foi de escrever códigos de testes unitários que cobrissem todos os
cenários possíveis para cada função executada no código. Para que isso fosse possível
utilizamos a bibliota de testes do JavaScript chamada Jasmine que utiliza por baixo o
PhantomJS que é um headless browser, evitando assim que seja necessário instanciar
um navegador para a execução dos testes.
Como a parte do software que se está testando tem dependencias com outros
softwares que nao fazem parte do escopo deste projeto, utilizou-se uma outra
ferramenta, Sinon.js, para mockar as interações com os componentes necessários. Os
testes foram então isolados da aplicação principal, tendo uma estrutura independente
onde é mais fácil de realizar uma manutenção.
Foi então criada uma suite com aproximadamente quinhentos casos de testes
(esse número varia conforme o projeto), que são executados em menos de um segundo,
possibilitando que o desenvolvedor consiga identificar algum erro (Figura 4) com muito
mais rapidez, podendo corrigí-lo prontamente (Figura 5) e também auxilie na melhora
da qualidade do código que é entregue ao testador.
Figura 4. Testes executados com erro
Figura 5. Testes executados com sucesso
Estas ferramentas possibilitam ainda que se possa verificar a quantidade de
linhas de código tem cobertura por testes, como podemos ver na Figura 6. Para este
projeto em específico a parte que está sendo testada tem 1.661 linhas de código, das
quais 1.397 possuem no mínimo um teste passando por elas.
Figura 6. Sumário de cobertura de testes
Com essa prática, conseguiu-se diminuir em 30% o número de erros encontrados
na fase de testes, pois passaram a ser encontrados ainda na fase de desenvolvimento.
Isso impacta também na equipe de testes que acaba ficando mais livre para criar novos
casos de testes, testar outras funcionalidades não cobertas por este código ou ainda
implementar novos testes automáticos, como testes de aceitação e integração, por
exemplo.
4.2 Build Automatizado
Outra tarefa que demandava muito tempo e era suscetível a erros era a realização dos
builds do projeto. Para esta prática, buscamos uma ferramenta que suportasse javascript
que é a linguagem utilizada no desenvolvimento da aplicação. Adotamos então uma
ferramenta de build específica para node.js, o Grunt. A partir desta ferramenta,
executamos de maneira automática os diferentes passos envolvidos no desenvolvimento
da aplicação.
Essa ferramenta necessita que seja desenvolvida uma feature (Gruntfile.js) para
interpretar o que se deve fazer. Neste caso o build automaticamente concatena, minifica
e ofusca os diferentes arquivos de javascript, além de roda automaticamente os testes
unitários implementados no passo anterior quando se roda o comando “grunt”. Através
deste comando também é possível que sejam geradas versões estáveis da aplicação,
onde automaticamente ele empacota e tagueia uma nova versão com o comando “grunt
release:vX.Y.Z”.
4.3 Controle de Versão
O controle de versão já era utilizado pela time, porém de maneira muito simples e
usando a ferramenta SVN. A melhoria se iniciou neste ponto adotando outra ferramenta
de controle de versão, o Github, pois já era utilizado largamente por outros times na
empresa, possui um repositório distribuido e com serviço na nuvem, nos permitindo ter
acesso a aplicação em qualquer lugar que contasse com acesso a internet.
A segunda parte da melhoria é em relação ao processo de uso, onde antes se
tinha apenas os desenvolvedores fazendo seus commits e em seguida empacotando o
código para então os testes serem realizados, agora é necessário que seja feito uma
revisão com o seu par, seja ele outro desenvolvedor ou um tester, para com o aval de
ambos o código seja commitado e então liberado.
Outra prática adotada foi a de sempre gerar uma tag quando uma versão estiver
estável e possa ser então disponibilizada para o cliente final. Com isso, caso uma versão
posterior sofra algum problema que não tenha sido identificado anteriormente, fica
muito mais fácil de se reverter o sistema para a última versão estável.
Além destas duas práticas citadas acima, adotou-se um esquema de
versionamento que segue o “semver9
” (major.minor.patch), onde o MAJOR segue a
versão da API que o sistema utiliza, o MINOR é incrementado sempre que uma nova
feature é desenvolvida e o PATCH é incrementado quando existe a correção de algum
bug da versão.
4.4 Commits constantes
Outra prática adotada foi a de realizar commits constante, pois quanto mais tempo o
código fica sem ser salvo, maior o risco de ter que fazer um merge para juntar partes que
foram desenvolvidas por outras pessoas. A complexidade do trabalho aumenta se a
quantidade de merges também for grande, podendo ocasionar em mais erros no código.
Porém é importante lembrar que não se deve fazer commits a todo instante, pois
pode-se com isto, perder a rastreabilidade do que foi feito, dificultando a revisão e
também a resolução de problemas que podem vir a surgir. Neste ponto, adotou-se então
a prática de revisão de commits, para que outra pessoa também possa opinar se seus
commits também estão bons, não apenas o seu código.
4.5 Não commitar código quebrado
Uma prática essencial para a Integração Contínua, é tratar o controle de versão
como algo sagrado, ou o mais próximo disto. Se não se pode confiar que o código que
está no trunk (ou master) é limpo e de confiança, fica difícil resolver os
problemas depois que eles já saíram da cabeça do desenvolvedor. Para a resolução deste
9
Regra semântica de versionamento, http://semver.org/
problema, adotou-se a prática de rodar localmente o projeto, fazendo o build automático
dele, onde já são executados também todos os testes unitários mencionados na primeira
prática deste capítulo, antes de fazer o push do código para o Github.
Após o envio do código para o repositório, um job de build é automaticamente
disparado no servidor de integração contínua (Jenkins), onde caso o build gere algum
erro, o responsável é imediatamente notificado, podendo tomar uma ação imediata para
a correção do problema, refazendo o processo até que o build fique estável.
4.6 Deploy automatizado
A última melhoria adotada é em relação a prática de entrega contínua, onde o processo
para disponibilizar uma nova versão em produção seja o mais automático e transparente
possível. Para que isto fosse algo que funcionasse 100%, deveriamos ter todos os testes
possíveis implementados nos projetos (unitários, aceitação, integração), porém isso
ficará para um segundo momento.
Neste momento foi implementado um job que faz a publicação automática de
uma versão depois que ela passa por todos os testes unitários (automáticos) e também
pelos testes manuais exploratórios que a equipe de testes realiza. Como vemos na Figura
2, foram criados jobs de publish (publicação) que são disparados atualmente de forma
manual, porém executando automaticamente todo o processo mostrado na Figura 3
apenas informando na hora da execução qual é o número da tag que deverá ser
publicada em produção.
5. Conclusão
Conforme proposto, este artigo mostrou a implementação de algumas técnicas de
integração contínua e automação de testes.
Em cada prática pudemos verificar que houve uma melhora no desempenho do
time e no desempenho do processo executado, tornando-o mais automático com menos
probabilidade de ocorrerem erros. A prática de automação dos testes unitário se mostrou
bastante eficiente, uma vez que a mesma quantidade de testes para serem executados de
forma manual levava em torno de 3 horas de um membro da equipe, geralmente o tester.
Considerando que as equipes geralmente são formadas por até 3
desenvolvedores, 2 designers e apenas 1 tester esse trabalho era bastante exaustivo e
suscetível a erros.
Outra prática que obteve bastante aceitação e gerou um impacto forte no
processo foi o build e o deploy automático, uma vez que desenvolvedores não precisam
mais executar as tarefas repetitivas dos passos de build e deploy da aplicação, tendo
mais tempo para trabalhos mais criativos e menos repetitivos.
Por fim, agora conseguimos obter feedbacks muito mais rápidos das aplicações,
integrando o código continuamente, investindo tempo na automação de tarefas e testes,
podendo encontrar defeitos antecipadamente e tornando então mudanças no software
muito menos problemáticas.
Referências
Beck, K., Beedle, M., Bennekum, A. van and et al (2001) “Manifesto para
Desenvolvimento Ágil de Software”, http://www.agilemanifesto.org/iso/ptbr/,
Janeiro
Dustin, E; Rashka, J; Paul, J. (1999), Automated Software Testing: Introduction,
Management, and Performance. 1st
edition.
Fowler, M. (2013) “ContinuousDelivery”,
http://martinfowler.com/bliki/ContinuousDelivery.html, Janeiro.
Fowler, M. (2006) “Continuous Integration”,
http://martinfowler.com/articles/continuousIntegration.html, Janeiro.
GitHub. (2014) “Field-tested tools for any project”, https://github.com/features, Janeiro.
Humble, J.; Farley, D. (2010), Continuous Delivery: Reliable Software Releases through
Build, Test, and Deployment Automation. 1st
edition.
Rouse, M. (2014) “Automated software testing”,
http://searchsoftwarequality.techtarget.com/definition/automated-software-testing,
Janeiro.
Wells, Don. (2009) “Agile Software Development: A gentle introduction”,
http://www.agile-process.org/, Janeiro.

Mais conteúdo relacionado

Mais procurados

Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalhoRuan Pozzebon
 
Uma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeisUma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeiss4nx
 
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilEngenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilRebecca Betwel
 
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixCris Fidelix
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingDaniel Wildt
 
Processos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBanProcessos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBanSamuel Cavalcante
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareLuciano Almeida
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Flávio Steffens
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme ProgrammingRodrigo Branas
 
81221835 ergoihc-teste-de-usabilidade-ariel
81221835 ergoihc-teste-de-usabilidade-ariel81221835 ergoihc-teste-de-usabilidade-ariel
81221835 ergoihc-teste-de-usabilidade-arielMarco Guimarães
 
Apresentação MBA Arq. Software. - IGTI
Apresentação MBA Arq. Software. - IGTIApresentação MBA Arq. Software. - IGTI
Apresentação MBA Arq. Software. - IGTIFernando Almeida
 
Continuous delivery
Continuous deliveryContinuous delivery
Continuous deliveryMarco Valtas
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Rennan Martini
 

Mais procurados (20)

Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
 
Uma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeisUma análise sobre gestão de pessoas baseada nos métodos ágeis
Uma análise sobre gestão de pessoas baseada nos métodos ágeis
 
Desenvolvimento Ágil
Desenvolvimento ÁgilDesenvolvimento Ágil
Desenvolvimento Ágil
 
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilEngenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
 
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Processos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBanProcessos Ágeis - Scrum, Kanban ou ScrumBan
Processos Ágeis - Scrum, Kanban ou ScrumBan
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
 
81221835 ergoihc-teste-de-usabilidade-ariel
81221835 ergoihc-teste-de-usabilidade-ariel81221835 ergoihc-teste-de-usabilidade-ariel
81221835 ergoihc-teste-de-usabilidade-ariel
 
Apresentação MBA Arq. Software. - IGTI
Apresentação MBA Arq. Software. - IGTIApresentação MBA Arq. Software. - IGTI
Apresentação MBA Arq. Software. - IGTI
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
 
Continuous delivery
Continuous deliveryContinuous delivery
Continuous delivery
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 

Semelhante a Artigo-Alex_Warmling

Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANFernando Palma
 
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De ProcessoUma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processocrc1404
 
Uma abordagem de entrega contínua para empresas de desenvolvimento de software
Uma abordagem de entrega contínua para empresas de desenvolvimento de softwareUma abordagem de entrega contínua para empresas de desenvolvimento de software
Uma abordagem de entrega contínua para empresas de desenvolvimento de softwareRodolfo Bueno
 
Metodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de SoftwaresMetodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de SoftwaresAragon Vieira
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...André Luis Celestino
 
GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MINING
GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MININGGESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MINING
GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MININGMarcos Lottermann
 
Processos de software
Processos de softwareProcessos de software
Processos de softwareDann Volpato
 
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...Fábio Pio
 
QATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de Software
QATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de SoftwareQATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de Software
QATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de SoftwareWelington Monteiro
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven developmentIzabel Rodrigues
 
Métodos Ágeis - Guia para Projetos Eficientes
Métodos Ágeis - Guia para Projetos EficientesMétodos Ágeis - Guia para Projetos Eficientes
Métodos Ágeis - Guia para Projetos EficientesGabriela Giacomini
 
Verificação, validação e teste de software ágil
Verificação, validação e teste de software ágilVerificação, validação e teste de software ágil
Verificação, validação e teste de software ágilGilberto Gampert
 
Lean software development (2)
Lean software development (2)Lean software development (2)
Lean software development (2)juarezlustosa
 
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...Silvio Gonçalves
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareThiago Reis da Silva
 
ATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docx
ATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docxATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docx
ATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docxjosepedro158321
 

Semelhante a Artigo-Alex_Warmling (20)

Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De ProcessoUma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
 
Lean software
Lean software Lean software
Lean software
 
Uma abordagem de entrega contínua para empresas de desenvolvimento de software
Uma abordagem de entrega contínua para empresas de desenvolvimento de softwareUma abordagem de entrega contínua para empresas de desenvolvimento de software
Uma abordagem de entrega contínua para empresas de desenvolvimento de software
 
Metodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de SoftwaresMetodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de Softwares
 
Automatização de Ambientes CI & CD & DevOps
Automatização de Ambientes CI & CD & DevOpsAutomatização de Ambientes CI & CD & DevOps
Automatização de Ambientes CI & CD & DevOps
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
 
GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MINING
GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MININGGESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MINING
GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE PADRÕES COM TEXT MINING
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...
 
QATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de Software
QATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de SoftwareQATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de Software
QATEST - Agile Brazil 2014 - O impacto do DEVOPS na Qualidade de Software
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven development
 
Métodos Ágeis - Guia para Projetos Eficientes
Métodos Ágeis - Guia para Projetos EficientesMétodos Ágeis - Guia para Projetos Eficientes
Métodos Ágeis - Guia para Projetos Eficientes
 
Subm_SamuelPereira_FINAL
Subm_SamuelPereira_FINALSubm_SamuelPereira_FINAL
Subm_SamuelPereira_FINAL
 
Verificação, validação e teste de software ágil
Verificação, validação e teste de software ágilVerificação, validação e teste de software ágil
Verificação, validação e teste de software ágil
 
Lean software development (2)
Lean software development (2)Lean software development (2)
Lean software development (2)
 
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de  Trabalh...
Práticas de Métodos Ágeis e Possibilidade de Execução em Ambiente de Trabalh...
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
 
ATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docx
ATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docxATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docx
ATIVIDADE 1 - TÓPICOS ESPECIAIS - 532023.docx
 

Artigo-Alex_Warmling

  • 1. Melhoria do desenvolvimento de software utilizando práticas de Integração Contínua e Testes Automatizados Alex Warmling1 , Anita Maria da Rocha Fernandes1 1 Curso de pós-graduação em Qualidade e Engenharia de Software – Universidade do Vale do Itajaí (UNIVALI) – Florianópolis – SC – Brasil alexw@edu.univali.br, anita.fernandes@univali.br Abstract. With the growth of web applications increasing each year, new practices in software development have been emerging. Their goal is always to facilitate the work of technical team either through new processes or new tools to assist in operations. This paper aims to show how the use of some continuous integration and test automation techniques can help the development team produce software with more confidence and quality, making it better and more reliable for the end user. Resumo. Como o crescimento das aplicações web vem aumento a cada ano, novas práticas no desenvolvimento de software estão surgindo. O objetivo delas é sempre o de facilitar o trabalho da equipe técnica, seja através de novos processos ou novas ferramentas para suportar a operação. Este artigo visa mostrar como a aplicação de algumas técnicas de Integração Contínua e automação de testes podem auxiliar a equipe de desenvolvimento a produzir software com mais confiança e qualidade, tornando-o melhor e mais confiável para o usuário. 1. Introdução O desenvolvimento de software vem evoluindo a anos e atualmente com a ascensão da internet no país, as aplicações web estão cada vez maiores, mais complexas e contando com um número cada vez mais expressivo de usuários. Com o intuito de agilizar o desenvolvimento e garantir mais qualidade nos produtos de software, empresas vem investindo em novas práticas/métodos de trabalho, como Integração Contínua (CI – Continuous Integration), Entrega Contínua (CD – Continuous Delivery) e automação de testes que antes eram feitos de forma manual, sendo desta maneira mais suscetíveis a erros. Através destas práticas, hoje é possível automatizar boa parte das tarefas do desenvolvimento de um software, entre elas o build, o teste e o deploy de uma aplicação. Isso faz com que o processo e o próprio software tenham menos erros, pois além de o processo estar automatizado, existem testes automáticos implementados para todas as camadas do software, como unitários e integração. Com essa prática as empresas conseguem descobrir possíveis falhas antes que cheguem ao cliente final, evitando prejuízos financeiros e de imagem. Porém, essas técnicas demandam também bastante trabalho e investimento por parte da empresa, pois não podem ser implementadas da noite para o dia. Algumas terão um custo maior para a empresa, que precisa enxergar a longo prazo o benefício do uso de cada uma detas técnicas. Outros métodos precisam de concentimento e apoio da
  • 2. equipe para que sejam implantados e funcionem, como as práticas ágeis descritos no XP (eXtreme Programming) e no SCRUM, por exemplo. Sendo assim, este estudo tem como objetivo comprovar como o uso de testes de software automatizados aliados a outras técnicas de integração continua e entrega contínua podem contribuir para a construção de um software melhor e com mais qualidade, em uma equipe que já utiliza algumas práticas do XP e do SCRUM no seu processo de desenvolvimento. 2. Metodologia Inicialmente realizou-se o levantamento do processo atual de desenvolvimento de software da empresa alvo. Este levantamento foi realizado através de pesquisa documental, entrevista não estrutura com os colaboradores e também através da observação direta das atividades que eram realizadas. Para mapear o fluxo destas atividades utilizou-se a ferramenta Bizagi. Após o mapeamento das atividades foi realizado então um estudo bibliográfico sobre práticas ágeis, focando nos aspectos da integração contínua, entrega contínua e automação de testes. Estas práticas prevêem várias atividades e aspectos que devem ser observados e obedecidos pelo time no seu processo de desenvolvimento de software, como por exemplo, manter um sistema de controle de versão, seja ele centralizado ou distribuído, onde todo o time deve se preocupar com a qualidade do que está sendo desenvolvido e principalmente que se tenha sempre uma versão funcional do sistema ao final do dia. Ao final deste estudo bibliográfico e das observações realizadas, foram propostas algumas mudanças no processo de desenvolvimento, para que fosse possível analisar se houveram ou não melhorias em relação ao que estava sendo utilizado anteriormente. 2.1 Sobre a empresa alvo O trabalho de análise do processo de desenvolvimento de software foi realizado em uma empresa privada de Florianópolis, que a 6 anos se dedica à pesquisa, desenvolvimento e inovação em soluções de personalização voltadas para o comércio eletrônico tanto nacional quanto internacional. A empresa possiu alguns produtos que são construídos de forma separada, onde cada produto tem um time específico responsável, porém compartilham uma mesma base de dados. Como cada produto tem um time responsável, as técnicas de gerenciamento e de desenvolvimento dos produtos podem ser distintas, uma vez que estes times tem autonomia para decidir a forma de trabalho, mais buscasndo sempre que algumas práticas estejam alinhadas em todos os times. Alguns destes times já utilizam as técnicas e práticas de integração contínua, outros ainda estão iniciando timidamente e é neste grupo que este artigo tomará foco. O processo de desenvolvimento do time alvo inicia com o levantamento de requisitos pelo analista de negócio da empresa. Como geralmente os projetos são parecidos, poucas novidades surgem entre um projeto e outro, desta maneira o processo é bastante simples. Porém, isto tem gerado alguns problemas durando o
  • 3. desenvolvimento, pois não se tem uma ordem exata para a sequencia de cada tarefa dentro de um time técnico. Após o levantamento dos requisitos adicionais, o desenvolvedor valida-os e então começa a codificar. Quando a codificação do requisito está pronta, ele gera um build e disponibiliza para a equipe de testes executar os casos de testes. Estes testes são na grande maioria manuais, onerando muito o tempo do testador. Após os testes, possíveis erros são reportados para o desenvolvedor realizar as devidas correções ou caso não tenha nenhum ocorrência de erros o pacote pode ser liberado para publicação. Então em seguida, o desenvolvedor publica este pacote em produção, para que os testes de layout sejam feitos no ambiente real do cliente, porém sem ainda habilitar a aplicação. Com os testes de layout realizados e se tudo estiver correto, o analista de negócios comunica o cliente da publicação e solicita a aprovação para habilitar a aplicação. A Figura 1 apresenta o processo citado acima. Figura 1. Processo de desenvolvimento objeto do estudo 3. Revisão bibliográfica Neste capítulo, serão vistos alguns conceitos necessários para a compreensão das práticas que foram abordadas como proposta deste artigo. Primeiramente, fala-se um pouco sobre metologias ágeis, abordando aspectos do manifesto ágil. Em seguida, tem- se uma breve descrição sobre os conceitos de integração contínua e entrega contínua, mostrando alguns aspectos positivos da adoção destas práticas no dia a dia de trabalho. Para finalizar são então apresentados alguns aspectos sobre a automação de testes e um breve resumo sobre as ferramentas utilizadas para realização das melhorias. 3.1 Práticas ágeis Os métodos ágeis nasceram na décade de 90, sendo que os mais conhecidos atualmente são o XP e o SCRUM. O intuito destes métodos/práticas é produzir software com mais qualidade, com menos tempo de desenvolvimento e de forma mais econômica. A utilização destes métodos muitas vezes é expressa de forma equivocada, pois leva as
  • 4. pessoas a pensarem que o Agile development 1 é sinônimo de agilidade, mas não, é apenas uma outra metodologia que prevê outros tipos de práticas e que se bem aplicadas podem resultar em um projeto mais rápido [Wells 2009]. O Manifesto Ágil publicado em 2001 é o Marco da grande disseminação destes métodos por todo o mundo, onde descreve a essência de um conjunto de abordagens para melhorar o desenvolvimento de software. O Manifesto Ágil (2001) está baseado em 4 princípios que passam a valorizar:  Indivíduos e interações mais que processos e ferramentas;  Software em funcionamento mais que documentação abrangente;  Colaboração com o cliente mais que negociação de contratos; e  Responder a mudanças mais que seguir um plano. 3.2 Integração Contínua Uma das práticas que os métodos ágeis mencionam é a Integração Contínua. Segundo Fowler (2006), a integração contínua é uma prática de desenvolimento de software, onde os membros de uma mesma equipe integram seu trabalho com frequênca. Com isto, ainda segundo Fowler (2006), fica mais fácil e rápido descobrir erros nas aplicações, pois os builds e os testes são automatizados, permitindo que a correção dos problemas ocorra mais rapidamente e se entregue um software de melhor qualidade. Para Humble e Farley (2010), o objetivo da integração continua é deixar o software sempre em um estado funcional. Afirmando ainda que a Integração Contínua inclui uma mudança grande de paradigma, dizendo que: “Sem integração contínua, o seu software está quebrado até que alguém prove que ele funciona, geralmente durante a fase de testes ou de integração. Com a integração contínua, o seu software está comprovadamente funcionando e você sabe quando ele quebra podendo corrígi-lo imediatamente.” 3.3 Entrega Contínua Para que a Integração Contínua faça sentido, a prática de Entrega Contínua também deve ser adotada. Fowler (2013) define Entrega Contínua como sendo uma disciplina de desenvolvimento de software onde o mesmo é construído de tal forma que pode ser entregue a qualquer momento. Segundo Fowler (2013), os principais benefícios desta prática são:  Menor risco de implantação: uma vez que você faz entregas menores e rodou os testes automáticos, há menos coisas com chance de conter algo errado; 1 É uma alternativa para a gestão de projetos tradicional, dando ênfase em capacitar pessoas a colaborar e tomar decisões em equipe, além de planejamento, testes e integração contínuas.
  • 5.  Progresso crível: onde é preferível se ter o pacote em produção do que apenas acreditar que o desenvolvedor o fez pois marcou a tarefa como completa; e  Feedback2 do usuário: pois como as entregas são menores e mais rápidas você descobre antes se o caminho que está tomando está alinhado com as expectativas do usuário final. 3.4 Testes automatizados Rouse (2014) define que teste de software automatizado é um processo em que ferramentas de software executam testes, através de um roteiro, sobre uma outra aplicação de software, verificando seus requisitos antes que esta seja liberada para produção. Rouse (2014) diz ainda que o objetivo do teste automatizado é simplificar ao máximo o trabalho da equipe de qualidade, sintetizando o maior número de testes no menor número de scripts possível. Para Dustin et al (1999), estes testes equivalem a um esforço de desenvolvimento que deve envolver sempre uma estratégia e planejamento de metas, definição de requisitos, análise, projeto, desenvolvimento, execução e avaliação. Segundo Crispin e Gregory (2009), existem diversas razões para automatizarmos os testes, que são:  Testes manuais são geralmente lentos;  Os processos manuais são propensos a erros;  Automação deixa as pessoas com mais tempo para fazer o seu melhor trabalho;  Fornecem maior segurança para que sejam realizadas quaisquer alterações no software;  Fornecem feedback muito mais cedo e com mais frequência;  Testes são a documentação viva do software; e  Geralmente a automação oferece um bom retorno sobre o investimento feito. Mas para que possamos implementar estas práticas com sucesso, alguns outros softwares de apoio devem ser utilizados neste processo. Ferramentas que possam apoiar a automação dos builds de integração, outras para que o código-fonte seja compartilhado com toda a equipe, outras para que se possa automatizar os testes, dentre outras ferramentas de gestão que apoiam as práticas ágeis. 3.5 Controle de versão Sistemas de controle de versão, conhecidos também como sistemas de gerenciamento de cóodigo fonte ou sistemas de controle de revisão, são um mecanismo utilizado para manter versões diferentes de cada arquivo do código-fonte de um software. Deste modo quando você modifica um arquivo, ainda pode acessar suas versões anteriores. São também um mecanismo colaborativo para que pessoas envolvidas no mesmo projeto possam trabalhar paralelamente [Humble e Farley 2010]. 2 Informação sobre a reação de um usuário ou produto utilizado como base para melhoria.
  • 6. Para este estudo utilizaremos a ferramenta GitHub, pois é um serviço hospedado na nuvem, diminuindo a complexidade de alguém na empresa ter a preocupação com a manutenção de um servidor de controle de versao, largamente utilizado atualmente com quase 19 milhões de repositórios. Permite ainda que sejam feitos o cadastro de issues3 , milestones4 e ainda revisão por pares dos commits5 realizados, práticas estas que estão contidas nas metodologias ágeis [GitHub 2014]. 3.6 Servidor de Integração Contínua Estes softwares possuem duas funcionalidades basicamente, o primeiro é poder executar por periodos longos um fluxo de trabalho simples em intervalos regulares. O segundo é fornecer uma visão rápida e simples dos resultados dos processos que foram então executados, notificando sobre o sucesso ou falha dos builds6 e testes. Estes serviços normalmente disponibilizam uma interface web para que possamos olhar com mais clareza tudo o que está acontecendo no momento ou também nos permitindo olhar para o passado [Humble e Farley 2010]. Figura 2. Screenshot do Jenkins com processos já executados Para este estudo de caso iremos utilizar a ferramenta Jenkins (Figura 2), um serviço de integração continua open-source, sendo o seu uso gratuito. Possui uma interface web amigável, é de fácil instalação e manutenção, possuindo vários plugins que facilitam ainda mais o trabalho como por exemplo, o plugin para o github, onde estaram armazenados os projetos deste estudo e também plugins de framworks de testes, possibilitando uma visualização mais rápida do resultado dos testes. 4. Estudo de Caso O estudo de caso foi realizado com base em sistemas Web de grande complexidade, onde para cada cliente de um produto, um projeto especifico de layout precisa ser 3 Problema encontrado, as vezes também chamado de erro. 4 Marca fases importante no ciclo de um projeto. 5 Salvar o código desenvolvido. 6 Ato de construir algo.
  • 7. montado, porém o backend7 é quase sempre o mesmo. As etapas de desenvolvimento da aplicação e de testes eram bastante trabalhosas, uma vez que não eram utilizadas muitas ferramentas que automatizassem tais processos. Esse excesso de trabalho manual acabava gerando sempre uma lista grande de defeitos encontrados na aplicação, pois o desenvolvedor não se atinha a criar testes unitários ficando todo o teste da aplicação a cargo do testador que fazia grande parte deste trabalho também de forma manual. Considerando isso, podemos facilmente perceber que existia uma grande demora entre uma implementação ou correção de uma feature8 até o momento que ela entraria de fato em produção, algo em torno de 6 horas, e ainda sem garantir que a grande maioria dos defeitos seria encontrada. A Figura 3 ilustra os passos necessários para realização de um deploy, depois que o testador tivesse dado seu aval. Figura 3. Processo de deploy manual da aplicação Como todo trabalho manual que é realizado está sujeito a erros, este tipo de atividade também pode incorrer em erros, seja trocando o nome de um diretório ou o número de uma versão. Outro problema era em relação aos testes da aplicação, que eram todos feitos de forma manual, testando todas as regras de negócio, funcionalidades e tempo de resposta por exemplo. Como solução dos problemas citados e também para tornar mais produtivo o trabalho no time foram então sugeridas algumas práticas de integração contínua para que 7 Parte de um programa que não é diretamente acessada pelo usuário. 8 Funcionalidade de um software.
  • 8. pudessemos analisar se haveria uma real melhoria na qualidade e no tempo de execução das tarefas. No contexto do time estudado, algumas práticas faziam mais sentido e estas serão explanadas a seguir. 4.1 Automação de testes O primeir ponto abordado pela equipe foi em relação a criação de uma suite de testes para automatizar parte deste trabalho. O ideal seria que todo o código desenvolvido fosse coberto por testes, porém como estávamos iniciando essa atividades, optou-se pela realização de testes unitários para verificarmos qual seria o ganho com esta prática. A proposta foi de escrever códigos de testes unitários que cobrissem todos os cenários possíveis para cada função executada no código. Para que isso fosse possível utilizamos a bibliota de testes do JavaScript chamada Jasmine que utiliza por baixo o PhantomJS que é um headless browser, evitando assim que seja necessário instanciar um navegador para a execução dos testes. Como a parte do software que se está testando tem dependencias com outros softwares que nao fazem parte do escopo deste projeto, utilizou-se uma outra ferramenta, Sinon.js, para mockar as interações com os componentes necessários. Os testes foram então isolados da aplicação principal, tendo uma estrutura independente onde é mais fácil de realizar uma manutenção. Foi então criada uma suite com aproximadamente quinhentos casos de testes (esse número varia conforme o projeto), que são executados em menos de um segundo, possibilitando que o desenvolvedor consiga identificar algum erro (Figura 4) com muito mais rapidez, podendo corrigí-lo prontamente (Figura 5) e também auxilie na melhora da qualidade do código que é entregue ao testador. Figura 4. Testes executados com erro
  • 9. Figura 5. Testes executados com sucesso Estas ferramentas possibilitam ainda que se possa verificar a quantidade de linhas de código tem cobertura por testes, como podemos ver na Figura 6. Para este projeto em específico a parte que está sendo testada tem 1.661 linhas de código, das quais 1.397 possuem no mínimo um teste passando por elas. Figura 6. Sumário de cobertura de testes Com essa prática, conseguiu-se diminuir em 30% o número de erros encontrados na fase de testes, pois passaram a ser encontrados ainda na fase de desenvolvimento. Isso impacta também na equipe de testes que acaba ficando mais livre para criar novos casos de testes, testar outras funcionalidades não cobertas por este código ou ainda implementar novos testes automáticos, como testes de aceitação e integração, por exemplo. 4.2 Build Automatizado Outra tarefa que demandava muito tempo e era suscetível a erros era a realização dos builds do projeto. Para esta prática, buscamos uma ferramenta que suportasse javascript que é a linguagem utilizada no desenvolvimento da aplicação. Adotamos então uma ferramenta de build específica para node.js, o Grunt. A partir desta ferramenta, executamos de maneira automática os diferentes passos envolvidos no desenvolvimento da aplicação. Essa ferramenta necessita que seja desenvolvida uma feature (Gruntfile.js) para interpretar o que se deve fazer. Neste caso o build automaticamente concatena, minifica e ofusca os diferentes arquivos de javascript, além de roda automaticamente os testes
  • 10. unitários implementados no passo anterior quando se roda o comando “grunt”. Através deste comando também é possível que sejam geradas versões estáveis da aplicação, onde automaticamente ele empacota e tagueia uma nova versão com o comando “grunt release:vX.Y.Z”. 4.3 Controle de Versão O controle de versão já era utilizado pela time, porém de maneira muito simples e usando a ferramenta SVN. A melhoria se iniciou neste ponto adotando outra ferramenta de controle de versão, o Github, pois já era utilizado largamente por outros times na empresa, possui um repositório distribuido e com serviço na nuvem, nos permitindo ter acesso a aplicação em qualquer lugar que contasse com acesso a internet. A segunda parte da melhoria é em relação ao processo de uso, onde antes se tinha apenas os desenvolvedores fazendo seus commits e em seguida empacotando o código para então os testes serem realizados, agora é necessário que seja feito uma revisão com o seu par, seja ele outro desenvolvedor ou um tester, para com o aval de ambos o código seja commitado e então liberado. Outra prática adotada foi a de sempre gerar uma tag quando uma versão estiver estável e possa ser então disponibilizada para o cliente final. Com isso, caso uma versão posterior sofra algum problema que não tenha sido identificado anteriormente, fica muito mais fácil de se reverter o sistema para a última versão estável. Além destas duas práticas citadas acima, adotou-se um esquema de versionamento que segue o “semver9 ” (major.minor.patch), onde o MAJOR segue a versão da API que o sistema utiliza, o MINOR é incrementado sempre que uma nova feature é desenvolvida e o PATCH é incrementado quando existe a correção de algum bug da versão. 4.4 Commits constantes Outra prática adotada foi a de realizar commits constante, pois quanto mais tempo o código fica sem ser salvo, maior o risco de ter que fazer um merge para juntar partes que foram desenvolvidas por outras pessoas. A complexidade do trabalho aumenta se a quantidade de merges também for grande, podendo ocasionar em mais erros no código. Porém é importante lembrar que não se deve fazer commits a todo instante, pois pode-se com isto, perder a rastreabilidade do que foi feito, dificultando a revisão e também a resolução de problemas que podem vir a surgir. Neste ponto, adotou-se então a prática de revisão de commits, para que outra pessoa também possa opinar se seus commits também estão bons, não apenas o seu código. 4.5 Não commitar código quebrado Uma prática essencial para a Integração Contínua, é tratar o controle de versão como algo sagrado, ou o mais próximo disto. Se não se pode confiar que o código que está no trunk (ou master) é limpo e de confiança, fica difícil resolver os problemas depois que eles já saíram da cabeça do desenvolvedor. Para a resolução deste 9 Regra semântica de versionamento, http://semver.org/
  • 11. problema, adotou-se a prática de rodar localmente o projeto, fazendo o build automático dele, onde já são executados também todos os testes unitários mencionados na primeira prática deste capítulo, antes de fazer o push do código para o Github. Após o envio do código para o repositório, um job de build é automaticamente disparado no servidor de integração contínua (Jenkins), onde caso o build gere algum erro, o responsável é imediatamente notificado, podendo tomar uma ação imediata para a correção do problema, refazendo o processo até que o build fique estável. 4.6 Deploy automatizado A última melhoria adotada é em relação a prática de entrega contínua, onde o processo para disponibilizar uma nova versão em produção seja o mais automático e transparente possível. Para que isto fosse algo que funcionasse 100%, deveriamos ter todos os testes possíveis implementados nos projetos (unitários, aceitação, integração), porém isso ficará para um segundo momento. Neste momento foi implementado um job que faz a publicação automática de uma versão depois que ela passa por todos os testes unitários (automáticos) e também pelos testes manuais exploratórios que a equipe de testes realiza. Como vemos na Figura 2, foram criados jobs de publish (publicação) que são disparados atualmente de forma manual, porém executando automaticamente todo o processo mostrado na Figura 3 apenas informando na hora da execução qual é o número da tag que deverá ser publicada em produção. 5. Conclusão Conforme proposto, este artigo mostrou a implementação de algumas técnicas de integração contínua e automação de testes. Em cada prática pudemos verificar que houve uma melhora no desempenho do time e no desempenho do processo executado, tornando-o mais automático com menos probabilidade de ocorrerem erros. A prática de automação dos testes unitário se mostrou bastante eficiente, uma vez que a mesma quantidade de testes para serem executados de forma manual levava em torno de 3 horas de um membro da equipe, geralmente o tester. Considerando que as equipes geralmente são formadas por até 3 desenvolvedores, 2 designers e apenas 1 tester esse trabalho era bastante exaustivo e suscetível a erros. Outra prática que obteve bastante aceitação e gerou um impacto forte no processo foi o build e o deploy automático, uma vez que desenvolvedores não precisam mais executar as tarefas repetitivas dos passos de build e deploy da aplicação, tendo mais tempo para trabalhos mais criativos e menos repetitivos. Por fim, agora conseguimos obter feedbacks muito mais rápidos das aplicações, integrando o código continuamente, investindo tempo na automação de tarefas e testes, podendo encontrar defeitos antecipadamente e tornando então mudanças no software muito menos problemáticas.
  • 12. Referências Beck, K., Beedle, M., Bennekum, A. van and et al (2001) “Manifesto para Desenvolvimento Ágil de Software”, http://www.agilemanifesto.org/iso/ptbr/, Janeiro Dustin, E; Rashka, J; Paul, J. (1999), Automated Software Testing: Introduction, Management, and Performance. 1st edition. Fowler, M. (2013) “ContinuousDelivery”, http://martinfowler.com/bliki/ContinuousDelivery.html, Janeiro. Fowler, M. (2006) “Continuous Integration”, http://martinfowler.com/articles/continuousIntegration.html, Janeiro. GitHub. (2014) “Field-tested tools for any project”, https://github.com/features, Janeiro. Humble, J.; Farley, D. (2010), Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. 1st edition. Rouse, M. (2014) “Automated software testing”, http://searchsoftwarequality.techtarget.com/definition/automated-software-testing, Janeiro. Wells, Don. (2009) “Agile Software Development: A gentle introduction”, http://www.agile-process.org/, Janeiro.