Um dos termos mais comuns quando se fala em maturidade e qualidade de sistemas e aplicações é o shift left. No jargão do setor, significa levar essa qualidade para mais perto do time de desenvolvimento e testar continuamente; e não apenas após o release do produto. A terminologia vem do modelo linear ou cascata de desenvolver softwares. Logo, quanto mais à esquerda, mais cedo o teste é implementado no processo.
O ideal é testar em cada um dos steps possíveis do ciclo de vida da aplicação. Por exemplo, fazendo análise do código – avaliando boas práticas, padrões de qualidade, questões de segurança etc.-, testes funcionais unitários, de integração, de API, de interface do usuário (UI) e testes de carga/performance. Todos eles, de preferência, automatizados, mesmo que muitas vezes o código do teste automatizado seja maior que o próprio código a ser testado.
A vantagem de se automatizar os testes é tornar mais evidente a qualidade da aplicação e conseguir desenvolver dentro do time to market necessário com o menor risco de problemas que impactem a experiência do usuário final.
No momento atual, com a falta de profissionais e a necessidade de entregas cada vez mais velozes, é importante apoiar o shift left com ferramentas que possibilitem estes testes contínuos, tais como scan de código, gestão de defeitos, gestão de vulnerabilidades, gestão de patches, gestão e planejamento de capacidade. Ao tornar-se maduro no shift left, precisamos continuar a testar o que está rodando em produção, ou shift right.
Quando falamos de testar em produção, muitos podem ter associado às simulações de estresse, carga, estabilidade etc. O conceito de shift right deve, no entanto, ir além. Para que gere valor real para o negócio, o shift left e a cultura DevOps (pessoas, processos e ferramentas) devem estar muito maduros dentro da empresa. Caso contrário, vão surgir problemas que poderiam ter sido identificados na fase anterior. E aí é tarde. O custo de correção de um bug encontrado em produção pode ser até 100 vezes superior, além de pôr em risco a experiência do cliente, bem como a imagem e o faturamento da empresa.
Quais tipos de teste podem ser feitos no shift right? Vale citar teste A/B (duas versões de uma mesma página para ver qual converte mais), Teste Canário (quando você direciona uma parte dos usuários para uma nova funcionalidade, por exemplo), Teste de UX, de latência e o Chaos Engineering, este último um conceito criado pela Netflix, que consiste em inserir perturbações em um ambiente sistêmico e avaliar seu comportamento em busca de aberrações, fraquezas e resultados imprevisíveis.
Estes testes podem ser realizados já com a aplicação rodando e disponível para o cliente final. Executados de forma contínua, fornecem feedback constante para a melhoria dos sistemas e, consequentemente, da experiência do usuário, na busca pela resiliência (capacidade de cumprir as tarefas mesmo diante de uma adversidade), pela disponibilidade e confiabilidade.
Com isso, a aplicação, ou o sistema, vão se moldando para que o usuário final tenha o menor impacto possível na sua experiência.
Testes como o de Chaos Engineering, por exemplo, permitem detectar problemas totalmente fora do radar. Vale lembrar que os bugs e gargalos sempre estiveram lá, mas faltava alguém focado em encontrá-los.
Outra vantagem desse modelo é ajudar na adequação da aplicação, por exemplo, quebrando em serviços ou microsserviços que evitem uma indisponibilidade geral da aplicação. Digamos que o banco de dados que gera as recomendações da Netflix sofra uma queda. Por ele ser um pedaço do sistema, não vai impedir que o usuário tenha acesso a seu histórico de programas assistidos.
Outro conceito muito importante é a observabilidade (observability), que vai além do monitoramento tradicional e suas ferramentas de APM, de monitoramento de infraestrutura, etc. Ele engloba todas as técnicas possíveis que permitam "entender" o que está acontecendo no ambiente enquanto o teste está em curso.
A grosso modo, a observabilidade é a disponibilidade de informações (logs, métricas etc.) que permitam aos desenvolvedores e analistas identificar os problemas e suas causas o mais rápido possível. E aqui pensamos em problemas de todos os tipos: requisições se acumulando, receita caindo, tempo de resposta aumentando; sem nos restringirmos apenas a recursos de processamento perto do limite.
E na observabilidade pode-se já pensar em tratamento de logs que estejam espalhados em diversos lugares, já tabulando os dados de forma a facilitar a interpretação, buscar por uma padronização do tipo de erro e mensagem gerada.
No Brasil, o shift right ainda está na sua primeira infância. A maioria dos clientes costuma procurar ajuda quando já está num momento de "dor", de crise, em que o trabalho e os riscos para o negócio são mais altos.
Se você já está cuidando da sua qualidade shift left comece a estruturar sua qualidade shift right. Mesmo se a aplicação não atingiu ainda maturidade suficiente, já é possível começar a tomar algumas iniciativas de shift right para ajudar a melhorar sua qualidade shift left.
Ao final das contas, o que interessa é você ter um produto de alta qualidade para o usuário final, não é mesmo.
Ronaldo Sales, diretor de SRE Services and Application Security na Yaman.
