Com as técnicas de implantação contínua de software, é comum entregar novos softwares em produção múltiplas vezes por dia. Uma suite de testes de regressão, independente que quão bem é projetada, leva ao menos uns 10 minutos para ser executada, o que pode levar a gargalos na entrega de mudanças em produção.
Então, você ainda precisa testar antes de “ir pro ar”? Porquê não testar as mudanças direto em produção?
Teste as mudanças em produção
O web site do The Guardian, terceiro maior jornal do Reino Unido, implanta software em produção uma média de 11 vezes por dia.
“Uma vez que o código está em produção, a garantia da qualidade pode realmente começar.”
“Algumas vezes as implantações dão errado. Nós esperamos por isso; e aceitamos isso, porque pessoas (e máquinas) erram. Mas a chave para lidar com este tipo de erro é não travar o processo ou ampliar os testes de regressão em qualquer nível. A solução é capacitar as pessoas a resolverem os erros rapidamente, aprenderem, e voltarem a entregar valor o quanto antes.”
~ Andy Hume, em Real Time QA, no blog The Guadian Developer
A chave de testar as mudanças assim que elas chegam a produção é ter o monitoramento contínuo da experiência do usuário em tempo real. Isso inclui métricas como page views e tempo de carregamento de páginas, que se correlacionam diretamente a receita de publicidade, a qual se incentiva manter saudável.
Testes automatizados de aceitação mais compreensíveis podem ser escritos de uma forma não destrutiva, o que significa que eles podem ser executados em produção. Isso significa que estes podem ser executados imediatamente em seguida de uma récem implantação em produção, e assim que o feedback dos testes é recebido, qualquer problema pode ser imediatamente remediado em produção e testado novamente.
Isso também significa que você não precisa ter e gerir ambientes de teste, que são caros e demorados, especialmente se você está constantemente tentando mantê-los parecidos com o ambiente de produção.
Teste as mudanças antes de elas chegarem em produção
Há um número limitado de negócios que são capazes de entregar software sem nenhum tipo de teste direto em produção: se há requisitos legais que exigem testes ou o risco de introdução de erros é muito alto para seu mercado-alvo, isso já não é possível.
Testes automatizados de regressão levam mais tempo para serem executados do que testes de unidade ou teste de integração. No entanto, há formas de gestão para garantir que o software vá rapidamente para produção. Estas estratégias incluem a execução de testes em paralelo, execução somente dos testes mais críticos para o negócio, teste rodando somente contra o navegador mais utilizado popularmente, ou somente rodando testes diretamente relacionados as mudanças.
Você pode configurar um pipeline de deployment que executa um subconjunto de testes antes da implantação em produção (em um ambiente de testes) e depois executa os testes restantes. Qualquer um dos problemas encontrados em testes subsequentes são julgados para ver se justifica-se outra entrega imediata ou se as correções podem ser incluídas no próximo conjunto de mudanças que estão sendo implantadas em produção.
Enquanto você definitivamente deveria rodar testes antes da implantação em produção, isso não significa que isso tem que dificultar drasticamente sua capacidade de implantação contínua.
TALKING ABOUT TESTING 