Destravando o teste contínuo: quatro práticas para o sucesso

Pouco tempo depois de entrar em cena como uma abordagem revolucionária para a entrega de software, o desenvolvimento Agile já está em um ponto de inflexão. É claro que tudo começou com as melhores intenções. À medida que ficava cada vez mais claro que o sucesso ou o fracasso de uma empresa na era digital dependia da capacidade de fornecer rapidamente aplicações web e aplicativos móveis sem falhas aos clientes, as empresas começaram a mudar massivamente em direção a metodologia Agile de desenvolvimento, acreditando que isso as levaria para ciclos de lançamento curtos, maior qualidade do produto e clientes mais felizes. Com grande alarde e entusiasmo considerável, chegou a era do desenvolvimento Agile.

Entretanto, neste final de década, algo inesperado aconteceu. O desenvolvimento Agile parou silenciosamente. De fato, o ritmo no qual as empresas lançam softwares está diminuindo. De acordo com a Forrester ("Forrester: The Path To Autonomous Testing: Augment Human Testers First", Janeiro 2019), a porcentagem de empresas que lançam software pelo menos uma vez por mês caiu de 36% em 2017 para 27% em 2018.

Em outras palavras, para a maioria das empresas, a promessa do desenvolvimento Agile não se concretizou.

Testando como ponto de apoio

Embora não seja preciso dizer, qualquer fator isolado não é 100% responsável por uma tendência tão significativa quanto a interrupção do desenvolvimento Agile, também não é uma generalização excessiva dizer que o teste é um dos maiores obstáculos entre as empresas e os objetivos do Agile. De fato, uma pesquisa recente com desenvolvedores do Gitlab mostrou que os testes foram identificados como a fonte mais comum dos atrasos no desenvolvimento, citado por mais da metade dos entrevistados.

Embora a maioria das empresas tenha adotado entusiasticamente o desenvolvimento Agile, a maioria ainda é incapaz de implementar efetivamente o teste contínuo em todo o ciclo de vida de desenvolvimento de software.

Aí está o obstáculo. As empresas agora estão descobrindo que, quando se trata de desenvolvimento Agile e teste contínuo, não podemos ter um sem o outro. Se não conseguirmos testar as aplicações com rapidez, confiabilidade e escala, inevitavelmente teremos apenas uma opção: Diminuir o processo de entrega por conta dos testes e correr o risco de perder a data de lançamento ou, manter a data de lançamento e correr o risco de entregar uma aplicação de baixa qualidade aos clientes. Nenhuma das opções é boa e ambas vão contra o objetivo de implementar o desenvolvimento Agile em primeiro lugar, que não deve levar a uma escolha entre velocidade e qualidade. (Accelerate por Nicole Forsgren, Jez Humble e Gene Kim é um ótimo livro para quem quer se aprofundar nesse conceito.)

Superar o obstáculo do teste contínuo é, portanto, a chave para fornecer aplicações de qualidade com rapidez e cumprir plenamente a promessa do desenvolvimento Agile. Aqui estão quatro práticas importantes que as empresas podem implementar para fazer exatamente isso.

#1: Ênfase na qualidade do teste

Se quer ser bem-sucedido nos testes contínuos, a qualidade dos testes é tudo. Isso não quer dizer que não haja outras considerações importantes, as mais importantes serão abordadas neste artigo, mas praticamente todas as outras práticas recomendadas de testes contínuos são relevantes apenas na medida em que está começando com uma base de testes de alta qualidade. E o determinante mais direto e confiável da qualidade dos testes é a taxa de aprovação.

Devemos escrever, gerenciar e executardos conjuntos de testes para que a grande maioria deles seja aprovada. Agora, todos devem passar? Absolutamente não. Nenhum desenvolvedor é perfeito e uma pequena porcentagem dos testes vão falhar. O motivo pelo qual testamos as aplicações é para descobrir bugs e corrigi-los antes que sejam levados à produção, criando uma experiência ruim para o usuário. Portanto, um teste que expõe uma falha em potencial na aplicação é um teste que serviu o seu objetivo. Dito isto, há uma diferença considerável entre os testes falharem ocasionalmente e com regularidade.

Quando os testes falham ocasionalmente, os desenvolvedores podem assumir com segurança que o novo código que testaram causou a quebra de algo na aplicação e podem tomar ações rápidas para solucionar o problema (supondo claro, que estejam seguindo a próxima melhor prática também). Mas quando os testes falham de maneira consistente, os desenvolvedores começam a questionar os resultados com motivo, já que ficam sem a certeza se a falha foi causada pelo novo código ou se é um reflexo de um problema com o próprio script de teste. Quando isso acontece, é necessário acompanhamento e exploração manual, e o processo de desenvolvimento Agile no qual investimos tanto tempo e energia é interrompido.

Como trabalhei diretamente com muitas equipes de controle de qualidade, incluindo grandes empresas que executam milhões de testes por ano, geralmente recomendo que as empresas tenham como objetivo passar ao menos 90% dos os testes executados. Na minha experiência, esse é geralmente o ponto de ruptura em que o número de testes com falha começa a exceder a capacidade da empresa de acompanhar manualmente as falhas. Portanto, as empresas que se encontram consistentemente abaixo deste limite devem enfatizar mais o projeto e a manutenção dos conjuntos de testes de uma maneira que leve a uma taxa de aprovação maior e permita evitar cenários em que o número de testes com falha exceda a largura de banda definida, para implementar o acompanhamento manual apropriado. A melhor maneira de fazer isso é a partir da seguinte prática.

#2: Mantenha os testes curtos e atômicos

Um dos prognósticos mais confiáveis sobre a qualidade dos testes é o tempo de execução. Faz sentido, já que quanto mais longo e mais complexo se torna, mais oportunidades para algo dar errado. Quanto menor o teste, maior a probabilidade de aprovação. De fato, de acordo com um novo relatório de benchmark do setor baseado em milhões de testes reais de usuários finais, os testes concluídos em dois minutos ou menos têm duas vezes mais chances de serem aprovados do que aqueles que têm duração maior.

Os conjuntos de testes mais curtos não são apenas mais estáveis, mas também executam mais rapidamente. Lembre-se, o desenvolvimento Agile é, acima de tudo, velocidade. Quanto mais rápido os testes são executados, mais rápido podemos receber feedback dos desenvolvedores e mais rapidamente podemos entregar as aplicações e colocar a nova versão nas mãos dos clientes. Agora, pode parecer óbvio que os testes mais curtos executam mais rápido que os testes mais longos, mas a maioria das empresas concentra-se no número de testes em um conjunto e não na duração deles, assumindo de maneira errônea que um conjunto com alguns testes longos será executado mais rapidamente do que o conjunto com vários testes curtos. Se estiver executando testes em paralelo, alerta de spoiler de práticas recomendadas, o conjunto com diversos testes rápidos será executado exponencialmente mais rápido que o conjunto com apenas alguns testes longos.

Faça um exemplo de cenário que possui um conjunto de testes com 18 testes de fluxo longo, ponta a ponta, e um segundo conjunto com 180 testes atômicos. Em quase todos os casos, o conjunto com 180 testes atômicos será executada significativamente mais rápida do que aquela com apenas 18 testes. De fato, quando modelamos esse cenário para os clientes durante as demonstrações ao vivo, o conjunto com 180 testes atômicos geralmente é executado 8 vezes mais rápido que o conjunto com 18 testes de fluxo longo.

A capacidade dos testes atômicos

Se deseja manter os testes curtos, e realmente deveria, a melhor maneira é mantê-los atômicos, que nada mais é do que um teste com script para validar apenas um único recurso da aplicação e nada mais. Portanto, em vez de um único teste que engloba a validação do carregamento da página inicial, se os visitantes podem fazer login com nome de usuário e senha, se conseguem colocar itens no carrinho de compras e se uma transação pode ser processada com êxito, pode ser criado quatro ou cinco testes separados, cada um avaliando uma dessas funcionalidades mencionadas.

Os testes atômicos também são consideravelmente mais fáceis de serem depurados quando falham. Ser capaz de obter um feedback rápido para os desenvolvedores, é excelente. O mesmo acontece com a confiança total, de que um teste com falha sinaliza uma interrupção na aplicação, ao invés de acreditar que o script esteja com falha. O mais importante é a capacidade de corrigir rapidamente o que está com problema, e os testes atômicos tornam a vida dos desenvolvedores mais fácil.

Como os testes atômicos são inerentemente curtos e, portanto, executam mais rapidamente que os testes mais longos (veja o cenário anterior), os desenvolvedores geralmente recebem o feedback do novo código assim que terminam de codar. A correção do código que foi escrito a alguns minutos atrás é consideravelmente mais fácil do que a correção do código que foi escrito a algumas horas ou dias. Além disso, como os testes atômicos se concentram em apenas uma parte da funcionalidade da aplicação, quando um falha, geralmente não há confusão sobre o que deu errado. Os desenvolvedores, portanto, não precisam gastar tempo e energia preciosos tentando diagnosticar a causa do problema, podendo corrigir o bug imediatamente e voltar rapidamente ao desenvolvimento de sistemas.

#3: Testes em múltiplas plataformas

Então, estamos executando scripts de testes atômicos curtos, alcançando uma alta taxa de aprovação e corrigindo rapidamente erros assim que são identificados. Estamos tranquilo e sossegados, certo?

Nem tanto.

Os clientes do mundo digital contemporâneo consomem informações e serviços em uma variedade cada vez maior, em navegadores, sistemas operacionais e dispositivos diferentes. Para realmente cumprir a promessa do desenvolvimento Agile, as organizações devem entregar rapidamente aplicações de alta qualidade que funcionem conforme o planejado quando, onde e como os clientes quiserem acessá-los.

Se um cliente deseja acessar o site a partir de um PC usando uma versão um pouco mais antiga do Firefox, esse site precisa ter uma ótima aparência e funcionar perfeitamente. Se um cliente diferente quiser acessá-lo a partir de um iPad usando a versão mais recente do Chrome, o site precisará ter uma ótima aparência e funcionar perfeitamente. E se um terceiro cliente quiser acessar usando o aplicativo nativo do celular que usa o Android como sistema operacional? Isso mesmo, o aplicativo precisa ter uma ótima aparência e funcionar perfeitamente.

A capacidade de determinar rapidamente se uma aplicação funciona corretamente em uma variedade cada vez maior de combinações de dispositivos, sistemas operacionais e navegadores é um componente crítico de testes contínuos eficazes. Isso inclui navegadores de celulares e web e sistemas operacionais, além de dispositivos físicos. Mais uma vez, com base na minha experiência de trabalho com centenas de clientes corporativos para ajudá-los a executar milhões de testes, recomendo que se esforce para testar em pelo menos 5 plataformas (definidas como qualquer combinação de um sistema operacional ou navegador de desktop ou móvel) com cada teste de implementação. Isso geralmente oferece a cobertura necessária para o lançamento confiável da aplicação nas plataformas que os clientes provavelmente estão usando.

Também deve se esforçar para incorporar os testes de dispositivo físico na estratégia geral de testes contínuos. Para fazer isso, geralmente é necessária uma mudança em toda a empresa para uma mentalidade de "mobile-first" (primeiro dispositivos móveis, ou pelo menos "mobile-equal" que nada mais é que semelhante no dispositivo móvel), na qual uma quantidade proporcional de tempo e recursos são dedicados para garantir que as atualizações nas aplicações mobile web e mobile nativo acompanhem as atualizações das aplicações web.

#4: Utilize o paralelismo

Mesmo se estiver executando de maneira brilhante cada uma das práticas anteriores, simplesmente não poderá escalar para atender às necessidades de empresa digital em ascensão sem a execução de testes paralelos. Sem a paralelização, os conjuntos de testes demorarão muito para serem executados, e as iniciativas de testes automatizadas falharão com toda a certeza.

Para entender o motivo da paralelização ser tão importante, considere o exemplo hipotético de um conjunto com 200 testes atômicos, assim espero. Cada um levando 2 minutos para ser concluído. Se pudermos executá-los em paralelo, poderemos executar todo o conjunto em apenas dois minutos, fornecendo aos desenvolvedores acesso imediato a informações sobre a validade de pelo menos 200 funções da aplicação. Se tiver que executar os mesmos 200 testes sequencialmente, levaria quase 7 horas para se obter a mesma quantidade de feedback. É muito tempo para os desenvolvedores esperarem. E quando os desenvolvedores precisam esperar, os clientes também terão de esperar.

A capacidade de executar testes em paralelo é, portanto, uma excelente aposta para a eficácia dos testes contínuos. As boas notícias? Se seguir as práticas recomendadas escritas neste artigo, está no caminho certo. A execução de testes atômicos e autônomos, ou seja, que podem ser executados de maneira independente, é a etapa mais importante que pode executar para se posicionar para alavancar efetivamente a paralelização. Além disso, é importante prestar atenção ao projetar o ambiente de testes de maneira que tenha capacidade disponível suficiente, geralmente na forma de VMs, para executar testes simultaneamente. Tão importante quanto isso, aproveite essa capacidade o máximo possível ao executar os conjuntos de testes.

Sucesso ou desilusão?

Theodore Roosevelt frequentemente recebe o crédito pelo seguinte ditado: "Nada que vale a pena ter, vem fácil". Mais de 100 anos depois, essas palavras ainda são válidas para os testes contínuos, pois não são nada fáceis. Mas existe um roteiro para o sucesso, que gira em torno dos principais pilares descritos neste artigo. Para recapitular:

• Reduza o tempo de execução de testes executando conjuntos com vários testes pequenos, em vez de poucos testes longos;
• Garanta a qualidade dos testes sempre executando testes atômicos;
• Garanta uma cobertura de testes adequada, expandindo o número de plataformas que testamos;
• Execute testes em paralelo para garantir que a escalabilidade nunca se torne um obstáculo.

Gostaria de encerrar revisitando o ponto de inflexão no qual as equipes de desenvolvimento Agile agora se encontram. Existem dois caminhos possíveis para o futuro. Um é marcado pelo sucesso, outro pela desilusão, com pouca margem entre os extremos. Se ainda não o fez, chegou a hora de se comprometer com a excelência contínua dos testes e, finalmente, transformar a promessa de desenvolvimento Agile em uma realidade duradoura.

Sobre o Autor

Lubos Parobek lidera o gerenciamento de produtos e a interação do usuário na Sauce Labs, fornecedora de nuvem de testes contínuos mais abrangente e confiável do mundo para aplicações web e mobile. Sua experiência anterior inclui posições de liderança de produtos em organizações como KACE, Sybase iAnywhere, AvantGo e 3Com. Parobek é mestre em Administração de Empresas pela Universidade da Califórnia, Berkeley.