Os testes de qualidade e performance representam uma etapa crucial entre o desenvolvimento e a produção de sistemas em empresas altamente dependentes da área de TI e para as quais os serviços prestados ao usuário final são o ponto-central de seus negócios. Enquadram-se nessa categoria principalmente setores como o financeiro e o de telecomunicações, mas também companhias aéreas, de e-commerce, farmacêuticas, de educação, etc. Para empresas com esse perfil, a redução da possibilidade de riscos e o ganho de produtividade são pontos fundamentais para evitar re-trabalho, perda de tempo e de dinheiro mais adiante.
Apesar disso, os testes ainda hoje são encarados como forma de se ter uma proteção rudimentar do ambiente produtivo, mesmo em grandes empresas que utilizam a plataforma mainframe. O mais comum é que, após a finalização do desenvolvimento do sistema, o projeto passe quase que diretamente para a fase de produção, sem que se valorize devidamente a etapa de testes. Anteriormente, como pouco era feito de maneira formal pelas áreas de desenvolvimento para reduzir problemas causados por falhas de sistemas, as áreas produtivas precisavam se antecipar e bloquear a entrada de programas não autorizados, através de processos normalmente caseiros de controle de versão de sistemas - ou, como era dito, de controle de programas. Isso garantia que os programas não poderiam ser colocados em produção sem autorização. No entanto, sempre algo era esquecido, o que continuava causando problemas na produção.
Posteriormente, as mesmas áreas de produção começaram a criar ambientes pré-produtivos à sua imagem e semelhança, passando assim a controlar problemas grosseiros com os sistemas. Isso funcionava da seguinte maneira: duplicavam-se os ambientes partindo-se da própria produção, reduzindo-se normalmente o volume de dados. Implantava-se então a nova versão do sistema antes de implantá-lo em produção. Já foi um avanço, porém só se conseguia filtrar os erros grotescos. Havia também outros entraves. Por exemplo, se a implantação fosse para um tipo de produto novo, então ele não existia ainda na produção. Como trazer dados dessa mesma produção se eles não existem ainda? Os problemas continuavam e com o agravante de que os erros tornavam-se mais finos e de difícil solução rápida.
Colocado esse cenário, vejamos onde há hiatos e onde a tecnologia de testes pode ajudar. Em primeiro lugar, o processo atual praticado nas empresas não possui previsibilidade de resultados. Não se sabe, de antemão, que casos de testes os sistemas encontrarão pela frente quando forem ser testados. Se não se sabe o que há pela frente, como saber o que esperar do teste?
Isso leva a dois problemas sérios. O primeiro é o excesso de trabalho reativo. Busca-se, após os testes, quais eram as condições que causaram aqueles resultados, algo totalmente improdutivo. O segundo é que, como dito anteriormente, como saber se os dados são os suficientes, se cobrem todas as condições normais de testes, positivas e negativas. Se não há previsibilidade, como saber se é suficiente? Outro ponto, testam-se os sistemas como uma caixa preta. Não se atenta para como ele foi construído. Fraudes estão, normalmente, disfarçadas dentro do código. Tolerância a falhas do ambiente, dados falhos recebidos, problemas de reinicio após uma interrupção não prevista e ausência de dados são alguns dos casos de testes genéricos que não são considerados.
Existe ainda a complexidade dos ambientes atuais. Alega-se que os testes são muito difíceis de serem realizados, pois os ambientes são complexos, com tecnologias diferentes, dificuldades de comunicação de dados, etc. Essa é a visão do todo, porém sempre é possível dividir em pedaços menores e assim testar. Mas isso requer controle e planejamento minuciosos. Requer processos automáticos de simulação de comunicação, outras plataformas, etc. Finalmente, chegamos ao ponto do esforço para a construção dos testes. Invariavelmente, o desenho e a construção dos testes são muito mais complexos que o próprio desenho e construção dos sistemas. Logo, consomem mais raciocínio, esforço mental. Tornam-se então um capital intelectual, um ativo das empresas, assim como o são os sistemas. Por que então não reter esse ativo? Por que desperdiçá-lo e gastar novamente sempre que uma nova versão de um sistema é construída? As empresas precisam se preocupar em reter esse ativo.
Com tecnologias especialmente desenhadas para realizar esses testes de qualidade e performance, a companhia consegue obter previsibilidade e retenção dos ativos de testes. Consegue planejar e construir testes complexos com casos positivos e negativos, simulação de ambientes, isolamento de dados e particularização de testes. Pode re-executar os testes a qualquer momento, automatizá-los e guardá-los como ativo intelectual. Frequentemente, nós nos deparamos com clientes ainda focados na criação de ambientes pré-produtivos e que, ao conhecerem o espectro de atuação das tecnologias de testes, finalmente enxergam o benefício que elas trazem aos negócios. Investir em testes é uma questão de resultados e sobrevivência.
Fonte: Por José Luiz Rivera, in www.adnews.com.br
Apesar disso, os testes ainda hoje são encarados como forma de se ter uma proteção rudimentar do ambiente produtivo, mesmo em grandes empresas que utilizam a plataforma mainframe. O mais comum é que, após a finalização do desenvolvimento do sistema, o projeto passe quase que diretamente para a fase de produção, sem que se valorize devidamente a etapa de testes. Anteriormente, como pouco era feito de maneira formal pelas áreas de desenvolvimento para reduzir problemas causados por falhas de sistemas, as áreas produtivas precisavam se antecipar e bloquear a entrada de programas não autorizados, através de processos normalmente caseiros de controle de versão de sistemas - ou, como era dito, de controle de programas. Isso garantia que os programas não poderiam ser colocados em produção sem autorização. No entanto, sempre algo era esquecido, o que continuava causando problemas na produção.
Posteriormente, as mesmas áreas de produção começaram a criar ambientes pré-produtivos à sua imagem e semelhança, passando assim a controlar problemas grosseiros com os sistemas. Isso funcionava da seguinte maneira: duplicavam-se os ambientes partindo-se da própria produção, reduzindo-se normalmente o volume de dados. Implantava-se então a nova versão do sistema antes de implantá-lo em produção. Já foi um avanço, porém só se conseguia filtrar os erros grotescos. Havia também outros entraves. Por exemplo, se a implantação fosse para um tipo de produto novo, então ele não existia ainda na produção. Como trazer dados dessa mesma produção se eles não existem ainda? Os problemas continuavam e com o agravante de que os erros tornavam-se mais finos e de difícil solução rápida.
Colocado esse cenário, vejamos onde há hiatos e onde a tecnologia de testes pode ajudar. Em primeiro lugar, o processo atual praticado nas empresas não possui previsibilidade de resultados. Não se sabe, de antemão, que casos de testes os sistemas encontrarão pela frente quando forem ser testados. Se não se sabe o que há pela frente, como saber o que esperar do teste?
Isso leva a dois problemas sérios. O primeiro é o excesso de trabalho reativo. Busca-se, após os testes, quais eram as condições que causaram aqueles resultados, algo totalmente improdutivo. O segundo é que, como dito anteriormente, como saber se os dados são os suficientes, se cobrem todas as condições normais de testes, positivas e negativas. Se não há previsibilidade, como saber se é suficiente? Outro ponto, testam-se os sistemas como uma caixa preta. Não se atenta para como ele foi construído. Fraudes estão, normalmente, disfarçadas dentro do código. Tolerância a falhas do ambiente, dados falhos recebidos, problemas de reinicio após uma interrupção não prevista e ausência de dados são alguns dos casos de testes genéricos que não são considerados.
Existe ainda a complexidade dos ambientes atuais. Alega-se que os testes são muito difíceis de serem realizados, pois os ambientes são complexos, com tecnologias diferentes, dificuldades de comunicação de dados, etc. Essa é a visão do todo, porém sempre é possível dividir em pedaços menores e assim testar. Mas isso requer controle e planejamento minuciosos. Requer processos automáticos de simulação de comunicação, outras plataformas, etc. Finalmente, chegamos ao ponto do esforço para a construção dos testes. Invariavelmente, o desenho e a construção dos testes são muito mais complexos que o próprio desenho e construção dos sistemas. Logo, consomem mais raciocínio, esforço mental. Tornam-se então um capital intelectual, um ativo das empresas, assim como o são os sistemas. Por que então não reter esse ativo? Por que desperdiçá-lo e gastar novamente sempre que uma nova versão de um sistema é construída? As empresas precisam se preocupar em reter esse ativo.
Com tecnologias especialmente desenhadas para realizar esses testes de qualidade e performance, a companhia consegue obter previsibilidade e retenção dos ativos de testes. Consegue planejar e construir testes complexos com casos positivos e negativos, simulação de ambientes, isolamento de dados e particularização de testes. Pode re-executar os testes a qualquer momento, automatizá-los e guardá-los como ativo intelectual. Frequentemente, nós nos deparamos com clientes ainda focados na criação de ambientes pré-produtivos e que, ao conhecerem o espectro de atuação das tecnologias de testes, finalmente enxergam o benefício que elas trazem aos negócios. Investir em testes é uma questão de resultados e sobrevivência.
Fonte: Por José Luiz Rivera, in www.adnews.com.br
Comentários