Mauricio Medina

Uma nova percepção

Existe hoje uma clara visão de que é necessário testar, garantir qualidade, diminuir riscos e que a Microsoft tem uma clara direção em apoiar estas iniciativas ao criar produtos e integrar suítes para aumentar a facilidade no processo de testes.

Muitos clientes, independentemente de processos e produtos, buscam aumentar a confiabilidade das aplicações das quais dependem seus negócios. Mesmo aqueles que não têm ainda uma maturidade de TI maior, todos concordam que sem testes o risco é grande. Mas poucos de fato testam de fato suas aplicações.

As razões são muitas e não vou ficar de novo buscando as raízes destes problemas. Em contato com muitos clientes, de vários níveis de maturidade, cheguei à conclusão de que é preciso criar e suportar uma nova abordagem para diminuir os problemas das aplicações que vão entrar em produção e daquelas que já estão em produção.

Esta nova percepção surgiu da constatação de que sempre é difícil conciliar os prazos dados para desenvolvimento, testes e a efetiva entrada em produção da aplicação. Mesmo em grandes corporações, tenho visto que os cronogramas sempre falham em contemplar os prazos para os testes e os custos dos mesmos. Estou falando dos vários tipos de testes que precisam ser feitos nas várias fases em que o desenvolvimento ocorre, ou seja: testes unitários, funcionais, performance, só para citar os mais conhecidos.

A pressão para que a aplicação vá para produção é tão grande, que ela praticamente muda simplesmente de aplicação desenvolvida e entregue para aplicação em manutenção no dia em que é entregue. Vários problemas vão surgir após a entrega da mesma, sempre ou quase sempre nas mãos dos usuários, sempre, indiscutivelmente criando condições de risco ao negócio.

A nova abordagem

Eu pensei em dar um nome como Xtreme Testing ou coisa do tipo, mas lembrei que estas coisas xtreme sempre tendem a virar assuntos religiosos, e ai deixei como Transaction Testing.

Na realidade talvez o conceito nem seja novo, mas a implementação deve ser: Ao contrário de testar todas as transações a fundo, somente aquelas que fossem consideradas de missão crítica dentro da aplicação seriam submetidas a um teste mais abrangente, sempre tendo como ponto de partida duas coisas: a garantia da funcionalidade implementada e a garantia de um mínimo de performance para a dada aplicação.

Isto quando em fase ante-produção. Ou seja, antes que ela seja levada para produção. Vantagens? Várias:

1. Somente se investiria tempo e recursos (sempre escassos) nas transações e seus componentes que tivessem reais impactos no negócio.

2. Há o barateamento do processo de testes, uma vez que partindo-se das definições dos requisitos, fica muito mais fácil e rápido identificar as transações que merecerão atenção especial desde o início, perseguindo-se desta forma uma melhor qualidade em todo o processo de construção.

3. Utilizando-se uma transação que está funcionalmente ok, pode-se criar vários baselines de performance, usando-se vários números de usuários para a identificação dos pontos críticos dos componentes da transação. E ai estudá-los detalhadamente procurando resolver os problemas encontrados

4. Dependendo do tipo de automação utilizado para analisar as transações, o trabalho efetuado na fase de testes da transação pode servir para monitorar a transação em produção, facilitando muito o mapeamento real do comportamento das transações e seus componentes.

5. Obviamente existem outras vantagens, que são mais ou menos interessantes dependendo do ambiente de testes, dos processos e cultura de cada empresa

Para transações já em produção, obviamente os problemas são outros, e também as vantagens desta abordagem:

1. Permite que se monitore a analise a transação real que está em produção, com total independência de documentação ou informações que podem não estar atualizadas. Este é um fato que tenho encontrado muito em clientes e está documentado na minha última matéria nesta coluna.

2. Permite dar nomes às transações e criar um ranking de transações mais consumidoras, rápidas, lentas e outras métricas, que podem ser usadas para facilitar os isolamento e foco no que realmente interessa. Além disto, consegue-se fazer este mesmo tipo de ranking com os componentes da transação e com os métodos de um componente.

3. Permite que se monitore somente as transações que interessam, de forma controlada, sem instrumentação da mesma, de forma não intrusiva, ligando-se ou desligando-se o monitor quando se quer. Isto permite que somente se faça a monitoração quando necessário e não o tempo todo.

4. Permite que se faça um capacity plan baseado na realidade monitorada e analisar os impactos que as muitas variáveis ambientais e de uso têm na transação.

5. E vai por ai.

Como falei, acho que isto nem é novo, mas as vantagens são interessantes. Além disto, se fizermos algumas contas, sai bem em conta.

É lógico que isto não substitui um processo formal de testes, e nem este é o objetivo, uma vez que esta abordagem é absolutamente complementar a qualquer processo de desenvolvimento e testes do mercado. Eu costumo brincar e chamar de "process agnostic".

Para ilustrar, sugiro uma visita a Identificando Problemas nas Transações e Isolando Componentes, palestra que fiz no PDC 2004 e que mostra como isto funciona.

Espero que isto não seja o início de uma discussão religiosa, uma vez que o objetivo foi facilitar a vida das pessoas que são responsáveis por garantir que aplicações onde puseram muita grana funcionem, se possível com performance e sem problemas.

Mas se quiserem mais informações, estou a disposição.

Abraços