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 esta funcionando.

 A prática 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ócios 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 reduzida 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, ela deve, diferentemente do que fazem em algumas corporações, 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 que, em reuniões de change management para definição de quais aplicações irão para deploy, os responsáveis pela homologação garantam 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 aí, a pseudo garantia assumida pelo time de homologação no momento de reunião de change 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é na disponibilização adequada e fiel de cada ambiente.