Melhoria do desenvolvimento de software utilizando
práticas de Integração Contínua e Testes Automatizados
Alex Warmling1
,...
equipe para que sejam implantados e funcionem, como as práticas ágeis descritos no XP
(eXtreme Programming) e no SCRUM, po...
desenvolvimento, pois não se tem uma ordem exata para a sequencia de cada tarefa
dentro de um time técnico. Após o levanta...
pessoas a pensarem que o Agile development 1
é sinônimo de agilidade, mas não, é
apenas uma outra metodologia que prevê ou...
 Progresso crível: onde é preferível se ter o pacote em produção do que apenas
acreditar que o desenvolvedor o fez pois m...
Para este estudo utilizaremos a ferramenta GitHub, pois é um serviço hospedado
na nuvem, diminuindo a complexidade de algu...
montado, porém o backend7
é quase sempre o mesmo. As etapas de desenvolvimento da
aplicação e de testes eram bastante trab...
pudessemos analisar se haveria uma real melhoria na qualidade e no tempo de execução
das tarefas. No contexto do time estu...
Figura 5. Testes executados com sucesso
Estas ferramentas possibilitam ainda que se possa verificar a quantidade de
linhas...
unitários implementados no passo anterior quando se roda o comando “grunt”. Através
deste comando também é possível que se...
problema, adotou-se a prática de rodar localmente o projeto, fazendo o build automático
dele, onde já são executados també...
Referências
Beck, K., Beedle, M., Bennekum, A. van and et al (2001) “Manifesto para
Desenvolvimento Ágil de Software”, htt...
Próximos SlideShares
Carregando em…5
×

Artigo-Alex_Warmling

208 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
208
No SlideShare
0
A partir de incorporações
0
Número de incorporações
19
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Artigo-Alex_Warmling

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

×