Pesadelo antes do Natal

Não te preocupes, esta não é mais uma publicação sobre o Black Friday. Também estou saturado de tanto ouvir falar sobre o Black Friday, o Cyber Monday e não sei mais o quê. O pior é que esta é uma moda que já se está a tornar uma tradição, e pelo menos em Espanha não faz muito sentido. Mas tu não lês este blogue para ouvir as minhas queixas sobre estes estrangeirismos e a adoção de tradições que pouco nos dizem, tu estás aqui porque trago a visão tecnológica e de negócio relacionada com o mundo do testing. E quer eu goste ou não, Black Friday é uma data chave no calendário.

Será que estas empresas vão esperar pelo “nightmare before christmas” das compras para falhar novamente junto dos seus clientes?

Uma grande proporção do comércio online concentra 50% das suas vendas anuais durante a semana da Black Friday, razão pela qual os responsáveis de negócios, marketing e TI têm esta data bem marcada nos seus calendários. Mas, e os responsáveis de quality assurance? Uma data tão significativa no calendário é tão importante para eles como para os outros?

O desempenho dos sistemas que era considerado como garantido, há anos já não existe, especialmente porque a arquitetura tecnológica é radicalmente diferente

Já sabemos que, graças a testes de software, podemos proteger o negócio assegurando o correto funcionamento dos websites onde é gerada a venda. Desta forma, em cada Black Friday, as empresas que têm processos de QA estabelecidos não têm de sofrer perdas tremendas e dores de cabeça quando os seus websites deixam de funcionar durante horas, com tudo o que isso implica para conversões e vendas de produtos, para além de prejudicar o prestígio de uma marca com algo tão básico como o correto funcionamento de um website. Mais um ano passou e pergunto-vos... será que as nossas recomendações vão passar mais uma vez despercebidas? Será que estas empresas vão esperar pelo “nightmare before christmas” das compras para falhar novamente junto dos seus clientes?

De uma forma ou de outra, mais cedo ou mais tarde, o desempenho dos sistemas afeta todas as organizações

Podes pensar que este artigo não é para ti porque o teu negócio não tem nada a ver com as vendas pela Internet, mas não pares de ler ainda! Porque, mais cedo ou mais tarde, o desempenho dos sistemas irá afetar todas as organizações, incluindo a tua. Obviamente, a causalidade no exemplo das vendas online é bastante clara; se o meu site estiver em baixo ou lento, os meus clientes não podem comprar, ou a experiência do utilizador é tão má que vão para a concorrência. Em suma, eu perco dinheiro. Noutras indústrias, a ligação entre o desempenho deficiente do sistema e o impacto nos resultados da empresa pode não ser tão claro.

O que estou a tentar transmitir-vos é que o desempenho dos sistemas que era considerado como garantido, há anos já não existe, especialmente porque a arquitetura tecnológica é radicalmente diferente.

Vamos supor que a tua empresa é um desses 240.000 clientes que tem SAP no mundo. Não tens nada a ver com compras online, mas à medida que a tua organização cresce, o teu sistema SAP fica cada vez mais lento; a produtividade dos teus colaboradores é afetada (perdas económicas), ou o processo de consolidação do SAP BPC é tão complexo que paralisa os teus sistemas durante horas (perdas económicas...).

Estes são apenas alguns exemplos; poderia dar-vos muitos mais em ambientes que são supostos serem "rápidos" simplesmente porque serem SaaS, tais como Salesforce, e onde cada vez mais clientes pedem a nossa ajuda para o otimizar.

A clássica solução de apostar mais no CPD (ou melhor, mais euros em AWS ou Azure), também não é a solução, devido aos custos e porque muitas vezes simplesmente não funciona. A complexidade do software e o aumento do volume de utilizadores que interagem através de diferentes dispositivos torna obrigatório os testes de desempenho e a monitorização de sistemas, e deve ser feito desde o início (shift-left, outra palavra sem tradução).

Cliente: “Acho que vamos bater na Black Friday, a minha cabeça está em perigo. Por onde começamos?"

Esta é uma frase que ouvimos todos os anos por esta altura, de uma empresa que, como muitas outras, só procura um orçamento quando vê as orelhas do lobo. Como disse antes, se quiseres que o “nightmare before Christmas” seja apenas um grande filme, e não o prenúncio da próxima queda do teu sistema, segue estas dicas:

1. Não o deixes para o fim -Shift Left não se trata apenas de começar a fazer os testes funcionais e a automatização antes no ciclo de vida, trata-se também de pensar no desempenho a partir do dia 0. Tradicionalmente, os testes de desempenho eram feitos perto do fim do desenvolvimento, uma vez que o seu foco eram os processos de negócio do início ao fim. No entanto, com a adoção de estratégias de Continuous Development (CD), Continuous Integration (CI) ou Continuous Deployment (CD), é possível integrar os testes de desempenho inclusive cada vez que fazemos um build. É claro que necessitarás de uma estratégia de testes de desempenho (e nós somos especialistas nesta área), caso contrário, não vale a pena simplesmente lançar testes constantemente. Pensa em avaliar as mudanças na tendência dos gráficos que obténs, em vez de olhar para o desempenho do sistema a nível geral. E não compliques com milhares de utilizadores, muitas vezes é suficiente gerar uma carga mínima e avaliar as mudanças entre releases / builds / commits...
2. Teste de componentes -Tradicionalmente, a indústria tem-se concentrado em ferramentas de posicionamento que "gravam" o que o utilizador real faz, para depois o reproduzirem simulando centenas ou milhares de ligações e criar a carga. Esse paradigma de trabalho já não é necessário. É agora possível trabalhar diretamente contra os componentes, quer a nível de webservices, quer a nível da base de dados (para dar dois exemplos). A minha recomendação é que testes a nível unitário, não procurando gerar carga, mas procurando gerar atividade suficiente para identificar tendências, especialmente ao comparar dados entre releases.
3. Simular cenários reais -Não te deves esquecer que o objetivo dos testes de desempenho é antecipar o que irá acontecer em produção, para detetar potenciais problemas antes que os utilizadores reais o façam. O teu plano de testes deve conter os detalhes do que esperas em produção. Antes do grande dia (seja a Black Friday, o fecho de contas mensal, ou o lançamento de uma campanha...), cria cenários de testes que simulem estas condições e não te esqueças que gerar carga para simplesmente "forçar" o sistema não traz mais valia, todos nós sabemos como fazê-lo, mas não é um teste de desempenho.
4. Pensa nas tuas dependências -Com ambientes heterogéneos, é cada vez mais comum confiar em terceiros (sejam eles outros departamentos ou outras empresas, tais como gateways de pagamento). Certifica-te de que conheces os seus planos de testes para verificar se cumprem com as tuas estimativas; e se não for possível ter esta informação, pensa na virtualização de serviços. Esta é uma excelente opção, não só quando não se pode testar o desempenho de uma plataforma externa, mas também quando o desenvolvimento de algumas das tuas dependências está a decorrer a um ritmo diferente (por exemplo, quando ainda não se terminou e já queres realizar testes).
5. Monitor em produção -Não te esqueças que o ciclo de vida de uma aplicação tem a palavra ciclo por uma razão - é iterativo. A informação que obténs em produção deve ser utilizada para planear testes de desempenho melhores. É comum que muitas das ferramentas utilizadas na monitorização em produção de forma sintética também suportem os scripts que utilizaste durante os testes de desempenho.

Se seguires estas 5 dicas, já tens grande parte do caminho feito para assegurar que a tua plataforma tem o desempenho que os teus utilizadores esperam. Como dizia no início deste post no blog, se os teus sistemas sofreram durante a Black Friday, não esperes até teres um “nightmare before christmas”, e chama os especialistas.