Boas práticas para mapeamento de critérios de aceite em um Teste de Performance 

Dentro do processo de ciclo de vida de desenvolvimento de software, um item de extrema importância, é claro, são os testes, bem como o seu próprio ciclo de vida, onde se encaixam os passos específicos desde a ideação até a análise dos resultados obtidos. Contudo, um desses passos é um tanto quanto importante em relação aos demais pois é o responsável justamente por moldar como o teste será feito e o que efetivamente será testado e isso vale para os mais diferentes tipos de testes, mas iremos aqui abordar mais o caso dos testes de performance: Estou falando da identificação dos critérios de aceite. 
 
Por critérios de aceite devemos entender que são as condições mínimas exigidas para que o que fora desenvolvido seja relevante ao negócio, quer seja por intermédio de uma solicitação de usuário ou um complemento sistêmico. Em tese, esses critérios já são estabelecidos entre a área de negócios e o Product Owner quando do levantamento inicial de necessidades a serem cumpridas para a solução de um problema de negócios que se tornará uma solução sistêmica de alguma forma. Esses critérios com certeza se refletem no processo de testes como um todo pois será acima deles que a equipe de qualidade se baseará para gerar todo um plano de testes e submetendo também os mesmos e os entendendo para cada um dos tipos de testes e suas fases a serem desenvolvidos. 

Entendendo o ciclo de vida de um teste de Performance 

O ciclo de vida de um teste de performance possui seu próprio ecossistema de fases a serem atendidas para que um correto teste seja feito e resultados sejam colhidos de forma correta. 

Este ciclo consiste nas seguintes etapas: 

  • Identificação dos ambientes de teste; 
  • Identificação dos critérios de aceite de performance; 
  • Design do Teste; 
  • Configuração dos ambientes de teste; 
  • Implementação do teste; 
  • Execução dos testes; 
  • Geração e análise dos resultados e Reteste, caso necessário; 

Dentro dessa relação, em termos processuais definição dos critérios de aceite para o teste de performance seja lá qual for ele (Carga, stress, pico, etc…) já se inicia nos primeiros estágios e tem como base inclusive as histórias criadas pelo P.O junto a área usuária pois nelas já se tem a noção, mesmo que macro, de como o sistema deverá performar. Pesando mais especificamente agora nessa etapa da performance deve-se, em cima do que já se sabe, decantar esses processos e definir algumas características que deverão ser observadas quando a questão é a performance e aqui separo três delas, que podem muito bem ser o todo de um teste de performance já que praticamente fornecem todas as informações necessárias para que o sistema e sua infraestrutura possam ser avaliados para possíveis execuções, são elas: 

Tempo de Resposta – Onde o sistema é medido em seu tempo de resposta a um acionamento de uma determinada tarefa e deve responder em um determinado período de tempo por um número mínimo de vezes. Como exemplo pode-se dar o acionamento de uma página de um e-commerce que, ao ser clicado o seu atalho, a mesma deverá responder em cerca de 0.3 segundos durante ao menos 95% das vezes em que é acionada com uma carga pré estimada de cerca de 1000 usuários consecutivos. Ou seja, se durante o teste de performance, como um teste de carga por exemplo, se esta página não responder nestes tempos em segundos ou responder em menos de 95% das vezes, ou ainda não ter a performance estipulada com a quantidade de usuários pré determinada, o teste encontrou um problema a ser verificado. Agora já para um teste de stress, podemos usar esse mesmo critério de aceite pré estipulado e aumentar, por exemplo, para 3000 usuários e ver como o sistema se comporta, podemos ter um indício de até quando o mesmo aguenta, por intermédio da deterioração de seus próprios critérios preestabelecidos. 

Throughput – Ou taxa da transferência que determina a quantidade de dados transferido de um lugar para o outro e processados por uma determinada quantidade de tempo dentro de uma rede de comunicação. Sua medida é feita em bps ou bits por segundo. Ele também pode ser um indicativo de que algo não vai bem quando o tráfego em bps se mostra um tanto irregular em relação a velocidade da rede em que o sistema está implementado ou mesmo a quantidade de bps se mostra muito diferente em relação a outras medições que estabeleceram um determinado padrão dentro desta rede. Pode identificar problemas na rede em si, em algum hardware ou mesmo no processo de comunicação de dados, banco, ou uma API por exemplo. 
 
Utilização de Recursos – Esta característica pode até ser um tanto redundante com as demais apresentadas, mas na verdade ela resume e engloba tanto o que já fora citado quanto recursos mais que fazem parte do entorno deste sistema que está sendo testado. Pode-se inclusive extrapolar esse processo pois dentro deste teste pode ser, por exemplo identificada uma determinada tabela de um determinado banco que é estanciada por diversos processos ao mesmo tempo por processos online ou em determinado dia e/ ou horários por um processo batch que, neste interim, travar um importante processo de negócio, fazendo serviços apresentarem extrema lentidão ou até travarem seu funcionamento. Estamos aqui falando na verdade que inclusive isso pode ser relacionado com o processo de CMDB da empresa, identificando inclusive possíveis itens de configuração mais ou menos críticos na hora da execução de uma mudança, por exemplo, ou até sendo relevante na hora de processos de hotfix em produção. 

Conclusão 

Em resumo, se nos critérios de aceite específicos para a performance essas características acima forem contempladas, já consegue-se cercar o objetivo principal que é identificar algum problema derivativo dessas verificações especificas. Obviamente que vão existir outros fatores que podem, ou não, pesar dentro do processo, tais como os próprios requisitos do negócio, expectativas em geral por parte de usuários (a considerar MVP Versus desejos), processos governamentais ou de contrato que são obrigatórios, metas e restrições para utilização de determinados recursos, cronogramas “top Down”, e por aí vai. De qualquer forma, esse caminho com as características e critérios bem estabelecidos tende ao menos a mitigar todo e qualquer risco dentro do ciclo de vida do teste de performance, mesmo que eles não sejam claramente enunciados. 

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *