Site Acceptance Testing, geralmente abreviado como SAT, é um processo formal de verificação realizado depois que equipamentos, software, sistemas ou soluções integradas são instalados no local do cliente. Seu objetivo é confirmar que o sistema entregue funciona corretamente no ambiente real de operação, atende aos requisitos do projeto, integra-se aos sistemas relacionados e está pronto para entrega, operação ou aprovação final.

Diferente dos testes de fábrica, realizados antes do envio ou da implantação, o SAT se concentra nas condições reais do local. Alimentação elétrica, conectividade de rede, fatores ambientais, cabeamento de campo, permissões de usuário, interfaces de terceiros, alarmes, lógica de controle, funções de segurança, fluxos de trabalho dos operadores e documentação são verificados nas condições em que o sistema realmente será usado.

Por que a verificação final no local do projeto é importante

Um sistema pode passar pela inspeção de fábrica e ainda assim falhar após a instalação, porque o local real introduz variáveis que não podem ser totalmente simuladas na fábrica. Os comprimentos dos cabos podem ser diferentes, as regras de rede podem ser mais rígidas, as salas técnicas podem ter condições de aterramento diferentes, os operadores podem usar fluxos de trabalho distintos e sistemas de terceiros podem responder de modo diferente dos simuladores de teste.

O SAT ajuda a fechar essa lacuna. Ele fornece uma forma estruturada de verificar que a solução entregue não é apenas tecnicamente completa, mas também operacionalmente utilizável. Para os proprietários do projeto, reduz o risco de aceitar um sistema que depois exija correções repetidas. Para fornecedores e integradores, cria um registro claro do que foi testado, do que passou, do que falhou e do que ainda precisa de acompanhamento.

Em projetos complexos, o SAT também apoia a gestão de responsabilidades. Ele ajuda a diferenciar defeitos de equipamento, problemas de instalação, erros de configuração, falhas de interface, documentos ausentes, lacunas de treinamento dos operadores e condições do local fora do escopo original.

A diferença entre testes de fábrica e testes no local

Factory Acceptance Testing, ou FAT, normalmente é realizado antes que o sistema seja enviado ou entregue. Ele verifica se o produto ou sistema atende aos requisitos acordados em um ambiente de teste controlado. O fornecedor pode simular entradas, saídas, links de rede, ações do operador e condições de falha antes da implantação.

O SAT acontece depois, após a instalação no local do projeto. Ele verifica se o mesmo sistema funciona corretamente com a alimentação real, dispositivos de campo reais, links de comunicação reais, infraestrutura predial, rede do cliente, sistemas de segurança, fluxo de trabalho da sala de controle e operação do usuário final.

Ambos os testes são valiosos. O FAT reduz a chance de enviar um sistema incompleto ou defeituoso. O SAT confirma que o sistema instalado funciona como parte do ambiente real do cliente. Um projeto que ignora qualquer uma dessas etapas pode enfrentar maior risco na comissionamento.

Como o processo de aceitação normalmente funciona

Preparação e planejamento de testes

O processo começa com um plano de testes. O plano define o que será testado, quem participará, quais documentos são necessários, quais ferramentas serão usadas, quais critérios de aceitação serão aplicados e como os resultados serão registrados.

Um bom plano deve estar vinculado ao contrato, à especificação técnica, aos documentos de projeto, aos desenhos aprovados, aos requisitos de interface, aos requisitos de segurança e ao escopo do projeto. Sem critérios claros, o SAT pode se transformar em uma demonstração informal em vez de um processo de aceitação controlado.

Verificação de prontidão do local

Antes do início dos testes formais, a equipe verifica se o local está pronto. Isso pode incluir disponibilidade de energia, aterramento, acesso à rede, instalação de gabinetes, terminação de cabos, condições ambientais, identificação dos equipamentos, instalação de software, ativação de licenças e inicialização básica do sistema.

Se o local não estiver pronto, os testes formais de aceitação podem produzir falhas enganosas. Por exemplo, uma plataforma de comunicação pode parecer defeituosa quando o problema real é uma regra de firewall bloqueada ou cabeamento incompleto.

Testes funcionais

Os testes funcionais confirmam que cada função exigida opera de acordo com a especificação do projeto. Isso pode incluir operação normal, login de usuários, controle de dispositivos, acionamento de alarmes, roteamento de chamadas, exibição de dados, geração de relatórios, entrada de sinais, controle de saídas, gravação, notificação e ações dos operadores.

Os testes funcionais devem ser escritos em linguagem prática. Cada teste deve descrever a ação, o resultado esperado, a condição de aprovação ou falha e a evidência necessária. Isso facilita a verificação do resultado e a auditoria posterior.

Testes de integração

Muitos sistemas dependem de outros sistemas. Uma plataforma predial pode se conectar a alarmes de incêndio, controle de acesso, CFTV, sonorização, elevadores, HVAC, switches de rede, bancos de dados ou software de terceiros. O SAT deve verificar essas interfaces em condições reais.

Os testes de integração costumam revelar problemas ocultos. O sistema principal pode funcionar sozinho, e o sistema de terceiros também pode funcionar sozinho, mas a interface entre eles pode falhar por incompatibilidade de protocolo, atraso de sincronização, erro de endereço, problema de permissão ou diferença de formato de dados.

Verificações de desempenho e confiabilidade

Dependendo do projeto, o SAT também pode incluir testes de desempenho. Isso pode envolver tempo de resposta, qualidade de chamada, taxa de transferência, taxa de atualização de dados, atraso de alarme, comportamento de failover, tratamento de carga, qualidade de gravação, latência de rede ou recuperação do sistema após reinicialização.

As verificações de confiabilidade são importantes para sistemas que dão suporte a segurança, produção, comunicação, energia, transporte, saúde, proteção patrimonial ou serviço público. O sistema não deve funcionar apenas uma vez durante uma demonstração; ele deve funcionar de forma consistente nas condições operacionais esperadas.

O SAT não é uma etapa final cerimonial. É a prova prática de que o sistema entregue pode operar no ambiente real do cliente, com usuários reais, interfaces reais e restrições reais.

Itens típicos incluídos em um checklist

Qualidade de instalação

A equipe verifica se os equipamentos foram instalados de acordo com os desenhos aprovados, padrões do local, regras de segurança e requisitos do fabricante. Montagem de gabinetes, roteamento de cabos, identificação, aterramento, ventilação, proteção de conectores e acesso físico podem ser revisados.

A qualidade de instalação é importante porque um sistema pode passar nos testes de software e ainda assim apresentar riscos futuros de confiabilidade causados por cabos soltos, identificação ruim, aterramento fraco, fluxo de ar bloqueado ou montagem insegura.

Revisão de configuração e parâmetros

As verificações de configuração confirmam que as configurações do sistema correspondem ao projeto. Elas podem incluir endereços IP, funções de usuário, números de ramal, limites de alarme, regras de roteamento, nomes de dispositivos, fusos horários, políticas de gravação, caminhos de armazenamento, permissões de acesso e cronogramas de backup.

A configuração deve ser documentada. Se o sistema precisar ser substituído, recuperado ou expandido posteriormente, configurações não documentadas podem dificultar a manutenção.

Operação do usuário

O SAT deve verificar se o sistema funciona para as pessoas que realmente irão utilizá-lo. Operadores podem precisar fazer login, visualizar status, reconhecer alarmes, realizar chamadas, controlar dispositivos, exportar registros, gerar relatórios, alternar modos ou seguir fluxos de emergência.

Essa etapa muitas vezes revela lacunas de usabilidade. Uma função pode existir tecnicamente, mas se for difícil de encontrar, mal identificada ou inconsistente com o fluxo de trabalho do cliente, pode ser necessário treinamento adicional ou ajuste de interface.

Tratamento de alarmes e falhas

O comportamento de falhas e alarmes deve ser testado cuidadosamente. O sistema deve detectar o evento correto, exibir a mensagem correta, acionar a notificação esperada, armazenar o registro do evento e retornar ao normal depois que a falha for eliminada.

Os testes de alarme são especialmente importantes em ambientes de segurança, proteção patrimonial, indústria, saúde e transporte. Alarmes falsos, alarmes perdidos, prioridade incorreta ou descrições pouco claras podem afetar a qualidade da resposta.

Backup e recuperação

Muitos sistemas exigem backup de configuração, backup de banco de dados, retenção de logs, alimentação redundante, servidores de failover, dispositivos sobressalentes ou procedimentos de recuperação. O SAT pode verificar se os processos de backup e restauração funcionam como prometido.

Essa parte costuma ser negligenciada porque o sistema parece normal durante a entrega. No entanto, a capacidade de recuperação se torna crítica quando ocorre uma falha, interrupção de energia, substituição de hardware ou corrupção de software.

Benefícios para proprietários de projetos e fornecedores

Reduz o risco de entrega

O SAT reduz a chance de aceitar um sistema incompleto ou instável. Os proprietários do projeto podem confirmar que as funções exigidas foram demonstradas e registradas antes da aprovação final.

Para os fornecedores, o SAT cria uma base clara para a entrega. Em vez de depender de confirmação verbal, a equipe pode fornecer registros de teste, listas de pendências, ações corretivas e assinaturas de aceitação.

Encontra cedo problemas específicos do local

Alguns problemas aparecem apenas depois que o sistema é instalado no local real. Eles podem incluir restrições de rede, falhas de cabo, capacidade de energia insuficiente, sistemas de terceiros incompatíveis, cabeamento de campo incorreto, interferência ambiental ou incompatibilidade com o fluxo de trabalho do operador.

Encontrar esses problemas durante o SAT é melhor do que descobri-los depois que o sistema entrou na operação diária.

Melhora a comunicação entre equipes

Os testes de aceitação reúnem proprietários do projeto, fornecedores, integradores, instaladores, operadores, equipes de TI, equipes de segurança e equipe de manutenção. Esse processo compartilhado ajuda a esclarecer expectativas e responsabilidades.

Quando um teste falha, a equipe pode identificar se o problema pertence à configuração, instalação, projeto, infraestrutura do local, interface de terceiros ou treinamento de usuários. Isso reduz acusações e melhora a resolução de problemas.

Apoia documentação e conformidade

Registros de teste, relatórios, checklists, arquivos de configuração, desenhos e formulários de aceitação passam a fazer parte da documentação do projeto. Esses registros podem apoiar auditorias, solicitações de garantia, manutenção futura, inspeções regulatórias e expansão do sistema.

Em ambientes regulados, a aceitação documentada pode ser tão importante quanto o próprio teste. Ela comprova que o sistema foi verificado contra requisitos definidos na entrega.

Cria uma linha de base para manutenção

Após a aceitação, os resultados do SAT podem servir como linha de base. Se o sistema se comportar de forma diferente no futuro, as equipes de manutenção podem comparar o desempenho atual com o registro original de teste.

Isso é útil para solução de problemas, atualizações de versão, substituição de hardware, correções de software e expansões futuras.

Aplicações em diferentes projetos

Automação industrial

Projetos industriais usam SAT para verificar sistemas PLC, plataformas SCADA, sensores, inversores, gabinetes de controle, intertravamentos de segurança, alarmes, painéis de operador e funções de linha de produção. Os testes confirmam que o sistema funciona com dispositivos de campo reais e condições reais de processo.

Como falhas industriais podem afetar produção e segurança, o SAT deve incluir operação normal, condições anormais, controle manual, comportamento de parada de emergência, tratamento de alarmes e registro de dados.

Telecomunicações e sistemas de rede

Projetos de telecomunicações podem usar SAT para verificar servidores, gateways, plataformas IP PBX, roteadores, switches, sistemas de gravação, sistemas de despacho, troncos SIP, dispositivos de acesso e ferramentas de monitoramento. A equipe verifica conectividade, roteamento, qualidade, failover e funções de gerenciamento.

Sistemas baseados em rede devem ser testados com endereços IP reais, VLANs, regras de firewall, configurações QoS, políticas de acesso remoto e contas de usuário, e não apenas com configurações de laboratório.

Gerenciamento predial e segurança

Projetos prediais usam SAT para controle de acesso, CFTV, interfaces de alarme de incêndio, sonorização, interfones, elevadores, controles HVAC, controle de iluminação e plataformas de gestão integrada. O objetivo é verificar que subsistemas separados funcionem juntos.

A integração é especialmente importante. Por exemplo, um alarme de incêndio pode precisar acionar ao mesmo tempo a liberação de portas, a abertura de câmeras, a transmissão por sonorização e o registro do evento na sala de controle.

Sistemas de saúde e laboratório

Hospitais, clínicas, laboratórios e ambientes de sala limpa podem exigir SAT para sistemas de comunicação, dispositivos de monitoramento, controle de acesso, sistemas ambientais, infraestrutura de suporte médico e plataformas de dados.

Os testes devem considerar segurança, privacidade, precisão, rastreabilidade, funções de usuário e continuidade de serviço. Nesses ambientes, a qualidade da documentação costuma ser crítica.

Infraestrutura de energia e utilidades

Usinas de energia, subestações, instalações de tratamento de água, locais de petróleo e gás e projetos de energia renovável usam SAT para confirmar funções de monitoramento, controle, comunicação, segurança, medição e alarme.

Esses locais podem exigir verificações adicionais de redundância, aterramento, proteção contra surtos, condições ambientais, cibersegurança e procedimentos de resposta a emergências.

Problemas comuns encontrados durante os testes

Instalação incompleta

Algumas falhas são causadas por instalação inacabada, não por defeitos do produto. Cabos ausentes, etiquetas erradas, terminais soltos, aterramento não conectado, cabeamento de gabinete incompleto ou licenças ausentes podem impedir a aprovação do teste.

Uma verificação de prontidão pré-SAT ajuda a reduzir esses problemas antes do início do teste testemunhado pelo cliente.

Incompatibilidade de configuração

Erros de configuração são comuns. Endereços IP, permissões de usuário, limites de alarme, regras de roteamento, IDs de dispositivo, configurações de horário, conexões de banco de dados ou parâmetros de protocolo podem não corresponder ao projeto aprovado.

Esses erros muitas vezes podem ser corrigidos rapidamente, mas ainda devem ser registrados para que a configuração final seja rastreável.

Falha de interface

Interfaces de terceiros podem falhar devido a diferenças de protocolo, bloqueios de firewall, credenciais ausentes, incompatibilidade de versão, mapeamento de dados incorreto ou configuração incompleta de API.

Os testes de interface devem envolver os dois lados da conexão. Não basta que um sistema envie dados; o sistema receptor deve processá-los corretamente.

Critérios de aceitação pouco claros

Se o plano de teste não define as condições de aprovação e falha, podem ocorrer disputas. Uma parte pode considerar o sistema aceitável, enquanto outra espera um nível de desempenho maior ou um fluxo de trabalho diferente.

Critérios claros devem ser acordados antes do início do teste. Isso evita julgamentos subjetivos durante a entrega.

Treinamento inadequado de usuários

Às vezes o sistema funciona, mas os usuários não sabem como operá-lo. Isso pode parecer uma falha técnica durante a aceitação.

Treinamento, guias rápidos de referência e procedimentos operacionais baseados em função devem ser incluídos antes da entrega final.

Muitas falhas de SAT não são causadas por equipamentos quebrados. Elas vêm de instalação incompleta, escopo pouco claro, documentação fraca, planejamento de interface deficiente ou fluxos de trabalho reais não testados.

Boas práticas para uma entrega tranquila

Prepare o checklist com antecedência. O checklist de SAT não deve ser escrito no último minuto. Ele deve ser desenvolvido a partir dos requisitos contratuais, especificações técnicas, desenhos aprovados, fluxos de trabalho do usuário e pontos de risco do projeto.

Convide as pessoas certas. Os testes devem incluir representantes do fornecedor, instalador, cliente, equipe de usuários finais, departamento de TI, equipe de segurança e equipe de manutenção quando relevante. A ausência de partes interessadas pode atrasar a aceitação, porque verificações importantes podem precisar ser repetidas depois.

Registre evidências. Capturas de tela, fotos, logs, relatórios exportados, medições, registros de chamadas, registros de alarmes e formulários assinados ajudam a provar que um teste foi concluído.

Use uma lista de pendências. Se pequenos problemas permanecerem, registre-os claramente com responsável, prioridade, ação corretiva e data-alvo de conclusão. Isso permite que o projeto avance enquanto itens inacabados continuam sendo acompanhados.

Não ignore os testes negativos. Não basta provar que a operação normal funciona. O sistema também deve ser testado quanto a alarmes de falha, entrada inválida, interrupção de energia, perda de comunicação, failover e recuperação quando exigido.

O que deve ser incluído no relatório final

O relatório final deve incluir nome do projeto, escopo do sistema, data do teste, participantes, ambiente de teste, documentos de referência, resultados do checklist, itens aprovados, itens reprovados, ações corretivas, fotos ou logs, registros de configuração e assinaturas de aceitação.

Se existirem desvios, eles devem ser documentados. Um desvio pode ser aceito pelo cliente, corrigido antes da entrega ou adicionado a uma lista de pendências para conclusão posterior. O ponto importante é que ele não deve permanecer oculto ou ambíguo.

O relatório também deve incluir informações de versão. Versão de software, versão de firmware, versão de banco de dados, revisão de desenho e data do backup de configuração são úteis para manutenção futura.

FAQ

O SAT pode ser realizado antes de todo o trabalho no local estar completo?

Pode ser realizado parcialmente, mas a aceitação final normalmente deve esperar até que a instalação, o cabeamento, a configuração, as interfaces e as condições operacionais exigidas estejam prontos. Caso contrário, os resultados podem não refletir o sistema real.

Quem deve assinar o relatório de aceitação?

Os signatários dependem do projeto, mas geralmente incluem o fornecedor ou integrador, representante do cliente, gerente do projeto, responsável pelo usuário final e, às vezes, representantes de manutenção, segurança ou qualidade.

O que acontece se um item de teste falhar?

A falha deve ser registrada com a causa, parte responsável, ação corretiva, prioridade e requisito de reteste. Falhas críticas normalmente precisam ser corrigidas antes da aceitação, enquanto questões menores podem ser adicionadas a uma lista de pendências se o cliente concordar.

O SAT é necessário para projetos apenas de software?

Sim, pode ser. Software implantado em um local do cliente ou em ambiente de nuvem ainda pode precisar de testes de aceitação para configuração, funções de usuário, integrações, desempenho, segurança, relatórios e fluxos operacionais.

Quais documentos devem estar prontos antes do início dos testes?

Documentos úteis incluem a especificação técnica aprovada, desenhos do sistema, plano de rede, lista de I/O, folha de configuração, lista de contas de usuário, checklist de testes, manual de operação, guia de manutenção e relatório FAT anterior, se disponível.