Posts Tagged ‘automatizar’

O bom, o feio e o mal em desenvolvimento – parte 1 – testes automatizados

janeiro 11th, 2010
Conversando com um colega do trabalho, discutíamos sobre a questão dos testes automatizados. Confesso, que nessa altura dos acontecimentos de TI, esse assunto estaria mais que esgotado, porém para minha surpresa, existe gente que ainda insiste dizer que é “perda de tempo” e outros termos menos lisonjeiros.
Esse colega me contou de um projeto onde existiam diversos problemas e que o cliente estava bastante insastifeito, entre outras coisas, com a qualidade das entregas. Isso porque, segundo o próprio cliente, várias vezes as alterações feitas ocasionavame na quebra de funcionamento em outras partes que aparentemente não tinham relação com a mudança pedida.
Quem um dia já trabalho com portais, por exemplo, sabe a encrenca que isso é: páginas, conteúdo dinâmico, caches primários e secundários, gestão de conteúdo instâncias de serviços, etc. Com isso, o entrelaçamento das coisas  é enorme e qualquer alteração implica, considerando situação ideal, no teste de todo o portal. Testar o portal inteiro significa, para uma pessoa, horas e até dias de trabalho (se considerarmos portais de notícias como o G1 e o R7). Agora imagina testar todo o portal a cada commit que for feito… impossível né! não quando automatizamos nossos testes ao invés de delegar isso para uma pessoa.
Antes que comecem o apedrejamento em praça pública de minha pessoa, não estou dizendo para demitir toda a sua equipe de testes (os famosos homologadores). Estou dizendo que as coisas podem ser feitas com um pouco mais de inteligência e maior valor agregado para o cliente.
Voltando a história do meu amigo, devido a questões de negócio, optaram por não “gastar” tempo em criar testes automatizados e o cliente se prontificou em testar tudo que era feito através de sua equipe interna de testadores profissionais. Nem preciso dizer que esta é a raiz da insatisfação do cliente com o quesito qualidade do projeto. Fazendo uso de um ditado popular : “Cão com muito dono ou nenhum, morre de fome de sede” .
Nessa história, quem tomava a decisão estava com uma visão antiga e com prazo de validade vencido sobre a questão de testes. Eles realmente acreditaram ( e acreditam – daqui a pouco chego lá) que investir em automatizar testes é custo e não investimento.  Esqueceram de considerar a qualidade… pensaram somente que precisavam colocar no ar o mais rápido o possível o sistema e os “fins justificariam os meios empregados”. Eles já estão pagando o preço pela péssima escolha, mas como todo “cego opcional” eles, pasmem vocês, não querem que “percamos” tempo em fazer esses bobeiras e culpam os desenvolvedores de todos os erros chamando-nos de incompetentes.
A minha resposta para este conhecido foi simples: mude de emprego. Faltou alguém de visão no projeto para entender que teste nunca é demais. Testes automatizados são um ganho e não perda de tempo. Vejam que nem estou falando em TDD, estou apenas considerando os testes !!!!
Quando “cercamos” nossas as aplicações testes, no mínimo estamos tentando protejar a consistencia da aplicação, evitando que mudanças quebrem-na. Claro que esse testes poderiam ser feitos por uma pessoa, mas imagine o custo (dinheiro mesmo !!!! tempo!!!) para que isso fosse feito num tempo hábil e com um retorno rápido para o desenvolvedor… Teste automatizados garantem isso. Sua aplicação pode ser testado o tempo todo e com isso, mesmo pequenas alterações levam a testar o todo verificando se a integridade não foi quebrada.
Isso, apesar de no começo representar mais trabalho, no final, gera um valor agregado imenso pois as coisas são entregues quando realmente estão prontas e com uma qualidade minima. Caso ainda queiram passar pela equipe de homologação, essa ficará livre para testar os requisitos e não se campo numérico aceita string.
Na literatura corrente, e por isso não foi me extender mais, existem diversos livros, artigos, blogs, textos, twitter, etc mostrando e provando porque devemos usar testes automatizados. Porém, me assusta o fato de ainda existirem gerentes, diretores e donos de empresa que consideram isso perda de tempo. Para estes a previsão é sombria. O mercado está aquecido por isso qualquer “bundão” consegue vender algo. Haverá um momento de retração e nova expansão e aí, somente quem estiver pronto, ágil e preparado sobreviverá… e não acredito que esses caras que eu citei estarão preparados.
Bem isso, até a próxima.

Automatizando o operacional

novembro 19th, 2009

Uma das coisa que me incomondam bastante é toda vez que vou iniciar um projeto, e tenho que montar um ambiente de desenvolvimento, perco horas e mais horas para completar a tarefa. Tudo porque, na maioria das empresas para as quais trabalhei, trabalho e trabalharei,  nunca tem um processo automatizado e padronizado de montagem de ambiente.  Sei que isso pode soar um tanto burocrático e o pessoal que odeia qualquer coisa que possa virar papel vai dizer que isso é uma heresia, mas acredito que é um mal necessário.
Para a grande parte das pessoas que começam numa nova empresa, projeto, etc, a rotina sempre a mesma :  horas baixando instaladores,  horas instalando tudo (pior se for em windows, pois as vezes tem que dar reboot na máquina), mais um monte de outras horas para configurar, criar usuários, baixar código, entender como funciona o build, e por aí se vão dias de trabalho gerando zero de valor agregado para o cliente.  O mais esquisito, que mesmo sendo isso um mega prejuízo para o projeto – uma pessoa consumindo horas do projeto sem fazer “nada” , não existe nenhum movimento para mudar essa realidade.
Não estou falando de processos ultra-automatizados que lê mentes e pelo jeito que você diz bom dia monta a sua máquina,  estou falando de coisas simples, como padronizar, repositórios internos de instalações e bibliotecas, uso de produtos que automatizem build e tarefas repetitivas, etc.  Estou falando também de, no caso de empresa maiores,  uma imagem de ambiente (backup) padronizada para que quando um novo desenvolvedor chegue, basta comprar um novo computador, baixar a imagem e configurar.
Não faltam ferramentas, produtos e soluções no mercado que podem ajudar a qualquer um a resolver isso. Em aplicações java, temos o maven (maven.apache.org) que pode cobrir muito bem quase toda o problema:  ele pode montar o projeto, instalá-lo, baixar as bibliotecas, configurar ambiente, compilar e fazer build, etc; além dele existe a opção de escrever em ant (ant.apache.org)  diversos scripts para automatizar build de aplicação, montagem de ambiente, etc. Em Ruby,  aqui não muito minha praia, acredito que existe o gems e o rake que facilitam bem esse trabalho.  Para os passo não cobertos por essas ferramentas, existem outras.  Em última instancia, pode ser colocado como uma história do sprint ( ou uma tarefa de backlog) e assim criar um programa que faça isso (bash, bat, cmd ,etc).
A questão mais importante é que exista algo padronizado e de preferencia automatizado, fazendo que se perca o mínimo de tempo possível com tarefas que não agregam valor ao cliente que está pagando.  A ideia é exatamente de não perder tempo com coisas que não geram retorno: atividades repetitivas, processos  que podem ser automatizados e outras coisas, maximizando o foco na funcionalidade.