software

Contribuir para o aumento do nível de confiança, prevenir e encontrar defeitos estão entre os principais objetivos que queremos alcançar quando testamos um software. Porém, para atingirmos essas metas não existe uma simples receita de bolo e precisamos estar sempre atentos para maximizar as nossas chances de entregarmos constantemente software de qualidade e que atenda às necessidades dos clientes.

Apesar de nossos esforços, invariavelmente temos que lidar com os defeitos escapados, que normalmente implicam em stress, re-trabalho e desgaste na relação com o cliente. Em meio ao problema, uma das primeiras ações que temos é a análise da causa raiz, ou seja, identificar o porquê do defeito ter ocorrido e consequentemente do mesmo não ter sido identificado nas etapas anteriores de validação.

Diversos podem ser os motivos para a falha na detecção do defeito, por exemplo:

– Cenário de teste não estava coberto.

– Teste existia, mas não foi priorizado para o ciclo de execução.

– Teste existia, foi priorizado, porém não foi executado corretamente.

– Teste existia, foi priorizado, executado corretamente, porém diferenças de ambiente não permitiram a detecção da falha.

– Etc.

You are doing it wrong

Porém, ainda há um outro motivo, que talvez seja um dos mais frustrantes – O teste existe, mas está errado.

Quando isso acontece, independente de planejarmos corretamente, o teste, seja ele manual ou automático, nunca nos trará o resultado correto e a falha inevitavelmente aparecerá em produção. Nesses casos, ainda temos como dificuldade adicional o fato de que a re-execução do nosso teste não ajudará na reprodução do erro, podendo inclusive gerar ruído na comunicação e dificuldades na identificação da causa do problema e consequentemente em sua correção.

Identificar testes com defeito não é algo simples e corremos o risco de executá-lo diversas vezes e confiarmos em resultados enganosos. Para tentar minimizar esse tipo de situação, podemos realizar algumas ações:
– Revisar os testes existentes

– Se forem testes manuais, mudar o responsável pela execução

– Aprofundar-se no funcionamento de mocks e stubs utilizados para teste

– Conhecer as limitações das ferramentas utilizadas

– Revisar as pré-condições e o ambiente de validação

E você já enfrentou o problema de ter falhas escapadas devido a testes defeituosos? Que ações tomou para tentar evitar que o problema se repetisse?

Todos já enfrentamos diferentes problemas de performance ao acessar nossos serviços favoritos na web. Lentidão e até mesmo indisponibilidade por longos períodos são problemas que ainda afetam a maioria das aplicações web.

Desse modo, podemos apontar que a Performance é um requisito não-funcional CHAVE para as aplicações web. E menosprezá-la pode causar grandes consequências.

Podemos definir os testes de performance, como:

Através dos testes de performance podemos simular o ambiente de produção, que a aplicação será submetida e avaliar como a mesma irá se comportar.

Lembrando que….

…de forma, que através da correta execução dos testes de performance, em conjunto com um monitoramento eficiente, podemos submeter diversos pontos da aplicação aos níveis de carga esperados e avaliar o seu comportamento.

No contexto das aplicações web: “Se um usuário tem de esperar muito (para acesso, processamento do lado do servidor, para formatação ou exibição do lado do cliente), ele ou ela pode decidir ir para outro lugar.” (Pressman, 2005)

Logo, desprezar esse requisito não-funcional pode gerar perdas irrecuperáveis para um negócio.

Do ponto de vista conceitual, fala-se sempre em três tipos de teste:

Performance: Avalia se a aplicação em teste atinge os requisitos em relação a questões como: tempo de resposta, throughput e utilização sob um nível de carga esperado.

Carga: Submete a aplicação a diferentes níveis de carga, com o objetivo de identificar a capacidade máxima de operação, além de gargalos, memory leaks, etc…

Stress: Avalia a robustez, disponibilidade e confiabilidade da aplicação em condições extremas (cargas muito elevadas, escassez de recursos)

Os três são comumente confundidos, porém como descrito cada um tem sem objetivo específico e a correta utilização dos mesmos durante o desenvolvimento poderá proporcionar um nível completo de informações sobre o comportamento da aplicação.

Por fim, é importante enfatizarmos que: “Caso não sejam executados da maneira correta, os resultados são, na melhor das hipóteses, inúteis e, na pior das hipóteses, enganosos, fazendo com que uma empresa menospreze ou superestime a capacidade de sua aplicação.” (Savoia, 2000)

Logo, é fundamental que, desde o início do ciclo de vida da aplicação, o RNF relacionado a performance seja priorizado, para que todo um ambiente de testes seja preparado de maneira adequada para simular o ambiente de produção e desse modo auxiliar o desenvolvimento a atingir o nível de qualidade desejado.

Gostou do assunto testes de performance? Participe, deixando seu comentário no post.

Em breve, voltaremos ao assunto falando do Apache JMeter.

E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!