Qualidade e Velocidade: Nossa jornada de sete anos rumo a uma disponibilidade de 99,999%

Diante de um ecossistema de software altamente dinâmico, o mundo dos testes de software permaneceu estagnado. À medida que os produtos se tornam cada vez mais complexos, as equipes de desenvolvimento se veem diante de um dilema: a demanda por entregas rápidas entra em conflito com a necessidade de garantir a qualidade dos produtos.

Como suas equipes podem adotar uma abordagem mais rigorosa em relação aos testes de software sem comprometer a agilidade e o crescimento do produto?

A equipe de SDET (desenvolvedores de software para testes), em constante crescimento, dentro do departamento de P&D da Vonage definiu uma solução. Nós a chamamos de Qualocity: a abordagem de testes em camadas que atende tanto à qualidade quanto à velocidade.

Então, onde tudo começou?

A maioria das empresas concentra seus esforços de teste em duas áreas principais: testes funcionais, que simulam o uso básico de uma aplicação, e a carga não funcional do sistema. As equipes de teste costumam avaliar a qualidade do produto com base na cobertura dos requisitos e no número de bugs encontrados, que passaram despercebidos ou foram reabertos — essencialmente, dando destaque aos bugs em vez de evitá-los desde o início.

Mas o mundo mudou. Enfrentamos um aumento da fragmentação em aspectos como sistemas operacionais, dispositivos e latência de rede. Estamos bem avançados na era dos aplicativos, uma era dinâmica e altamente competitiva. Estamos vendo APIs e bibliotecas comuns que agora permitem um desenvolvimento mais rápido, bem como diversos serviços em nuvem que oferecem ao desenvolvedor um ambiente que não depende de sistemas operacionais, segurança, redundância ou mesmo escalabilidade. Tudo isso para dizer que empresas com ciclos de lançamento em cascata que levam meses não conseguem mais competir com a demanda por recursos e inovação.
As empresas que não conseguirem entregar rapidamente chegarão atrasadas ao mercado.

As Camadas

No entanto, apesar da necessidade de agilidade, há um risco em apressar a produção contando apenas com alguns métodos ultrapassados de testes de qualidade. Pois, se continuarmos fazendo as coisas da mesma forma que fazemos há anos, acabaremos entrando em um ciclo vicioso de problemas de qualidade e escaladas na produção, o que não é agradável para ninguém. Isso nos leva a dois fatores críticos: a qualidade precisa melhorar, mas precisamos ter a capacidade de implementar mudanças na produção de forma consistente e consciente.

Há sete anos, começamos a pesquisar métodos adicionais para complementar as duas camadas originais: os testes funcionais e os de carga. Durante esse período, desenvolvemos de forma constante a abordagem de qualidade e velocidade que nos levou a uma disponibilidade do sistema de 99,999%, conhecida coloquialmente como os “cinco noves”.

Por meio de pesquisas e experimentações, criamos o processo aqui apresentado, que é composto por três camadas multidimensionais:

Disciplina na programação

Pode parecer óbvio que a disciplina adequada na programação é o cerne da qualidade do software. Os testes começam aqui, no cumprimento consistente das normas e dos procedimentos.

• Revisões de código devem ser realizadas por colegas, sempre, e o código automatizado deve ser tratado da mesma forma.

• Testes unitários com ampla cobertura nos permitem testar com facilidade e confiança, sem correr o risco de danificar a base de código.

• Ferramentas de análise estática detectam erros estáticos e vulnerabilidades de segurança. Existem muitas dessas ferramentas no mercado, que oferecem diferentes especificações para atender a diferentes necessidades.

• Testes funcionais devem se concentrar no uso de simulações. Teste no nível da API e envolva sua automação com simulações que testem exatamente o que você solicitou. Evite testes automatizados de ponta a ponta, pois você está testando seu código e não o produto completo. Como resultado, a cobertura aumentará e os testes se tornarão mais estáveis.

Certifique-se de que os testes funcionais sejam executados em todos os lugares, não apenas nos ambientes de desenvolvimento e controle de qualidade, mas também em produção. Se criados corretamente, eles servirão como uma excelente ferramenta de monitoramento e não apresentarão falhas com frequência. Todos sabemos como é frustrante ser alertado às 2 da manhã por um alarme falso.

Testes não funcionais

Para isso, você precisará sair da sua zona de conforto e pensar em grande. Você precisará conhecer o uso médio do seu produto e levá-lo ao seu limite.

Considere uma API que, segundo você sabe, recebe, em média, 1.000 chamadas por segundo, com um pico de 1.200 às 10h e às 15h, e um mínimo de 800 às 22h.

• Para testes de carga , você vai querer fazer 1.000 chamadas por segundo durante algumas horas.

• Em Testes de estresse , você continuará adicionando chamadas até chegar a uma falha. Esse é o seu ponto de estresse. Decida o que fazer a respeito e tente novamente.

• Testes de estabilidade levam em conta o uso médio ao longo do tempo. Durante um período prolongado, faça 1.200 chamadas por segundo nos horários de pico, 800 nos horários de menor movimento e 1.000 no restante do tempo. Isso garantirá que você consiga manter a estabilidade sob sua carga média.

Se o seu software incluir recursos para escalonamento automático, certifique-se de realizar testes em instâncias adicionais assim que o limite for atingido. Teste a a redundância para regiões e zonas, pois lembre-se: seus serviços em nuvem vão apresentarão falhas de vez em quando. Segurança , neste contexto, refere-se a testes de penetração de aplicativos, testes de OSS (bibliotecas externas e APIs) e ferramentas de análise estática. As revisões de código são cruciais nesta etapa e devem fazer parte do ciclo de vida do desenvolvimento de software.

Disciplina de DevOps

Deixe assimilar. Não se iluda achando que você se protegeu contra todos os casos extremos só porque tudo o que foi mencionado acima está funcionando bem. Isso simplesmente não é possível. Você tem mais dispositivos, mais recursos de Account e mais configurações a considerar. Reserve um tempo para garantir que os testes sejam realmente precisos.

Lembre-se de proceder gradualmente com os lançamentos

• Incentivar a correção de bugs pela equipe de desenvolvimento antes de passar para o ambiente de teste

• Então experimente no usuários (interna) antes de compartilhar com os beta (externos). Esses grupos beta selecionados devem representar a maioria da sua base de produção, no que diz respeito a instâncias e dispositivos.

• Assim que a versão estiver amplamente disponível, ative um sistema de implantação , que alterna entre servidores de produção e de teste e permite que você retorne rapidamente a uma versão anterior, se necessário.

• Monitore minuciosamente; acompanhe o estado do seu sistema, configure alertas e analise os dados de teste

• Converse com suas equipes de sucesso do cliente e explore outras fontes de feedback, como lojas de aplicativos, redes sociais e plataformas comunitárias.

Se você seguiu todas essas etapas, podemos praticamente garantir que agora está pronto para o GA.

Conclusão

O que apresentamos acima é uma abordagem para uma estratégia de qualidade que consideramos quase perfeita, mas ainda assim viável. Embora ainda não tenhamos implementado essa abordagem integralmente em todos os nossos serviços — especialmente no código legado e no software herdado —, podemos afirmar com confiança que cada camada tem se mostrado capaz de fazer uma diferença significativa. A equipe de SDETs e engenheiros de DevOps da Vonage pode atestar isso. É um grande desafio, mas recomendamos que você adicione gradualmente uma camada de cada vez, até atingir a cobertura ideal para o seu caso.

Esperamos que isso tenha ajudado e que essa pesquisa o aproxime ainda mais da disponibilidade desejada.