Homologação é garantia de tranquilidade?

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 está funcionando.

A prática mostra que infelizmente a homologação não é garantia de erro zero, pois 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 está 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 deixou de existir.

A garantia da tranquilidade de todo o ciclo de desenvolvimento, passa pela boa utilização das práticas 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, este deve diferentemente do que em algumas corporações não fazem, ser uma cópia exata do ambiente de produção, pois de nada adianta homologar um sistema e seu funcionamento, se todas as condições, interfaces e sistemas não forem 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, e afirmando 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 management desaparece, e entra em cena a caça às 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é a disponibilização adequada e fiel de cada ambiente.