Homologação do sistema: como testar antes de aceitar a entrega

O e-mail chega numa quinta-feira à tarde: "O sistema está pronto para homologação. Pedimos a validação até quarta-feira para seguirmos com a implantação". Junto vem um link, um usuário de administrador e uma senha. A gestora abre, clica em três ou quatro telas, cadastra um cliente de teste, vê que salvou e responde que está tudo certo. Três semanas depois, com a equipe usando de verdade, o relatório de comissão sai errado para quem vende parcelado, e o fornecedor responde que aquilo foi aprovado na homologação.

Essa cena se repete em empresa pequena, média e grande, com fornecedor bom e com fornecedor ruim. A homologação é o momento em que a empresa tem mais poder sobre o projeto, e quase sempre é tratada como formalidade. Depois do aceite, o que era defeito vira pedido de alteração, e pedido de alteração tem prazo e preço próprios.

Este guia é para quem contratou um sistema online ou aplicativo sob medida e está prestes a receber a entrega. Não exige conhecimento técnico: exige método e algumas horas da equipe certa.

O que é homologação, sem o jargão

Homologar é testar o sistema do ponto de vista de quem vai usar, num ambiente separado do uso real, para decidir se ele faz o que foi combinado. É diferente do teste que o próprio fornecedor faz durante o desenvolvimento. O programador testa se o código funciona; a empresa testa se o trabalho funciona.

Um botão de "gerar boleto" pode funcionar perfeitamente e gerar o vencimento errado para clientes com prazo especial, porque ninguém contou ao programador que esse prazo existia. Quem emite boleto todo dia percebe em dois minutos.

Em geral ela acontece num ambiente de testes: uma cópia do sistema, com endereço próprio, onde dá para errar sem consequência. Se o fornecedor pede para homologar direto no sistema de produção, com dados reais, isso já é um sinal a discutir antes de começar.

Por que a empresa não pode deixar o teste com o fornecedor

O fornecedor sério testa. Mas ele testa o que entendeu, e o que ele entendeu veio de reuniões, de um documento de escopo e de mensagens trocadas ao longo de meses. Toda regra que ficou implícita, todo "isso é óbvio" que ninguém escreveu, só aparece quando alguém da operação usa o sistema.

Há também um motivo contratual. Na maior parte dos contratos, o aceite encerra a entrega e dispara pagamentos, garantia e mensalidade de suporte. A partir dali, o ônus de provar que algo é defeito, e não mudança, passa a ser da empresa. Testar bem antes de assinar é a forma mais barata de evitar essa discussão.

Antes de testar: o critério de aceite vem do escopo

Não dá para dizer se algo está pronto sem saber o que "pronto" significa. Por isso a homologação começa antes do sistema chegar, lá no escopo do sistema. Se o escopo diz "módulo de pedidos", qualquer tela de pedidos cumpre. Se diz "o vendedor cadastra o pedido, o sistema aplica a tabela de preço do cliente e bloqueia desconto acima de 10% sem aprovação do gerente", existe um critério que dá para testar.

Se o escopo do seu projeto ficou genérico, ainda dá tempo de fazer o trabalho agora. Antes de abrir o sistema, liste por escrito:

• Os processos que o sistema precisa cobrir, do começo ao fim: do orçamento ao faturamento, do chamado ao fechamento, da entrada ao estoque.
• As regras de negócio que valem dentro de cada processo: tabelas de preço, prazos, aprovações, impostos, limites.
• Os relatórios e números que a gestão vai usar para decidir, com a forma de cálculo de cada um.
• As integrações com outros sistemas: emissor de nota, banco, loja virtual, transportadora, planilhas que continuam existindo.

Mande essa lista ao fornecedor antes de começar. Ela quase sempre revela algum mal-entendido que é melhor descobrir agora.

Quem deve testar

O erro mais comum é deixar a homologação com uma pessoa só, normalmente quem acompanhou o projeto. Ela conhece bem as reuniões e mal a rotina de cada setor. O teste bom tem uma pessoa por área que vai usar o sistema, de preferência quem faz o trabalho, e não quem chefia.

• Quem opera todo dia: a atendente, o vendedor, o auxiliar de estoque. São eles que sabem os casos esquisitos que acontecem toda semana.
• Quem confere números: o financeiro ou o contador, para checar se os totais, impostos e comissões batem com o cálculo que a empresa já faz hoje.
• Quem decide: o dono ou gestor, que olha relatórios e painéis e responde a pergunta que importa, que é se dá para gerir a empresa com aquilo.

Reserve tempo de verdade na agenda dessas pessoas: duas ou três sessões de uma hora por área, com o roteiro na mão, rendem mais do que uma semana de "dá uma olhada quando puder".

Como montar o roteiro de teste

O roteiro é uma lista de situações para executar e conferir, escrita em linguagem de operação. Ele não precisa de ferramenta especial: uma planilha com colunas para o passo, o resultado esperado, o resultado obtido e quem testou resolve. O que importa é cobrir quatro tipos de caso.

O caminho feliz

É o processo do jeito que ele deveria acontecer: cliente cadastrado, pedido feito, pagamento aprovado, nota emitida. Comece por ele, porque se o caminho feliz falha, o resto não vale o tempo. Use casos reais da última semana, com os mesmos produtos, os mesmos valores e os mesmos clientes, e compare o resultado com o que aconteceu de verdade.

O caminho errado

É o que acontece quando alguém erra, desiste ou volta atrás: pedido cancelado depois de faturado, cliente que paga metade, produto devolvido, cadastro duplicado, campo obrigatório deixado em branco. É aqui que a maioria dos defeitos aparece, porque é o tipo de caso que o fornecedor testa menos.

Os perfis de acesso

Entre no sistema com o usuário de cada função, e não só com o administrador que veio no e-mail. Confira se o vendedor vê só o que deve ver, se o estagiário não consegue apagar um pedido e se a aprovação de desconto realmente bloqueia. O controle de acesso é a parte que mais passa sem teste, porque o administrador consegue fazer tudo.

O volume real

Um sistema que responde rápido com dez clientes cadastrados pode travar com doze mil. Peça que o ambiente de homologação tenha volume parecido com o real: a base de clientes importada, o histórico de pedidos do último ano, o catálogo inteiro. Teste a busca, os relatórios do mês e a exportação com esse volume. Se o sistema for usado no celular, teste também no celular, na rede da empresa e no 4G.

Dados de teste: nem vazio, nem produção

Homologar num sistema vazio esconde problema de desempenho, de importação e de relatório. Homologar com a base real de clientes, sem cuidado, cria outro problema: dados pessoais circulando num ambiente com menos proteção, às vezes com acesso de mais gente do que deveria. A LGPD vale para o ambiente de testes também.

O meio-termo que funciona é uma cópia da base com os dados pessoais trocados por valores fictícios, mantendo quantidade, valores e datas. E desligue no ambiente de testes tudo o que fala com o mundo de fora: e-mail de cobrança, WhatsApp ou nota fiscal disparados para cliente real são um incidente mais comum do que parece.

Como registrar um defeito que o fornecedor consegue corrigir

"O relatório está errado" não é um defeito, é uma queixa. O fornecedor vai precisar de mais três mensagens para entender, e a correção atrasa. Um registro bom tem sempre os mesmos elementos:

1. O que foi feito, passo a passo, com o usuário usado.
2. O que era esperado, de preferência citando a regra do escopo.
3. O que aconteceu, com o print da tela e o número do registro envolvido.
4. A gravidade: impede o uso, atrapalha com contorno possível, ou é detalhe visual.

Concentre tudo num lugar só: defeito relatado por áudio no WhatsApp do programador some. E combine desde o início que cada correção volta para teste: o defeito só é dado como resolvido quando quem relatou confere e confirma.

Defeito, ajuste ou pedido novo: a discussão mais comum

Toda homologação produz três tipos de item, e misturar os três é o que mais gera atrito entre empresa e fornecedor.

• Defeito é quando o sistema não faz o que estava combinado. A correção é obrigação do fornecedor, sem custo, e precisa acontecer antes do aceite ou dentro da garantia.
• Ajuste é quando o combinado foi entregue, mas o uso mostrou um detalhe a melhorar: um campo fora de ordem, um filtro que faltou, um texto confuso. Fornecedor razoável costuma absorver uma quantidade pequena disso.
• Pedido novo é quando a equipe percebe, usando, que precisa de algo que não estava no escopo. É legítimo, mas é outra entrega, com orçamento próprio.

Quem separa é o documento de escopo. Quando ele não responde, negocie: parte vira pedido novo, parte o fornecedor absorve. O que não funciona é segurar o aceite por pedido novo, nem aceitar com defeito grave porque o prazo apertou.

O que conferir além das telas

A homologação costuma olhar só para o que aparece na tela. Mas o aceite é também o momento de conferir se a empresa está recebendo o controle do próprio sistema, e não só o direito de usá-lo. Antes de assinar, confira:

• O código-fonte entregue ou depositado, conforme o contrato, numa conta ou repositório em nome da empresa.
• Os acessos de administrador do sistema, do servidor, do domínio e do banco de dados, com usuário de alguém da empresa.
• As contas de terceiros que o sistema usa, como gateway de pagamento, envio de e-mail, mapas e, se for aplicativo, a conta nas lojas da Apple e do Google, todas no CNPJ da empresa.
• O backup: onde fica, com que frequência roda e quando foi o último teste de restauração.
• A documentação mínima: um manual de uso por perfil e um registro das regras de negócio implementadas, para que outro fornecedor consiga dar continuidade se for preciso.

Nada disso dá trabalho para o fornecedor de boa-fé, e tudo fica mais difícil de conseguir depois do último pagamento. E o sistema continua custando depois de entregue, como mostra o guia sobre o custo de manter um aplicativo.

Quando assinar o aceite, e o que fica para depois

O aceite não precisa esperar o sistema ficar perfeito, porque nenhum fica. O critério razoável é: nenhum defeito que impeça o uso dos processos principais, os defeitos menores listados com prazo de correção, e os itens de controle da seção anterior conferidos.

Muitas empresas usam o aceite parcial ou provisório: o sistema entra em uso, e o aceite definitivo vem depois de 30 dias de operação real, período em que aparecem os casos que nenhum roteiro previu, como o fechamento do mês e a primeira folha de comissão. Se o contrato não prevê isso, vale propor por escrito antes do início da homologação.

Combine também a garantia: por quanto tempo o fornecedor corrige defeitos sem custo, e em que prazo de atendimento.

Por fim, planeje a virada: importação final, treinamento e um plano para o primeiro dia. Quem troca uma planilha que virou sistema ganha um seguro barato mantendo a planilha em paralelo por uma ou duas semanas.

A NSWeb desenvolve sistemas online e aplicativos sob medida para pequenas e médias empresas, com ambiente de homologação separado, código e acessos em nome do cliente. Fale com a gente pelo formulário de contato e conte em que fase está o seu projeto: ainda no escopo, em desenvolvimento ou com uma entrega para validar.

Perguntas frequentes

As dúvidas mais comuns de quem vai homologar um sistema ou aplicativo pela primeira vez.