Homologação de sistema: o que conferir antes de pagar o fornecedor

Homologação de sistema é a etapa em que a empresa contratante confere, com os próprios usuários e com situações reais da operação, se o que o fornecedor entregou atende ao que foi combinado, antes de dar o aceite formal e liberar o pagamento. Quem conduz é o cliente. Para funcionar, ela precisa de critérios de aceite escritos antes da entrega, de um roteiro de testes tirado do dia a dia da empresa e de uma pessoa com autoridade para recusar a entrega.

A cena costuma ser assim. O fornecedor avisa que o sistema está pronto. Alguém da empresa cadastra um cliente de teste, emite um pedido, vê que salvou e responde o e-mail com um "ok". O financeiro libera a última parcela. No primeiro fechamento de mês, o relatório de comissões sai errado e o pedido com desconto especial não fatura. O fornecedor responde que comissão sobre desconto especial nunca foi especificada e manda um orçamento.

Pode ser que ele tenha razão. Pode ser que não. O problema é que ninguém na empresa consegue provar nenhuma das duas coisas.

De quem é a responsabilidade pela homologação?

Da empresa que contratou. O fornecedor testa o que construiu antes de entregar, e isso é obrigação dele, mas só quem opera o negócio sabe dizer se o sistema resolve o problema que motivou a contratação.

O glossário do ISTQB, entidade internacional de certificação em teste de software, chama isso de teste de aceitação: um teste formal que confere o sistema contra as necessidades do usuário, os requisitos e os processos de negócio, para que o cliente decida se aceita ou não a entrega. Quando é feito pelos próprios usuários, ganha o nome de teste de aceitação do usuário, ou UAT. No Brasil, o mercado chama tudo isso de homologação.

O "pronto" do fornecedor tem outra função. O Guia do Scrum chama de Definition of Done o padrão de qualidade que a equipe se compromete a cumprir em cada entrega. Ele foi escrito por quem constrói; o aceite precisa partir de critérios que a empresa contratante aprovou.

O motivo para levar isso a sério é dinheiro. Enquanto a parcela está em aberto, o fornecedor tem todo o interesse em corrigir rápido. Depois do pagamento, cada problema vira negociação.

Quem já comprou apartamento na planta conhece esse momento. Na vistoria de entrega das chaves, o comprador cuidadoso leva uma lista, abre cada torneira, testa as tomadas e anota tudo no termo antes de assinar. O comprador apressado assina, faz a mudança e só então percebe a infiltração atrás do armário. A partir daí, cada conversa com a construtora começa pela pergunta sobre quem causou o problema e quando.

O setor público já escreveu regra para isso. A Lei 14.133/2021, no art. 140, separa o recebimento provisório, feito por quem acompanhou a execução, do definitivo, feito por servidor ou comissão designada, ambos com termo detalhado, e permite rejeitar a entrega no todo ou em parte. Empresa privada não está sujeita a essa lei, mas a lógica serve do mesmo jeito.

O que conferir antes de dar o aceite?

Primeiro, os critérios. Critérios de aceite são as condições que o sistema precisa cumprir para ser aceito, e eles devem estar escritos antes da entrega, de preferência antes de o desenvolvimento começar. "O sistema deve calcular comissões corretamente" não serve, porque cada lado vai interpretar de um jeito. "Para os pedidos de setembro, a comissão do sistema bate com a planilha do financeiro em todos os vendedores" serve, porque qualquer pessoa da área consegue conferir. Se o projeto já começou sem critérios, ainda dá tempo: escreva com a área usuária antes da próxima entrega e peça a concordância do fornecedor por escrito.

Depois, o roteiro. Ele é a lista das situações que os usuários vão executar no sistema, cada uma com o resultado esperado, e deve sair de quem conhece a operação. Inclua o fluxo de uma segunda-feira normal, as exceções que aparecem toda semana (devolução, cancelamento, desconto fora da tabela), os eventos de calendário como fechamento de mês e as integrações com ERP, banco ou nota fiscal. Teste com dados parecidos com os reais, num ambiente separado do sistema em uso. Dados fictícios escondem justamente os problemas do cadastro de verdade. Se for usar cópia da base real, mascare os dados pessoais e combine o procedimento com o jurídico, porque a LGPD se aplica.

Por fim, a classificação do que aparecer. O que contraria um critério combinado é defeito e entra na garantia. O que não estava escrito em lugar nenhum é pedido novo e tem custo, mesmo quando parece óbvio para quem usa. Registre cada problema com o passo a passo, o resultado esperado e o critério que ele contraria. Sem esse registro, a conversa com o fornecedor vira disputa de memória.

Como ligar o aceite ao pagamento?

O aceite deve ser um documento, e o pagamento deve depender dele. Três formatos funcionam bem e podem ser previstos no contrato. No aceite por etapa, cada módulo é homologado e pago separadamente. No aceite com pendências, o sistema entra em uso, os problemas que não travam a operação ficam listados com prazo, e uma parte do valor só sai quando forem resolvidos. No aceite provisório e definitivo, o primeiro libera o uso e o segundo vem depois de um período de operação real, quando o primeiro fechamento de mês já passou.

Junto com o aceite, a empresa deve receber o que garante a autonomia dela: o código no repositório da própria empresa, os acessos administrativos e a documentação mínima para outra equipe dar manutenção. Como isso envolve contrato e propriedade, vale passar a redação pelo jurídico.

Também importa quem assina. O aceite precisa de alguém com autoridade para recusar a entrega, e quem estava mais livre naquela semana raramente é essa pessoa. Em empresa sem liderança técnica, costuma ser o diretor da área usuária, apoiado por alguém que entenda de tecnologia: um profissional da casa, uma consultoria independente ou um CTO sob demanda que acompanhe os fornecedores sem ser um deles.

Nem toda entrega pede esse ritual. Para um ajuste pequeno num relatório, a confirmação do usuário basta. Em software pronto contratado por assinatura, o produto é igual para todos os clientes, então o que se homologa é a configuração, as integrações e a migração dos dados. Numa prova de conceito, exigir o rigor de um sistema de produção atrasa a resposta que se queria comprar. E a homologação tem seus próprios riscos: vira canal para pedido novo disfarçado de defeito, ou atrasa o projeto quando a empresa leva semanas para testar. Ela reduz o risco, sem eliminar defeito em produção, e por isso a garantia continua necessária.

O próximo passo cabe numa tarde. Antes da próxima entrega, escolha quem vai assinar o aceite e peça a essa pessoa que escreva, com a equipe que usa o sistema, as dez situações da operação que precisam funcionar sem falha. Mande a lista ao fornecedor e peça a confirmação por escrito de que a entrega cobre esses casos. Se quiser conversar sobre como estruturar isso na sua empresa, estamos à disposição.