Mudando o foco de testes: as vantagens da abordagem por transações

Por Mauricio Medina

Venho falando em todos os meus últimos artigos sobre transações, um conceito que para muitos ainda é meio complicado, e para os envolvidos em projetos e com aplicações com problemas sempre é um desafio.

Minha experiência vem da minha vida dentro de vários clientes, onde, independentemente do nível de maturidade, processos e etc, sempre sofrem uma pressão enorme para que os projetos entrem na data, as aplicações funcionem minimamente e vai por ai.

Como tenho clientes com um diversidade enorme de maturidade em relação à processos, métodos, automação e etc., sempre busco entender qual o nível mais adequado para cada um deles, e tentar traduzir isto em algo que realmente funcione dentro das limitações e capacidades de cada um.

Hoje

Na maior parte das grandes corporações, há uma terceirização forte quanto ao desenvolvimento de aplicações, tanto na contratação do desenvolvimento externo, quanto no uso de desenvolvedores externos dentro do seu ambiente, seguindo seus métodos e processos. E sempre vejo que de alguma forma, muitos testes são negligenciados por inúmeros problemas que tenho certeza que o leitor deve ter alguma experiência. Mas a pressão continua, e a responsabilidade por garantir que vai funcionar a contento também.

Tem muito do eu ganho, nós empatamos e vocês perdem nestes casos. A pressão para seguir cronogramas faz com que mesmo as empresas que investiram rios de dinheiro em processos, métodos de desenvolvimento, os ponham de lado em nome da velocidade (time to the market) na entrega das aplicações.

Nos pequenos, processos e métodos são abstrações boas para a hora do almoço ou do chopp de fim de tarde. A pressão que aceitam de seus clientes praticamente os empurra para um desenvolvimento sem um mínimo de testes que não os funcionais, mesmo assim no caminho feliz.

Obviamente há honrosas exceções, mas mesmo estas também costumam ser "flexíveis" quanto a pressão de cada projeto.

E só falei de projetos de desenvolvimento, não disse nada em relação às aplicações mancas, com problemas que devem vir das suas especificações, arquitetura, qualidade de código e vai por ai. E é muito mais fácil pedir mais hardware do que procurar as raízes dos problemas, até porque não se confia na documentação quando existe e código é terra onde ninguém pisa...sabe-se lá como foi feito...

Sempre é mais fácil pedir aumento de hardware, mesmo que ele mostre depois que teve um efeito placebo na performance da aplicação. Mas ai já passou um tempo e a pressão diminuiu um pouco.

Falei numa das minhas últimas matérias sobre a abordagem das transações, e tenho implementado esta abordagem em vários clientes com sucesso.

Mudando o foco

Não quero subverter a ordem dos processos de desenvolvimento e testes de software, mas tenho que admitir que hoje eles estão um pouco longe de estar de fato implementados. Mesmo empresas que receberam algumas certificações abrem mão disto quando se trata de atender às necessidades prementes dos clientes, fazendo a versão com ou sem processo, similar a com ou sem NF.

Minha intenção com esta nova abordagem é mostrar o quanto é mais rápido e barato focar onde realmente interessa para a aplicação e o negócio, em vez de testar toda a aplicação e não se testar nada direito. E tudo que está escrito aqui é totalmente "process agnostic" e pode ser aplicado juntamente com os processos que as empresas já usam.

O foco que proponho é que olhemos a aplicação e identifiquemos quais as transações que mais a influenciam em relação a quantidade de transações, prioridades, criticidade, número de usuários e outros fatores que vão ser revelados nesta análise.

A partir desta visão, e como estou escrevendo para a comunidade Microsoft, podemos rastrear e monitorar as transações COM, +COM e .NET com e sem carga, avaliando o comportamento de cada componente da transação. É muito mais simples e direto, focado somente onde o negócio pode ser sensível a problemas e que limita os esforços aonde interessa.

Nada de testar transações que serão usadas poucas vezes ou que não são críticas. Investimento focado, resultado alcançado.

É lógico que é necessário ter automação neste processo, e vocês podem baixar algumas ferramentas para fazer isto de www.xtremesoft.com para COM e +COM e www.avicode.com para as .NET. Vale a pena e vários usuários no Brasil estão usando com muito sucesso, incluindo a própria Microsoft.

Outro ponto interessante é juntar esta monitoração com testes de carga, onde podem ser usadas várias ferramentas para gerar os usuários virtuais e avaliar-se o impacto que eles trazem para a performance dos componentes da transação e para a aplicação em si. Tentem www.cloudtest.com e vejam como é simples.

Um benefício adicional é que se fizermos uma avaliação ou teste básico (baseline) no ambiente de homologação ou testes, vamos obter algumas métricas que podem ser usadas para pensar se aquela aplicação vai poder conviver em um servidor que já suporta outras aplicaçoes concorrendo pelos mesmos recursos ou se é melhor a instalarmos em outro.

Já testei e implementei esta abordagem em várias situações, sempre com vantagens. E mais, se adicionarmos estes testes com uma análise detalhada do código dos componentes, vamos conseguir melhorar a performance total da aplicação.

Espero que não pareça um chato falando o tempo todo de transações e etc., mas como minha experiência é ditada pelos problemas que encontro nos clientes, sempre busco o caminho mais rápido e barato para ajudá-los.

Espero ter contribuído mais uma vez & abraços

Mauricio Medina

Maurício Medina é diretor executivo da Consequor Tecnologia, empresa focada em qualidade e performance, além de ter sido o diretor de serviços da Compuware e o fundador da Rational Software no Brasil. Tem 23 anos de experiência na área de TI e esteve presente nas ondas de tecnologia que chegaram ao país através das empresas que as estavam implementando, como Amplus (início das redes), Relacional (distribuição de Oracle), Gupta (ferramentas de desenvolvimento). Foi escolhido como Most Valuable Professional (MVP) pela Microsoft e é colunista da coluna Arquitetura de Software no site www.msdn.com