Delimite a entrega e a decisão que será tomada
Homologação, neste roteiro, é a verificação técnica e de uso de uma entrega de software. Não confunda esse trabalho com a homologação da licitação. Identifique sistema, módulo, versão e itens efetivamente entregues. Uma manutenção de relatório e a implantação de um sistema completo exigem recortes diferentes, mesmo quando pertencem ao mesmo contrato.
Reúna contrato, termo de referência, proposta e documentos que definem as obrigações pertinentes. Confira também o procedimento institucional de fiscalização e recebimento. O artigo 140 da Lei nº 14.133/2021 disciplina recebimentos provisório e definitivo, com condições conforme o objeto. A aplicação ao caso e a competência para cada ato precisam ser confirmadas pela equipe responsável, sem deduzir prazos de um roteiro genérico.
A orientação do DATASUS distingue a entrega para validação da confirmação posterior do sistema ou funcionalidade. Essa separação ajuda a evitar que a assinatura de um recibo seja interpretada como demonstração de conformidade. Registre qual ato está sendo preparado e quais evidências ainda precisam ser obtidas antes da decisão correspondente.
Monte uma matriz entre obrigação e evidência
Para cada requisito, registre sua referência, uma descrição verificável, o responsável pela avaliação e o modo de conferir. Acrescente condição inicial, ação e resultado esperado. A frase permitir acompanhamento não é suficiente: descreva qual perfil consulta qual solicitação, quais informações aparecem e o que acontece quando não existe autorização para visualizar o registro.
Uma matriz simples pode usar cinco colunas: requisito, cenário, expectativa, evidência e resultado. Evite converter cada frase do contrato em um teste isolado se várias descrevem a mesma jornada. Também não agrupe obrigações diferentes em um único item chamado sistema funcionando. O vínculo deve permitir explicar uma falha e localizar a exigência que ela afeta.
Se a obrigação estiver ambígua, encaminhe a interpretação à instância competente antes de tratar uma preferência como defeito. Não acrescente funcionalidades por iniciativa da equipe de testes. Registre necessidades novas separadamente, para avaliação pelo procedimento cabível. A homologação precisa comprovar o objeto exigível e informar riscos, sem alterar informalmente o acordo estabelecido.
Prepare condições que tornem o resultado reproduzível
Identifique versão do software, configuração relevante, integrações disponíveis e dados usados. Se uma correção for instalada durante a sessão, registre a mudança e quais casos precisam ser repetidos. Sem essa referência, uma evidência pode mostrar comportamento de versão diferente daquela encaminhada ao recebimento, tornando a conclusão difícil de sustentar.
Use ambiente autorizado e dados sintéticos sempre que forem suficientes para o objetivo. Se houver necessidade justificada de informação real, observe o procedimento institucional e seus controles. Não encaminhe uma cópia completa de cadastros para o fornecedor apenas para facilitar o teste. A preparação deve preservar a proteção dos dados e permitir testar os perfis necessários.
Inclua condições semelhantes às de operação: navegador utilizado pela equipe, recursos de acessibilidade, limites de anexo e dependências de outros sistemas, conforme o escopo. Anote diferenças conhecidas entre homologação e produção. Um resultado positivo em ambiente simplificado precisa vir acompanhado do que ele não permitiu verificar, em vez de ser apresentado como garantia universal.
Teste jornadas completas e exceções relevantes
Escolha tarefas que atravessem o fluxo necessário ao serviço: iniciar, conferir, enviar, consultar e concluir quando essas etapas existirem. Uma tela pode funcionar isoladamente e não preservar o registro na passagem seguinte. Peça à área usuária que execute a atividade com instruções suficientes, sem depender de o fornecedor conduzir cada clique ou corrigir o cenário silenciosamente.
Acrescente erros previsíveis: campo inválido, duplicidade, ausência de permissão, indisponibilidade de integração e tentativa de retomar uma operação interrompida. Confira se o sistema orienta o próximo passo e preserva o que deve ser preservado. O roteiro de acessibilidade de formulários municipais ajuda a testar teclado, mensagens e confirmação quando fazem parte da entrega.
Priorize conforme o impacto e as obrigações contratadas. Uma função que autoriza uma ação sensível exige verificação diferente de uma mudança de aparência. Quando usar amostragem, registre sua justificativa e alcance. Não escreva todos os casos aprovados se apenas alguns foram executados. Casos não testados precisam aparecer como tal para orientar a decisão.
Verifique dados e integrações além da tela
Confira se um registro criado pode ser recuperado com valores e relacionamentos corretos. Quando houver cálculo, utilize exemplos com resultado esperado conhecido pela área responsável. Se a entrega inclui migração, compare quantidades, campos relevantes e exceções de origem. A contagem total sozinha não prova que cada informação foi associada ao registro adequado.
Nas integrações, observe o significado do retorno, a autorização e o tratamento de falha. Um aviso de enviado pode representar apenas a saída de uma requisição, enquanto a operação no destino continua pendente. O guia sobre interoperabilidade ajuda a distinguir conectividade de consistência operacional e a definir o que precisa ser confirmado entre as partes.
Exporte os resultados quando a função estiver prevista e teste sua leitura. Documentação, perfis e meios de continuidade também podem integrar o objeto contratado. O planejamento da transição de fornecedor contribui para examinar se a instituição conseguirá usar e recuperar suas informações sem depender de uma demonstração conduzida por quem desenvolveu o sistema.
Registre falhas de modo que possam ser corrigidas
Cada ocorrência deve conter cenário, versão, passos necessários, expectativa e resultado observado. Inclua evidência proporcional, como registro de execução ou captura com dados protegidos. Diferencie falha do produto, configuração inadequada, dependência indisponível e dúvida sobre o requisito. Essa classificação facilita encaminhamento, sem antecipar responsabilidade contratual antes da análise competente.
Descreva o impacto: impede concluir a tarefa, apresenta informação incorreta, expõe conteúdo ou dificulta uma ação específica. Evite adjetivos vagos como grave sem explicar a consequência. Caso existam níveis de criticidade ou critérios de bloqueio definidos no contrato ou procedimento, aplique-os consistentemente. A equipe deve conseguir relacionar a pendência a uma decisão de uso ou recebimento.
Peça que a correção identifique o que mudou e execute novamente o cenário original. Depois confira os fluxos próximos que podem ter sido afetados. Uma resposta do fornecedor dizendo corrigido é um encaminhamento para verificação. Preserve a evidência anterior e o novo resultado para demonstrar a diferença, inclusive quando a correção resolve apenas parte do problema.
Separe resultado técnico e formalização do recebimento
Consolide requisitos verificados, casos não executados, falhas resolvidas e pendências. Registre as condições do teste e a identificação da versão avaliada. O relatório técnico precisa sustentar a atuação de quem tem competência para decidir. Participar da sessão de homologação não transforma automaticamente cada usuário em responsável pelo ato formal de recebimento.
Um parecer da Secretaria de Governo Digital sobre contratação específica de software examina critérios de aceitação, homologação e conformidade das entregas. O exemplo reforça a ligação entre planejamento e verificação, mas suas condições não devem ser copiadas como regra geral de qualquer município. As consequências de uma pendência devem seguir o contrato e o regime aplicável.
Se houver aceitação de alguma condição ou encaminhamento para correção posterior permitido no caso, registre fundamentação, autoridade responsável e acompanhamento. Não esconda falhas para cumprir uma data de lançamento. Tampouco anuncie rejeição, glosa ou sanção como resultado automático de um teste: essas medidas dependem do procedimento e da avaliação das instâncias competentes.
Faça a operação reconhecer o que foi recebido
Entregue à equipe usuária as instruções e os limites relevantes da versão aceita. Confirme suporte, registro de ocorrências e responsáveis pela continuidade conforme o escopo. Uma evidência de teste perde utilidade se a operação começa com configuração diferente e ninguém sabe identificar a entrega. A passagem para uso precisa preservar essa referência e suas pendências.
Defina o destino do material de homologação e o acesso autorizado. Anexe as evidências necessárias ao procedimento institucional, evitando arquivos dispersos em contas pessoais. Quando chegar uma atualização, a matriz anterior ajuda a selecionar regressões pertinentes. Ela deve evoluir com requisitos e riscos, sem obrigar a equipe a repetir indiscriminadamente tudo a cada mudança pequena.
Para prefeituras e secretarias, o ganho prático é uma decisão de recebimento que pode ser explicada: qual obrigação foi conferida, com qual cenário e resultado. A homologação termina quando há evidência suficiente para a decisão competente e encaminhamento das lacunas. O número de telas demonstradas não substitui essa ligação entre necessidade e entrega.
Perguntas frequentes
Homologação técnica é a homologação da licitação?
Não. Aqui o termo descreve a verificação da entrega do software. Os atos e competências da contratação devem ser tratados pelo procedimento próprio.
A apresentação do fornecedor basta para aceitar a entrega?
A apresentação pode ajudar, mas a avaliação deve conferir os requisitos exigíveis, registrar os testes executados e sustentar o recebimento pela autoridade competente.