MouseOver Studio

Andrew Clifford, consultor de TI, escreveu aproximadamente faz um ano um artigo para ITtoolbox que recentemente começo a rodar novamente na Internet e chamou muito minha atenção. O artigo fala sobre desenvolvedores e testes, e pelo fato de estar em inglês, vou resumir o que diz nele. Assim as pessoas que não tem muita facilidade com o idioma podem adquirir o conhecimento que o autor quis transmitir.

Andrew começa mencionando que muitos dos melhores programadores parecem ser os que fazem menos testes e ao contrario de criticar, deveríamos aprender deles. Ele mesmo reconhece que nos tempos de programador, encaixava na classificação e que conversando com outros consultores descobriu que ele não era o único. Seguidamente lança a pergunta:

Aqueles programadores produzem constantemente um bom trabalho, como conseguem fazer isso sem uma boa bateria de testes?

O autor mesmo responde e comenta que aqueles desenvolvedores são especialistas no que fazem, pelo que podem manter sua atenção mais enfocada em cumprir as regras de negocio que no como se deve programar. Para cumprir as regras de negocio, aqueles desenvolvedores devem seguir uma especificação. Quando a especificação não esta muito bem detalhada ou completa, eles tem suficientemente capacidade para corrigir o problema e melhorar a especificação. Eles tem muito conhecimento sobre como o programa deve funcionar e funciona, pelo que e mais difícil deixa escapar algum buraco. Mas o principal motivo e outro. Andrew diz que os desenvolvedores testam conforme vão criando o programa. Eles programam, integram e testam o resultado. Eles não acham que programar e testar são tarefas diferentes.

Logo depois de responder a pergunta, Andrew menciona que é lógico que os programas desenvolvidos por esses bons desenvolvedores precisam de um teste de nível maior, mas não de testes unitários, porque o programa cumpre as especificações e se encontra bem integrado com outras funcionalidades.

Si algum de vocês for um gerente de projetos, pode desejar seguir algumas das recomendações dadas pelo autor.

A primeira e dar aos programadores aceso total as especificações. Eles devem validar as especificações e ter elas claras antes de começar a programar. A segunda recomendação e não ter uma tarefa pra desenvolver e outra pra testar as unidades, tudo deve ser feito em conjunto. A terceira e ultima dica e reportar o progresso para incentivar as boas práticas. Para Andrew, um código completo sem unidades de teste quer dizer que o programa esta 0% realizado. Por outra lado, as unidades de teste realizadas e o código por ser desenvolvido quer dizer que o programa esta 80% realizado.

O artigo finaliza com a seguinte frase:

Programadores de verdade não testam. Eles não tem que testar. Eles ja testaram.

Lendo os comentários do post percebi que algumas pessoas não entenderam o que Andrew quis dizer. O autor diz que os desenvolvedores não testam, mas no artigo também diz que eles testam conforme vão programando, como é isso?

Pelo que eu entendi, estamos falando de dois tipos de testes. O primeiro tipo de teste e o que os bons desenvolvedores não gostam de fazer de acordo com o artigo, é o teste de integração. O segundo tipo de teste e o que os desenvolvedores fazem a cada momento, é o teste de unidade.

Pessoalmente, acho que os desenvolvedores não devem gastar tempo em fazer testes de integração. E claro que depois de acabar um programa o funcionalidade, devem dar uma testada para verificar que tudo esteja funcionando, mas os testes de integração normalmente requerem de muito tempo e paciência.

Para dar um exemplo, nessa semana desenvolvi uma funcionalidade que dependendo de alguns dados de histórico gerados por outra funcionalidade, gerava uma previsão de dados que seguidamente seria consultada por uma terceira funcionalidade. Depois de ter acabado a funcionalidade pela qual eu estava encarregado, fiz um ultimo teste e verifiquei que tudo esteja funcionando. Ia passar a minha seguinte tarefa quando meu gerente falo que tinha que fazer um bom teste de integração e verificar que tudo esteja correto e os dados batendo.

Tentei explicar pra ele que a tarefa ia demorar muito e o tempo estava um pouco apertado pelo motivo de faltar pouco para a data de entrega do projeto completo. Diz também que era melhor que a tarefa seja feita pela área de testes e eu dedicar aquele tempo a desenvolver as outras funcionalidades, que é o que melhor sei fazer e onde estaria sendo mas produtivo. Meu gerente respondeu dizendo que a tarefa seria feita depois novamente pela area de testes e que o que ele não queria era que depois a área de testes criasse um chamado mencionando que existia uma inconsistência, mesmo sendo causada por uma terceira funcionalidade.

Utilize dois dias então em testar que tudo esteja correto e somente encontrei um erro, em outra terceira funcionalidade. Foi corrigido e passado para testes. O ruim foi que chegou a data de entrega do projeto e não tudo estava pronto. Teve que trabalhar uma par de horas fora do horário de trabalho com uns colegas para poder finalizar o projeto sem postergar muito o prazo. Si eu não tivesse utilizado aqueles dois dias em fazer os testes de integração, o projeto tinha sido finalizado dentro do prazo. O pior é que tudo o trabalho que eu fiz, vai ser realizado novamente pela área de testes, ocorrendo um re-trabalho.

Para finalizar, me quedo com as palavras do Chris, retiradas dos comentários do artigo:

Eu concordo com que os programadores não devem testar seus programas mas do que a unidade ou algum outro teste durante o desenvolvimento, mas e porque eles são os piores testers. Não importa que tão bom um programador é, eles sempre testam o sistema para verificar que vai funcionar do modo que foi programado. O problema é que muitos usuários não pensam do mesmo modo e terminam inserindo as coisas mais estranhas no programa. Uma boa área de qualidade e testes de uso são extremamente importante para finalizar ate os projetos mais pequenos.

Si alguém tiver uma experiência ou comentário, seja muito bem vinda.