Converge Comunicações -

RSS Feed Compartilhe TI INSIDE Online no Facebook Compartilhe TI INSIDE Online no Twitter Compartilhe TI INSIDE Online no Google+ Compartilhe TI INSIDE Online no Linkedin

Homologação é garantia de tranquilidade?

Postado em: 11/11/2014, às 07:38 por Alberto Marcelo Parada

A homologação tornou-se no passado recente o carimbo proferido pelas áreas usuárias de aprovação de que tudo o que foi solicitado foi entregue e esta funcionando.

A pratica mostra que infelizmente a homologação não é garantia de erro zero, ela transformou-se com o passar dos anos em uma divisão de responsabilidades, antes dela qualquer erro identificado na produção pela área de negócio era atribuída imediatamente a um erro do time de desenvolvimento ou um problema no deploy pela produção.

Hoje a responsabilidade esta dividida, com o advento dos ambientes de desenvolvimento, teste, homologação e produção a possibilidade de encontrar problemas foi reduzido drasticamente, mas não deixaram de existir.

A garantia da tranquilidade de todo o ciclo de desenvolvimento passa pela boa utilização das praticas de mercado no desenvolvimento, uma validação do código pelo pessoal de testes que necessariamente deve estar envolvido desde os levantamentos dos requisitos até a entrega do sistema testado para o ambiente de homologação garantindo que todos os padrões e casos de testes foram exaustivamente trabalhados e aplicados para eliminar os erros e dúvidas.

Quando a aplicação chega ao ambiente de homologação e este deve diferentemente do que em algumas corporações não fazem ser uma cópia exata do ambiente de produção, porque vejamos, de nada adianta homologar um sistema e seu funcionamento se todas as condições, interfaces e sistemas não sejam exatamente o que será encontrado no ambiente de produção.

É muito comum encontrarmos em reuniões de change management para definição de quais aplicações irão para deploy, os responsáveis pela homologação garantirem que o sistema foi exaustivamente testado por todas as áreas garantindo que pode ser publicado e no momento do deploy descobrir-se que determinadas interfaces com outros sistemas não estão gerando o resultado esperado porque o sistema que a interface irá interagir sofreu alterações que não foram contempladas no desenvolvimento da aplicação que acabará de ser promovida.

E ai a pseudo garantia assumida pelo time de homologação no momento de reunião de change desaparece e entra em cena a caça as bruxas, na maioria das vezes tem-se como resultado que a culpa é de ninguém até porque seria impossível o time de desenvolvimento saber da alteração da aplicação na interface, o time de teste prever os casos de teste de algo que não será possível testar e a equipe de homologação ter certeza de ter validado todas as funções de negócio solicitadas.

Podemos concluir que a homologação será uma garantia de tranquilidade para todos os níveis da corporação se a corporação tiver a serenidade de investir de maneira correta em todo o ciclo de desenvolvimento da aplicação, desde a capacitação dos analistas de requisitos, até na disponibilização adequada e fiel de cada ambiente.

Alberto Marcelo Parada, formado em administração de empresas e análise de sistemas, com especializações em gestão de projetos pela FIAP. Já atuou em empresas como IBM, CPM-Braxis, Fidelity, Banespa, entre outras. Atualmente integra o quadro docente nos cursos de MBA da FIAP, além de ser diretor de projetos sustentáveis da Sucesu-SP

Tags: , , ,

1 Comentário

Deixe o seu comentário!

Nome (obrigatório)

E-mail (não será mostrado) (obrigatório)

Website

Mensagem (obrigatório)



Top