Nos últimos anos, na área de TI, muito tem se ouvido falar em DevOps.

Esta cultura tem tornado cada vez menos rígida a fronteira entre o desenvolvimento e as operações de TI necessárias para manter os sistemas no ar.

Diante dos muitos benefícios trazidos pela adoção das práticas de DevOps, principalmente em times ágeis, quais seriam as razões para que esta cultura tenha ganhado força somente num passado recente? Que fatores motivam as práticas de DevOps? Que fatores permitiram que o DevOps se tornasse uma realidade?

No post de hoje vamos elicitar 3 grandes motivadores da cultura DevOps na atualidade.

O conflito histórico entre equipe de infra e equipe de desenvolvimento parece estar com os dias contados. As práticas de DevOps vem com o objetivo de facilitar a integração entre atividades de desenvolvimento, como criar novas features, resolver bugs, etc, e as operações de infra para manter o sistema no ar como manutenção dos servidores, sincronização e deploy do código, etc.

Realizar estes dois tipos de tarefas de forma coordenada pode trazer diversos benefícios através da colaboração entre os profissionais que criam e testam as aplicações e as equipes que mantém todo o ambiente de produção no ar. Para mais informações sobre DevOps, leio o post "Já Ouviu Falar em DevOps?".

Como falei no início do post, os processos de DevOps começaram a marcar presença mais fortemente nos times de TI somente nos últimos anos. Principalmente pela constante necessidade de mudanças e, consequentemente, pela maior necessidade de agilidade nas entregas, o cenário que encontrado em muitos times de desenvolvimento praticamente "pedia" a aplicação dos processos de DevOps.

Entender os motivos que levaram a ascensão destas práticas pode ajudar na aplicação das mesmas de forma a extrair o máximo dos benefícios trazidos com as técnicas de DevOps. Abaixo, enumeramos 3 grandes fatores que ajudam a entender o porquê da adoção e valorização das práticas de DevOps atualmente:

1. Cultura Ágil

Dentre tantas melhorias, como os avanços nos meios nos setores de telecomunicação e tecnologia da informação tornaram a realidade das organizações cada vez mais dinâmicas.

Com ambientes mais dinâmicos surge a necessidade de maior flexibilidade e respostas mais rápidas às mudanças. Mais especificamente na área de TI, é preciso que os sistemas sejam desenvolvidos e mantidos de maneira que mudanças possam ser aplicadas com agilidade.

É necessário estar continuamente entregando valor. Para que isso seja possível é preciso que, uma vez desenvolvido, um sistema possa ir para produção rapidamente e com qualidade. Um gargalo que pode ser comumente encontrado é na burocracia muitas vezes imposta pelas equipes que mantém os sistemas no ar. Para estas equipes, a priori, mudanças não são bem vindas e estão sempre associadas a riscos. Porém, para o negócio as mudanças tem se tornado cada vez mais necessárias.

O tempo entre o desenvolvimento de um recurso e o deploy em produção pode ser um fator determinante para o sucesso ou fracasso de uma iniciativa de uma organização. Diante deste cenário é possível notar os processos de DevOps surgem como uma prática interessante na medida em que permitem que as mudanças sejam levadas rapidamente para produção de forma coordenada e com qualidade, reduzindo o time to market.

As práticas de DevOps tratam de tornar mais eficientes e, quando possível, automatizar todas as operações necessárias para que um código saia do desenvolvimento e chegue em produção com rapidez e qualidade, que é o que se pretende dentro da cultura ágil.

2. Tecnologia

Operações como realizar deploy de forma bem controlada, gerar de pacotes, executar testes, automatizar scripts para sincronização de pacotes, dentre outras operações não são desejos recentes na TI.

Antes mesmo do crescimento da cultura ágil e da necessidade de entregas contínuas, a automatização de operações de TI já era um desejo em muitos times. Podemos nos perguntar: Então por que estas operações ganharam maior atenção agora com as práticas de DevOps?

O primeiro ponto que me vem em mente é o fator financeiro. Antigamente, responder rápido a mudanças era algo não tão "lucrativo" quanto hoje. Primeiro porque o custo para automatizar estas operações era mais alto.

Segundo, por que a necessidade por respostas rápidas a mudanças não era tão grande quanto hoje.

Outro ponto é a tecnologia. Atualmente com a virtualização e computação na nuvem, além da alta capacidade de processamento das máquinas, ficou facilitada a construção de ferramentas voltadas para o apoio às operações de TI, como automatização de testes e gerência de configuração,por exemplo. Além disso, os crescentes investimentos em aplicativos para dispositivos móveis tem impulsionado criações e atualizações que precisam ser lançados frequentemente com agilidade e qualidade.

3. Infra estrutura mais complexa

Manter os sistemas de uma organização no ar tem se tornado uma tarefa cada vez mais complexa. Atualmente, muitas são as formas de disponibilizar as aplicações no ar. A manutenção, que antes era feita somente sobre as máquinas físicas, hoje é feita sobre máquinas físicas, máquinas virtuais, além da nuvem.

Estes novos recursos permitem que as equipes responsáveis por manter os sistemas no ar tenham maior previsibilidade, garantias e SLA bem definidos na manutenção de seus sistemas.

Por outro lado, a complexidade decorrente destes serviços requer que as operações de TI estejam bem definidas e automatizadas na medida do possível, para garantir que os benefícios alcançados com estes serviços sejam alcançados.

A partir destes 3 grandes fatores fica fácil perceber a necessidade e os benefícios que o DevOps pode trazer às organizações atuais.

Para o desenvolvimento ágil é importante que as operações sejam feitas com a colaboração de todo o time, conferindo mais rapidez nas entregas, e economizando nas burocracias.

Métricas importantes como o Time to market são afetadas diretamente com a implantação das práticas de DevOps, que pode reduzir significativamente o tempo necessário para que um produto seja disponibilizado no mercado.

The post (Português) 3 Motivadores para a Cultura DevOps appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Quando falamos em testes automatizados, o que vem primeiro à cabeça? Testes que simulam o usuário utilizando uma aplicação, através da UI (User Interface)? Testes de unidade (ou unitários)? Neste post, vamos mostrar os níveis de testes automatizados dentro do Agile e como melhorar a estratégia de automação de testes da sua empresa.

Em empresas que estão começando a trabalhar com testes automatizados, é comum vermos o uso de ferramentas do tipo record-playback, como o Selenium IDE, para criar scripts de testes validando cenários de ponta-a-ponta em uma aplicação, através da UI. Esses testes também são chamados de Testes de Aceitação. Ferramentas como essas facilitaram bastante a criação desses testes, permitindo até que um usuário possa gravar um teste, sem requerer skills de programação. Soluções pagas, como as da IBM, HP e Microsoft, também oferecem ferramentas desse tipo.

Infelizmente, também é comum cair na "tentação": gravar centenas de testes que navegam pela UI, só percebendo que algo está errado quando um novo campo é incluído em uma tela, ou quando o identificador de um elemento é alterado, por exemplo. A médio/longo prazo surgem os problemas: o custo de manutenção se torna alto, os testes demoram muito para rodar (aumentando tempo de build) e dar feedback sobre o sistema, muitos testes falham devido a falsos negativos, etc.. Com isso, o time acaba perdendo a confiança nos testes e, muitas vezes, deixando de rodá-los.

Essa preocupação com o tempo de build e de feedback dos testes não vem dos dias de hoje. No XP (Extreme Programming), na parte sobre Integração Contínua [1], já se falava da importância do "10-minute build". James Shore, no livro The Art of Agile Development, cita o "10 or 15-minute build", que seria o tempo máximo razoável para obter feedback do seu build. Em suas próprias palavras, "That's about the right amount of time to stretch my legs, get some coffee, and talk over our work with my pairing partner". O assunto é tão relevante, que Dan Bodart, em sua palestra Crazy Fast Build Times – Or when 10 seconds starts do make you nervous, mostra maneiras de reduzir em até dez vezes o tempo de build de uma aplicação.

Em empresas que possuem times ágeis, testes de unidade (e também o TDD) já nos ajudam muito nessa situação. Quando temos uma boa quantidade de testes de unidade para um sistema, se faz menos necessário automatizar testes tão exaustivos pela UI. Testes de unidade são fáceis de manter, são muito efetivos para testar valores limite ou possíveis combinações de desvios dentro do código e rodam extremamente rápido, nos dando um bom feedback sobre nosso sistema em pouco tempo. Porém, por definição, estamos testando comportamentos de componentes isolados, de forma que uma hora ou outra deveríamos testar a integração entre eles, certo? Logo, criamos então um teste que navegue pela UI para validar isso? Não!

Pirâmide de Automação de Testes

Em seu livro Succeeding with Agile, Mike Cohn descreve o conceito da Pirâmide de Automação de Testes (Test Automation Pyramid).

Segundo Cohn, uma estratégia eficiente de testes automatizados deve contemplar testes em três níveis: Unidade, Serviço (Integração) e UI. Na base da pirâmide, temos uma grande quantidade testes de unidade, que devem ser a base de uma boa estratégia de testes automatizados. No topo, uma quantidade pequena de testes de UI, justamente para evitar os problemas que comentamos anteriormente. No meio, temos uma quantidade razoável de testes de serviço, que também podem ser chamados de testes de integração, API Tests, etc.. Cohn, no artigo The Forgotten Layer of the Test Automation Pyramid, comenta sobre a importância desse nível de teste e seu papel em preencher o gap entre unidade e UI.

Testes na camada de serviço testam, basicamente, os serviços da aplicação, “abaixo” da UI. Essa abordagem evita com que todo teste, além do teste de unidade, seja executado diretamente navegando pela interface do usuário. Com isso, em vez de executarmos testes exaustivos validando todas as regras de negócio pela interface, podemos fazer testes abaixo da UI. Esse tipo de teste tem sido muito importante, visto que muitas aplicações hoje em dia possuem interfaces Web e Mobile (smartphone, tablet), sendo necessário separar a interface da lógica da aplicação. Martin Fowler se refere a esses testes com o nome de Subcutaneous Tests.

Dentro do Agile, podemos fazer esses testes para validar os critérios de aceite das histórias, por exemplo. Uma boa abordagem é o uso de BDD (Behaviour-Driven Development) [2]. Para aplicações Java, existe o Arquillian, que tem diversos recursos para criação desses testes, além de extensões que ajudam na criação de testes com Selenium WebDriver e Page Objects.

Testes na UI

Com testes na camada de serviço, não precisamos validar todas as regras de negócio de um sistema pela UI. Podemos focar esses testes em funcionalidades críticas (Smoke Tests), em testes que validem aspectos da interface, ou em testes com diversos browsers (xBrowser Testing). Smoke Tests formam o subconjunto dos testes mais importantes, que garantem que a aplicação está realmente OK. O ISTQB (International Software Testing Qualifications Board) os define como:

                "Subconjunto de todos os casos de testes definidos/planejados que cobre as principais funcionalidades de um componente ou sistema, para averiguar as principais funções de um programa em funcionamento sem se preocupar com maiores detalhes."         

Quando concentramos os testes automatizados para a camada de UI, como descrevemos no início do post, em vez de termos uma pirâmide, temos o chamado "Ice-cream Cone", vide figura abaixo:

Como evitar os problemas de testes na UI?

1. Uso do pattern Page Objects

Padrão preconizado pelo próprio Selenium, que propõe separar os testes da complexidade da UI, melhorando a legibilidade, manutenibilidade e reusabilidade do código.

Importante: Tratar código de teste como código de produção!

2. Uso de Headless Browsers

Headless Browsers funcionam da mesma forma que browsers comuns, com a diferença de não ter uma interface gráfica. São mais rápidos para testes e são muito bons para usar com Integração Contínua. Hoje em dia, o mais popular é o PhantomJS, que utiliza a engine gráfica WebKit, a mesma usada pelo Google Chrome. Há também o SlimerJS e o HtmlUnit.

Frameworks e headless browsers suportados:

• Selenium WebDriver

   

  • HtmlUnit, através do HtmlUnitDriver
  • PhantomJS, através do GhostDriver
• Capybara

   

  • HtmlUnit, através do Celerity
  • PhantomJS, através do Poltergeist
• CasperJS

   

  • Suporta o PhantomJS (engine WebKit) e o SlimerJS (engine Gecko)

 3. Uso de BDD

Existem diversos frameworks para ajudar na adoção de BDD, como:

• JBehave (Java)
• Cucumber (Ruby, Java, etc.)
• SpecFlow (plataforma .NET)
• easyb (Groovy)

 4. Paralelizar testes

É possível rodar testes em paralelo, diminuindo bastante o tempo de execução. Pode-se usar TestNG, Maven e Selenium Grid para tal.

Finalizando, recomendo a leitura do artigo Eradicating Non-Determinism in Tests, do Martin Fowler e da palestra Lições do Futuro: O que eu queria saber há alguns anos atrás sobre como manter uma suíte de testes, do Eder Ignatowicz e Fabio Santos, apresentada nas edições 2012 e 2013 do TDC. Compartilhem suas dúvidas nos comentários!

Referências:

http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

http://martinfowler.com/bliki/TestPyramid.html

[1] https://blog.myscrumhalf.com/2012/06/a-integracao-continua-utilizada-no-dia-a-dia-do-desenvolvimento-agil/

[2] https://blog.myscrumhalf.com/2011/10/bdd-%E2%80%93-foco-no-comportamento-do-sistema/

The post (Português) Melhorando sua Estratégia de Testes Automatizados appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Olá Pessoal, no post de hoje irei falar sobre o Agilte Tester, o testador ágil. Esse termo é utilizado no livro Agile Testing: A Practical Guide for Testers and Agile Team para identificar o testador que está alinhado com os princípios e valores ágeis.

Em projetos de software, testes sempre são um motivo para discussão. Em projetos tradicionais, normalmente há uma gerência (Gerência de Qualidade) e uma equipe (Equipe de Garantia de Qualidade) que são responsáveis por especificar e realizar os testes. A Equipe de Garantia de Qualidade busca encontrar erros, sejam erros de não conformidades com normas técnicas ou não atendimento de requisitos do software. Por outro lado, em projetos ágeis, essa burocracia pode atrapalhar bastante o andamento do projeto. Atualmente, técnicas como o TDD indicam que os testes deve ser escritos e executados pelos próprios programadores, quebrando um pouco a prática tradicional.

Agile Testing é mais do que isso, é uma forma de utilizar os valores ágeis para auxiliar o testador, o chamado Agile Tester, o ajudando a fazer melhor seu trabalho, a ajudar seu time a entregar um maior valor de negócio para o projeto a cada iteração. Logo, não basta escrever um teste automatizado em um projeto ágil para falar que no projeto se faz Agile Testing e que a pessoa é um Agile Tester, alguns princípios devem ser seguidos para reforçar os valores da agilidade.

No livro são discutidos um conjunto de 10 mandamentos do Agile Tester, que irei apresentar abaixo.

1. Forneça Feedback Contínuo

Como a ideia é utilizar esses conceitos em projetos ágeis, o conceito de feedback contínuo não é nenhuma novidade. Uma das principais funções do testador é apoiar o Product Owner e o Cliente à escrever os requisitos de cada user story, na forma de exemplos e testes.

2. Entregue valor para o cliente

Desenvolvimento ágil é entregar valor em ciclos curtos para o Cliente. Nesse caso, o testador deve ficar atento às mesmas, se estão exatamente de acordo com o que o Cliente priorizou recentemente. Agile Testers sempre estão focados no projeto como um todo, i.e., as funcionalidades mais importantes de cada release devem estar prontas para serem entregues, mesmo que com isso, outras funcionalidades devam ficam em segundo plano.

3. Buscar a comunicação olho no olho

​Nenhum time funciona bem sem uma boa comunicação. Como hoje em dia existem times distribuídos, em diferentes continentes, trabalhando no mesmo projeto, o Agile Tester deve buscar uma forma única para facilitar a comunicação com todos da equipe.

4. Tenha coragem

​Coragem é um valor importante em projetos ágeis, práticas como testes automatizados e integração contínua permitem ao time praticar esse valor. O time deve ter coragem de realizar mudanças, mas, sem uma suite de testes de regressão automatizados, essa mudança pode ser muito insegura. O Agile Tester deve ter coragem para encontrar os erros de outros e ajudá-los a não cometerem o mesmo erro. Deve ter coragem de pedir ajuda, mesmo quando quem pode ajudá-lo for uma pessoa de difícil acesso.

5. Mantenha a simplicidade

​Agile Testers e seus times não devem apenas produzir o sofware mais simples possível que atenda aos requisitos do cliente, mas também devem encontrar a forma mais simples de medir se o software atende a esses requisitos. Logo, medições são importantes, mas, não devem ser uma barreira para a condução do projeto.

6. Pratique a melhoria contínua

​O Agile Tester sempre deve estar em busca de novas ferramentas, técnicas, habilidades ou práticas que auxiliem em seu trabalho de garantir que os desejos do cliente serão atendidos da forma mais simples possível.

7. Responda a mudanças

​Apesar de esse ser um dos valores mais importantes para times ágeis, é um dos mais difícies conceitos para Agile Testers. Pois com a estabilidade, o testador pode dizer que, após ele testar algo, aquilo está pronto. Entretanto, a adaptação a mudança é necessária, logo, a utilização de ferramentas automatizadas para testes pode auxiliar um Agile Tester a responder a mudanças com maior rapidez e segurança.

8. Seja auto-organizado

​O Agile Tester é parte do time auto-organizado do projeto. Logo, ele deve buscar apoio de todos do time para atingir seus objetivos.

9. Foque nas pessoas

​Projetos de sucesso são aqueles onde boas pessoas conseguem fazer seu melhor trabalho. Como o tester encontra erros, ele deve fazê-lo sempre respeitando a todos da equipe, nunca focando na pessoa que cometeu algum erro, mas sim no erro que foi cometido, para evitar algum mal estar entre os membros da equipe e ajudar a todos a não cometerem os mesmos erros.

10. Aproveite

​Trabalhe em um time onde se sinta confortável, ninguém consegue realizar um bom trabalho em um ambiente ruim.

Finalizando, pode-se perceber que o Agile Tester deve estar alinhado com os princípios e valores ágeis, todos os 10 mandamentos são baseados neles. E você, se considera um Agile Tester??

Deixe seu comentário e vamos continuar esse bate papo…

Referência:

• Agile Testing: A Practical Guide for Testers and Agile Team

The post (Português) 10 Mandamentos de um Agile Tester appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The Sprint Review has already been the subject of a few posts on this blog, as in What is the Sprint Review meeting? – FAQ Scrum. The reason for that is, although sometimes this meeting is not given the ideal attention, it is in fact one of the most important points of inspection and adaptation of the Scrum cicle, especially concerning the product itself.

One of the reasons of this undervaluation is because, in some cases, people think that the Sprint Review exists so we can test the product generated during the Sprint and, indeed, this can be done by the product testers, without the need of a meeting with stakeholders, PO and development team together. However, the mistake here is to assume that the Sprint Review meeting is only to test what's being delivered. And it is to desmistify this belief that we're going to see why this meeting is so important.

#1: It is time to check what was done and see if it suits and pleases you!

The main goal of the Sprint Review is to show the stakeholders and the PO what has been done during the Sprint development, not to initially test the release. When a product backlog item is put in the Sprint Backlog, there is a expectation that, by the end of the Sprint, that problem will be solved and accordingly to the wanted quality levels. It is why during a Sprint Review the PO has the power to approve and disapprove the itens of the Sprint Backlog. He needs to evaluate if the expectated value has been achieved and delivered. If yes, he approves the item. If not, disapproves.

#2: Ok. We are pleased with the Sprint results. But is this the path we want the product to follow?

The Sprint Review meeting also is the moment where you reunite PO, development team and stakeholders so that everyone can see what the product is like now and discuss whether it is on the right path.  The planning of the next Sprint will be done at another moment, but it is during the Sprint Review meetings that new suggestions to the Product Backlog come up and it is good that they do. It just shows that everybody is involved with the project, looking for the product's success and talking about the best direction for it.

#3: Nah… not pleased, no. We have to change some things around here.

Well, not everything is just happiness. Sometimes some itens of the Sprint Backlog are going to disapproved, but it is not because they are unfinished or have bugs, for example. They are going to be disapproved just because the PO didn't accept them. And it is important that this is done in person, during the meeting, so that the development team can really understand why that item wasn't approved and what needs to change so that it won't happen again.

#4: Fine… it is also the first opportunity to test the product.

Ok, it is possible to run initial testes during the Sprint Review meeting, but it is important to know that it is not the goal of the meeting and that, in fact, the tests there are going to an evaluation of the requirements. Testing how it is functioning is going to be really superficial.

If we take a look at Agile Testing book, we'll see that this evaluation fits the quadrant number 3 of Agile Testing Quadrants, as we can see below.

These quadrants are there to represent the different ways of testing a feature in an agile way. In the case of Review meetings' tests, our goal is to criticise the product from the business point of view. Thus, our tests during the Review meetings will criticise different scenarios, usability, user acceptance, validating the product and the business and not how the requirement is functioning.

#5: And also a time for learning…

Another advantage of the Sprint Review meeting is that it is an opportunity to show how to use the new feature and to explain, step by step, the actions necessary to execute it. This avoids noise in the communication and false bug alarms, and also it is the first evaluation of the usability of the feature. If there's no doubt in how to use it, probably the usability is ok and it will be easy to understand how to use it. If any doubts come up, it's worth considering an adaptation of the feature.

#6: For the end of surprises, disappointments and frustations!

Last but not least, the Sprint Review meeting prevents that stakeholders end up having unpleasant surprises with the direction that the product ended up going. If the project is being reviewed all along, by the end of it the product generated will be just like it was wanted to, delivering the expected value and we'll prevent that cases where after years of development the product is just set aside, because it not attends the necessities to what it was created.

What about the project you participate in? How do your team see the Sprint Review? Share with us your thoughts and experiences!

References:

• Essential Scrum: A Practical Guide to the Most Popular Agile Process
• Using the Agile Testing Quadrants

The post 6 reasons why the Sprint Review is important appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Another problem related to this topic is when it is known that measurement is important, but it’s done without any planning or a clear goal. Remember that even if the cost of performing a certain measurement is low, if it is not used for any purpose, in the end it becomes expensive because it meant wasted team effort.

To solve this problem, the GQM (Goal Question Metric) was created. It’s a simple method to plan measurements so that they’re based on specific organization/project goals. In this post we propose the use of the GQM method with the SCRUM framework.

As one of the roles of a Scrum Master is to monitor and look after the team work process, the measurement should be an important ally for his work. A good practice would be to analyze the negative and positive points raised in retrospectives (especially the recurring ones) and identify the weak points in the process. For example, a negative recurrent point in the latest retrospectives may be that many bugs are being found by the client in the production version. It shows that the activity of automated testing in the work process is not performing well.

Based on this identification, it is possible to apply the GQM in planning a measurement process. For this purpose it should be defined:

• The GOAL of the measurements. E.g. improve the efficiency of the automated tests.
• The QUESTION that should be answered. E.g. what is the efficiency of the automated tests?
• The METRICS that can answer the question. E.g. number of bugs found by the client, interval between failures etc.

With these definitions it is possible to initiate the measurement program that will be followed by the team. It is also important that the Scrum Master schedule regular meetings for data analysis, where the measured data is displayed so that it is possible to draw conclusions for corrective actions (e.g. graphs, tables, etc.).

The GQM, showed in this post, is just one of many methods that can be used to plan measurements. Others may be found in guides, such as MPS.BR, CMMI and some ISOs. The important conclusion of this post is: Measurements should be planned.

The post Using the GQM method with the SCRUM framework appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.