Buenas, pessoal?! E aí, como foram as festas de final de ano? Esperamos que, entre suas promessas para o ano de 2018, uma delas tenha sido: “Pelos poderes de Grayskull, farei mais testes!”

Então, vamos para o segundo post da nossa série sobre qualidade de software? Se você ainda não leu ou não lembra do primeiro post, dá uma olhada lá: 7 motivos para considerar o teste de software indispensável

Neste post falaremos um pouco mais sobre motivação. Mas, agora que você já acredita que teste de software é indispensável, vamos apresentar para você as vantagens da automação de testes.

Veremos alguns dos principais benefícios que os testes automatizados trazem e o porquê deles estarem ganhando terreno cada vez mais. Na verdade, se compararmos com alguns anos atrás, observamos que hoje está se seguindo uma onda cultural: as pessoas estão se dando conta que a automação (não apenas de teste) é o principal meio para escalar o desenvolvimento de software no mundo atual e futuro.

Let’s go!

Mas então, quais os benefícios da automação de testes?

Bom, já sabemos que fazer verificações em nosso software é algo indispensável. Testar passou de algo, que era feito quando sobrava tempo, para algo que surge desde a concepção dos projetos. Assim, passou a ser um fator decisivo na garantia de qualidade a possibilidade de sempre (a cada alteração) verificar que o nosso software está atendendo às expectativas dos nossos usuários.

Mas, aí aparece alguém e fala: não tem como testar tudo sempre! Teste é caro, trabalhoso e chato.

Neste momento, eu reajo assim:

Mas depois de alguns minutos meditando ao som de uma melodia celta, tenho que concordar que esse é o cenário mais encontrado ainda hoje. Levando em consideração uma bateria completa de testes manuais, em um sistema complexo (ou nem tanto), torna-se inviável executar todos os testes a cada alteração do software.

Esse cenário nos leva à alguns fatos sobre testes manuais:

• Eles são naturalmente lentos, pois precisam de ação e supervisão humanas. Quanto maior o número de passos de verificação, maior o tempo necessário para que uma pessoa prepare, execute e analise a suíte de testes completa.
• Dependendo da forma como são executados, os testes manuais podem não ser confiáveis. Por exemplo, dependendo da complexidade dos passos de preparação e verificação, e de sua descrição, a pessoa que os executa talvez tenha que seguir seu feeling. Assim, alguém sem a devida preparação pode acabar executando o teste de forma inapropriada.
• Uma característica comum dos testes manuais é que eles são apegados ao ambiente. Dificilmente você consegue portar um desses testes para outros ambientes, ou precisa de algum esforço em configurações para fazer isso. Sabe aquela história de que “funciona no meu PC/notebook/celular/tablet/Hal 9000/ábaco”? Pois é, os testes manuais adoram ouvir essa história antes de dormir.
• Testes manuais são inerentemente caros, se levarmos em consideração o custo em alocação de pessoas e tempo gasto. Eles exigem uma série de preparações por parte de quem vai executar, a obtenção de evidências para montar os relatórios de resultados, e assim por diante. No fim, tudo isso tem validade somente até a próxima alteração do software. 🙁

Em resumo, nosso desejo é poder realizar nossas verificações de uma forma escalável, confiável, barata e contínua. Para que sempre possamos garantir que estamos atendendo os nossos usuários da melhor forma, sem falhas e com alinhamento de expectativas.

Na verdade, nós esperamos que as possíveis falhas sempre fiquem nos filtros dos testes, e não cheguem até os usuários.

Queremos passar disso:

Para isso:

Vamos explorar agora cada um dos benefícios em se ter e usar testes automatizados. E veremos que tudo se encaixa nas exigências atuais para um processo eficiente de desenvolvimento de software.

Escalabilidade

Definitivamente, não é possível escalar a execução de testes manuais. Se considerarmos apenas o tempo que uma pessoa dispensa para realizar o setup e alcançar condições minimamente aceitáveis para confiar no resultado do teste, já concluímos que não será possível fazer essas verificações a cada alteração. Principalmente se forem alterações muito frequentes.

Logo, com automação de testes, nós conseguimos manipular nossas verificações para atender praticamente qualquer número de alterações. Também podemos escalar a execução dos testes em localização. Pois, com os devidos cuidados (automações e gerência de configuração e dados), os testes se tornam portáveis para praticamente qualquer ambiente.

Também podemos contar com a possibilidade de paralelismo. Em muitos cenários, é possível executar testes em paralelo, diminuindo consideravelmente o tempo dispensado para executar uma bateria completa de testes.

Confiabilidade

Uma das principais características dos testes automatizados é o determinismo. Com certeza, isso exige um cuidado por parte de quem automatiza. Pois, se os testes são aplicados em ambientes sem gerência de estado, essa característica se perde e as execuções podem se tornar instáveis.

Contudo, assumindo um ambiente devidamente controlado e uma gerência de configuração e de dados adequada, podemos dizer que os testes sempre são executados da mesma maneira. E isso os torna naturalmente confiáveis, ainda mais se comparados a procedimentos manuais.

Se com testes manuais nós dependemos da atenção e conhecimento de uma pessoa, com testes automatizados nós temos tudo isso codificado. Então, qualquer pessoa, até mesmo com pouca experiência, consegue executar um teste de forma confiável.

Com o devido processo de revisão do código dos testes e a determinação adequada do procedimento de verificação, podemos confiar que o software foi devidamente coberto e os resultados representam o certo ou errado absoluto.

Ciclos de feedback mais rápidos

A automação de testes, combinada com outras automações no processo de desenvolvimento de software, promove ciclos de feedback mais rápidos. Problemas de qualidade, configuração e implantação podem ser detectados antecipadamente e tratados de modo a reduzir totalmente (ou quase todo) o impacto no usuário final.

O State of DevOps Report de 2017, oferecido por Puppet e DORA, fala sobre automação como uma vantagem das organizações de alto desempenho:

Automation is a huge boon to organizations.

High performers automate significantly more of their configuration management, testing, deployments and change approval processes than other teams. The result is more time for innovation and a faster feedback cycle.

A automação se tornou um fator competitivo das organizações. Se o tempo é otimizado com automação de processos e tarefas, sobra tempo para atuar naquilo que realmente faz a diferença: inovação.

Redução de custos

Muitas pessoas acham que a automação de teste exige um grande esforço e acaba elevando os custos de desenvolvimento. Mas é exatamente o contrário. 🙂

A automação de teste exige um esforço inicial como qualquer outra atividade dentro do desenvolvimento de software. Mas, esse esforço é logo compensando. As reduções de custo se apresentam na forma de:

• maior facilidade na obtenção de feedback dos testes → promove uma execução facilitada. Pois possibilita diversos meios de disparo (desde botões em interfaces de ferramentas até uma simples chamada de comando em um terminal). E também torna possível uma análise de resultados pró-ativa, dado que muitas ferramentas oferecem relatórios consolidados e métodos de disparo para outras tarefas automatizadas.
• menor investimento financeiro em pessoas executando tarefas repetitivas → as pessoas deveriam ser pagas para realizar tarefas de alto valor, que exijam capacidades cognitivas e raciocínio que só humanos possuem (coisas que máquinas não podem fazer). É um grande desperdício manter pessoas fazendo tarefas repetitivas e enfadonhas, que aumentam a chance de falhas decorrentes naturalmente de esforços repetidos.
• escalabilidade para execução a cada alteração → escala, tanto em pessoas, quanto em tempo, pois possibilita um número menor de pessoas envolvidas com o processo de execução de testes e promove um tempo menor em etapa de setup. Isso permite executar os testes com uma frequência muito maior, se comparado com uma abordagem manual.
• diminuição do retrabalho → com verificações podendo ser executadas continuamente, um menor número de defeitos chegam até a entrega final do software, diminuindo consideravelmente o custo em retrabalhos.

O paper End-to-end test automation – A behavior-driven and tool-agnostic approach, publicado pela Infosys, traz uma abordagem que busca reduzir a complexidade da automação de testes e torná-la ainda mais útil na promoção de feedback contínuo. Com essa abordagem, eles chegam a citar reduções entre 40% e 60% no custo de geração de casos de teste automatizados, em comparação com testes manuais.

Aderência à cultura DevOps – CI e CD

Dentro do contexto das práticas de desenvolvimento, conhecidas como Continuous Integration (CI) e Continuous Delivery (CD), parte da alma da cultura DevOps, existe a ideia de Continuous Testing. Testar continuamente é uma necessidade porque as entregas precisam ser garantidas, o processo de desenvolvimento deve ser fluído e falhas em produção devem caracterizar raríssimas exceções.

Mas então, como testar continuamente? Automação de testes é a resposta.

Se seu software está coberto com um conjunto considerável de testes automatizados, saiba que você já tem meio caminho andado para um pipeline de CD.

Os pipelines de CD são conhecidos por terem etapas de testes automatizados organizados por velocidade de feedback. Isso significa que testes que fornecem resultados mais rápidos e focados são alocados nas etapas iniciais do pipeline. Já testes mais demorados e abrangentes são colocados nas etapas posteriores. Por exemplo, análise estática e testes de unidade normalmente são os primeiros do pipeline. Pois, fornecem uma resposta muito rápida quanto a falhas e irregularidades inaceitáveis do software.

No fim, apenas testes automatizados são capazes de escalar nesses cenários, tendo em vista que podem ser executados a cada alteração do software sem intervenção humana e podem ter sua duração gerenciada.

Segundo o State of DevOps Report 2017, a automação de testes é o fator com maior contribuição positiva no processo de CD:

Quando automatizar vale a pena?

É claro que não podemos automatizar tudo. Embora a automação de testes traga muitos benefícios, existem cenários e situações onde isso se torna inviável. Por exemplo, alguns testes como usabilidade e aceitação do usuário são normalmente escolhidos para serem realizados de forma manual, dada a sua complexidade e dinâmica de execução. E de fato, no Dzone’s Guide To Automated Testing: Improving Application Speed and Quality, foram entrevistados 434 profissionais que trabalham com software. Entre esses profissionais, os testes manuais são preferidos para testes de aceitação (78%), testes de usabilidade (70%) e testes a nível de história de usuário (63%). Por outro lado, os testes mais comumente automatizados são os testes de integração (61%), de unidade (58%) e de desempenho (56%).

Então, como saber se vale a pena automatizar determinados testes? Abaixo escolhemos alguns fatores que podem ajudar a identificar quando automatizar é viável:

• Existência de um processo bem definido
• • Anote todos os pré-requisitos, todas as condições que precisam ser atendidas antes do início do teste. Depois registre cada passo que precisa ser executado. Por fim, descreva o que precisa ser feito para verificar o resultado.
  • Faça uma execução manual a partir do que você registrou. Verifique se o processo é sempre o mesmo, se as fases de execução são bem definidas e não precisam de interpretação cognitiva. Em caso afirmativo, há grandes chances de que seja um teste automatizável.
• Tarefa repetitiva
• • Se existe uma tarefa que sempre é executada do mesmo jeito, sendo totalmente repetitiva, certamente ela é automatizável.
• Ausência da necessidade de supervisão humana (sensores automatizados)
• • Se você consegue iniciar e terminar um teste de forma tão tranquila que você até dorme melhor à noite, então é quase certo que você consegue automatizar.
  • Preste atenção nos “sensores” do teste. Eu posso começar o teste a qualquer momento? Eu consigo detectar claramente quando ele termina? Eu consigo detectar o certo ou o errado de modo objetivo?
• Calcular o ROI
• • Calcular o retorno de investimento ajuda a identificar a viabilidade da automação, verificando quanto, de fato, será reduzido em custos.
  • O artigo The True ROI of Test Automation, publicado no blog da Abstracta, fala de uma forma bem resumida sobre como calcular o retorno de investimento para a automação de testes. Inclusive, nesse artigo, é citado que os defeitos encontrados e corrigidos na fase de pós-entrega chegam a custar cinco vezes mais do que quando encontrados durante a fase dos testes de unidade.

Por onde começar?

Dê preferência para começar pela parte mais fácil e que exija a menor curva de aprendizagem. Em outras palavras, comece pelo tipo de teste automatizado que cause o menor impacto em seu cotidiano e de sua equipe, facilitando a aderência dos profissionais.

Normalmente, o teste de unidade é o caso ideal para se começar. Além de mais barato, rápido e fácil de aprender, ele caracteriza o primeiro passo na qualidade agregada. Os testes de unidade estão próximos do código, são focados e oferecem uma depuração facilitada.

Se pensarmos bem, o teste de unidade é a verificação mais básica que poderíamos ter: a verificação da menor unidade de código testável. Então, com alguns passos básicos, nós podemos começar praticando ele:

• Analise o que cada unidade (método/função) de seu código está fazendo;
• Faça um levantamento do objetivo da unidade que você está desenvolvendo;
• Registre os casos de sucesso e de falha possíveis ao executar essa unidade. Busque todos os caminhos possíveis. #dica: leia sobre complexidade ciclomática;
• Escreva um teste que represente um caminho dentro da unidade e veja o teste falhar. Depois conserte o teste e veja ele passar. Por fim, melhore o código do teste e, consequentemente, o da sua aplicação. #dica: leia mais a respeito de Red-Green-Refactor.

E não esqueça, quando seu teste passar, para dar sorte, você deve fazer assim:

Outra abordagem para a escrita de testes de unidade é o TDD (Test Driven Development). Vamos falar mais disso em outro post, mas você pode ler mais a respeito no livro Test Driven Development: By Example, do Kent Beck, ou TDD: Teste e Design no Mundo Real, do Maurício Aniche.

Os próximos posts da série serão mais técnicos. Começaremos a colocar a mão na massa. 😀

Até lá! E…