Melhoria do desenvolvimento de software utilizando

práticas de Integração Contínua e Testes Automatizados

Alex Warmling1, Anita Maria da Rocha Fernandes

1

1Curso 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 commits

5 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.