Site Acceptance Testing, comúnmente abreviado como SAT, es un proceso formal de verificación que se realiza después de instalar equipos, software, sistemas o soluciones integradas en el sitio del cliente. Su propósito es confirmar que el sistema entregado funciona correctamente en el entorno operativo real, cumple los requisitos del proyecto, se integra con los sistemas relacionados y está listo para la entrega, la operación o la aprobación final.

A diferencia de las pruebas de fábrica, que se realizan antes del envío o la implementación, el SAT se centra en las condiciones reales del sitio. La alimentación eléctrica, la conectividad de red, los factores ambientales, el cableado de campo, los permisos de usuario, las interfaces de terceros, las alarmas, la lógica de control, las funciones de seguridad, los flujos de trabajo del operador y la documentación se comprueban bajo las condiciones en las que el sistema se utilizará realmente.

Por qué importa la verificación final en el sitio del proyecto

Un sistema puede superar la inspección de fábrica y aun así fallar después de la instalación, porque el sitio real introduce variables que no pueden simularse por completo en la fábrica. Las longitudes de cable pueden ser distintas, las reglas de red pueden ser más estrictas, las salas de equipos pueden tener condiciones de puesta a tierra diferentes, los operadores pueden usar otros flujos de trabajo y los sistemas de terceros pueden responder de forma distinta a los simuladores de prueba.

El SAT ayuda a cerrar esta brecha. Proporciona una forma estructurada de verificar que la solución entregada no solo esté completa desde el punto de vista técnico, sino que también sea utilizable en la operación. Para los propietarios del proyecto, reduce el riesgo de aceptar un sistema que luego requiera correcciones repetidas. Para proveedores e integradores, crea un registro claro de lo que se probó, lo que pasó, lo que falló y lo que aún necesita seguimiento.

En proyectos complejos, el SAT también ayuda a gestionar responsabilidades. Permite distinguir entre defectos del equipo, problemas de instalación, errores de configuración, fallos de interfaz, documentos faltantes, brechas de capacitación de operadores y condiciones del sitio fuera del alcance original.

La diferencia entre pruebas de fábrica y pruebas en sitio

Factory Acceptance Testing, o FAT, se realiza normalmente antes de que el sistema sea enviado o entregado. Comprueba si el producto o sistema cumple los requisitos acordados en un entorno de prueba controlado. El proveedor puede simular entradas, salidas, enlaces de red, acciones del operador y condiciones de falla antes de la implementación.

El SAT ocurre más tarde, después de la instalación en la ubicación del proyecto. Comprueba si el mismo sistema funciona correctamente con la alimentación real, los dispositivos de campo reales, los enlaces de comunicación reales, la infraestructura del edificio, la red del cliente, los sistemas de seguridad, el flujo de trabajo de la sala de control y la operación del usuario final.

Ambas pruebas son valiosas. El FAT reduce la posibilidad de enviar un sistema incompleto o defectuoso. El SAT confirma que el sistema instalado funciona como parte del entorno real del cliente. Un proyecto que omite cualquiera de las dos etapas puede enfrentar un mayor riesgo durante la puesta en marcha.

Cómo suele desarrollarse el proceso de aceptación

Preparación y planificación de pruebas

El proceso comienza con un plan de pruebas. El plan define qué se probará, quién participará, qué documentos se requieren, qué herramientas se necesitan, qué criterios de aceptación se usarán y cómo se registrarán los resultados.

Un buen plan debe estar vinculado al contrato, la especificación técnica, los documentos de diseño, los planos aprobados, los requisitos de interfaz, los requisitos de seguridad y el alcance del proyecto. Sin criterios claros, el SAT puede convertirse en una demostración informal en lugar de un proceso de aceptación controlado.

Comprobación de preparación del sitio

Antes de que comience la prueba formal, el equipo verifica si el sitio está listo. Esto puede incluir disponibilidad de energía, puesta a tierra, acceso a la red, instalación de gabinetes, terminación de cables, condiciones ambientales, etiquetado de equipos, instalación de software, activación de licencias y arranque básico del sistema.

Si el sitio no está listo, las pruebas formales de aceptación pueden producir fallos engañosos. Por ejemplo, una plataforma de comunicación puede parecer defectuosa cuando el problema real es una regla de firewall bloqueada o un cableado incompleto.

Pruebas funcionales

Las pruebas funcionales confirman que cada función requerida opera de acuerdo con la especificación del proyecto. Esto puede incluir operación normal, inicio de sesión de usuarios, control de dispositivos, activación de alarmas, enrutamiento de llamadas, visualización de datos, generación de informes, entrada de señales, control de salidas, grabación, notificación y acciones del operador.

Las pruebas funcionales deben redactarse en un lenguaje práctico. Cada prueba debe describir la acción, el resultado esperado, la condición de aprobación o fallo y la evidencia requerida. Esto facilita la verificación del resultado y su auditoría posterior.

Pruebas de integración

Muchos sistemas dependen de otros sistemas. Una plataforma de edificio puede conectarse con alarmas contra incendio, control de acceso, CCTV, megafonía, ascensores, HVAC, switches de red, bases de datos o software de terceros. El SAT debe verificar estas interfaces bajo condiciones reales.

Las pruebas de integración suelen revelar problemas ocultos. El sistema principal puede funcionar solo y el sistema de terceros también puede funcionar solo, pero la interfaz entre ambos puede fallar por incompatibilidad de protocolo, retardo de temporización, error de dirección, problema de permisos o diferencia en el formato de datos.

Comprobaciones de rendimiento y fiabilidad

Según el proyecto, el SAT también puede incluir pruebas de rendimiento. Esto puede abarcar tiempo de respuesta, calidad de llamada, rendimiento de datos, tasa de actualización, retardo de alarmas, comportamiento de conmutación por error, manejo de carga, calidad de grabación, latencia de red o recuperación del sistema después de un reinicio.

Las comprobaciones de fiabilidad son importantes para sistemas que respaldan seguridad, producción, comunicación, energía, transporte, atención sanitaria, protección o servicios públicos. El sistema no debe funcionar solo una vez durante una demostración; debe funcionar de manera constante bajo las condiciones operativas esperadas.

El SAT no es un paso ceremonial final. Es la prueba práctica de que el sistema entregado puede operar en el entorno real del cliente con usuarios reales, interfaces reales y restricciones reales.

Elementos típicos incluidos en una lista de verificación

Calidad de instalación

El equipo verifica si los equipos se han instalado conforme a los planos aprobados, las normas del sitio, las reglas de seguridad y los requisitos del fabricante. Pueden revisarse el montaje de gabinetes, el tendido de cables, el etiquetado, la puesta a tierra, la ventilación, la protección de conectores y el acceso físico.

La calidad de instalación importa porque un sistema puede pasar las pruebas de software y aun así tener riesgos futuros de fiabilidad causados por cables flojos, etiquetado deficiente, mala puesta a tierra, flujo de aire bloqueado o montaje inseguro.

Revisión de configuración y parámetros

Las comprobaciones de configuración confirman que los ajustes del sistema coinciden con el diseño del proyecto. Pueden incluir direcciones IP, roles de usuario, números de extensión, umbrales de alarma, reglas de enrutamiento, nombres de dispositivos, zonas horarias, políticas de grabación, rutas de almacenamiento, permisos de acceso y programas de copia de seguridad.

La configuración debe documentarse. Si más adelante el sistema necesita sustitución, recuperación o ampliación, los ajustes no documentados pueden dificultar el mantenimiento.

Operación del usuario

El SAT debe verificar si el sistema funciona para las personas que realmente lo utilizarán. Los operadores pueden necesitar iniciar sesión, ver estados, reconocer alarmas, realizar llamadas, controlar dispositivos, exportar registros, generar informes, cambiar modos o seguir flujos de emergencia.

Esta etapa suele revelar brechas de usabilidad. Una función puede existir técnicamente, pero si es difícil de encontrar, está mal etiquetada o no coincide con el flujo de trabajo del cliente, puede requerirse capacitación adicional o ajuste de la interfaz.

Gestión de alarmas y fallas

El comportamiento ante fallas y alarmas debe probarse con cuidado. El sistema debe detectar el evento correcto, mostrar el mensaje correcto, activar la notificación esperada, almacenar el registro del evento y volver a la normalidad cuando se elimine la falla.

Las pruebas de alarmas son especialmente importantes en entornos de seguridad, protección, industria, atención sanitaria y transporte. Falsas alarmas, alarmas omitidas, prioridades incorrectas o descripciones poco claras pueden afectar la calidad de la respuesta.

Respaldo y recuperación

Muchos sistemas requieren respaldo de configuración, respaldo de bases de datos, retención de registros, alimentación redundante, servidores de conmutación por error, dispositivos de repuesto o procedimientos de recuperación. El SAT puede verificar si los procesos de respaldo y restauración funcionan según lo prometido.

Esta parte suele pasarse por alto porque el sistema parece normal durante la entrega. Sin embargo, la capacidad de recuperación se vuelve crítica cuando ocurre una falla, interrupción eléctrica, sustitución de hardware o corrupción de software.

Beneficios para propietarios de proyectos y proveedores

Reduce el riesgo de entrega

El SAT reduce la posibilidad de aceptar un sistema incompleto o inestable. Los propietarios del proyecto pueden confirmar que las funciones requeridas se han demostrado y registrado antes de la firma final.

Para los proveedores, el SAT crea una base clara para la entrega. En lugar de depender de confirmaciones verbales, el equipo puede proporcionar registros de prueba, listas de pendientes, acciones correctivas y firmas de aceptación.

Detecta temprano problemas específicos del sitio

Algunos problemas solo aparecen después de instalar el sistema en la ubicación real. Pueden incluir restricciones de red, fallas de cableado, capacidad de energía insuficiente, sistemas de terceros incompatibles, cableado de campo incorrecto, interferencias ambientales o desajustes en el flujo de trabajo del operador.

Encontrar estos problemas durante el SAT es mejor que descubrirlos después de que el sistema haya entrado en operación diaria.

Mejora la comunicación entre equipos

Las pruebas de aceptación reúnen a propietarios del proyecto, proveedores, integradores, instaladores, operadores, equipos de TI, equipos de seguridad y personal de mantenimiento. Este proceso compartido ayuda a aclarar expectativas y responsabilidades.

Cuando una prueba falla, el equipo puede identificar si el problema pertenece a configuración, instalación, diseño, infraestructura del sitio, interfaz de terceros o capacitación del usuario. Esto reduce la culpa cruzada y mejora la resolución de problemas.

Apoya la documentación y el cumplimiento

Los registros de prueba, informes, listas de verificación, archivos de configuración, planos y formularios de aceptación pasan a formar parte de la documentación del proyecto. Estos registros pueden respaldar auditorías, reclamaciones de garantía, mantenimiento futuro, inspecciones regulatorias y ampliaciones del sistema.

En entornos regulados, la aceptación documentada puede ser tan importante como la prueba en sí. Demuestra que el sistema fue comprobado contra requisitos definidos durante la entrega.

Crea una línea base para mantenimiento

Después de la aceptación, los resultados del SAT pueden servir como línea base. Si el sistema se comporta de manera distinta más adelante, los equipos de mantenimiento pueden comparar el rendimiento actual con el registro original de prueba.

Esto resulta útil para resolución de fallas, actualizaciones de versión, sustitución de hardware, parches de software y futuras ampliaciones.

Aplicaciones en distintos proyectos

Automatización industrial

Los proyectos industriales usan SAT para verificar sistemas PLC, plataformas SCADA, sensores, variadores, gabinetes de control, enclavamientos de seguridad, alarmas, paneles de operador y funciones de línea de producción. Las pruebas confirman que el sistema funciona con dispositivos de campo reales y condiciones reales del proceso.

Como las fallas industriales pueden afectar la producción y la seguridad, el SAT debe incluir operación normal, condiciones anormales, control manual, comportamiento de parada de emergencia, gestión de alarmas y registro de datos.

Telecomunicaciones y sistemas de red

Los proyectos de telecomunicaciones pueden usar SAT para verificar servidores, gateways, plataformas IP PBX, routers, switches, sistemas de grabación, sistemas de despacho, troncales SIP, dispositivos de acceso y herramientas de monitoreo. El equipo comprueba conectividad, enrutamiento, calidad, conmutación por error y funciones de gestión.

Los sistemas basados en red deben probarse con direcciones IP reales, VLAN, reglas de firewall, configuraciones QoS, políticas de acceso remoto y cuentas de usuario, no solo con ajustes de laboratorio.

Gestión de edificios y seguridad

Los proyectos de edificios utilizan SAT para control de acceso, CCTV, interfaces de alarma contra incendio, megafonía, intercomunicadores, ascensores, controles HVAC, control de iluminación y plataformas de gestión integrada. El objetivo es verificar que los subsistemas separados funcionen juntos.

La integración es especialmente importante. Por ejemplo, una alarma de incendio puede necesitar activar al mismo tiempo la liberación de puertas, la visualización de cámaras, un anuncio por megafonía y el registro del evento en la sala de control.

Sistemas sanitarios y de laboratorio

Hospitales, clínicas, laboratorios y entornos de sala limpia pueden requerir SAT para sistemas de comunicación, dispositivos de monitoreo, control de acceso, sistemas ambientales, infraestructura de soporte médico y plataformas de datos.

Las pruebas deben considerar seguridad, privacidad, precisión, trazabilidad, roles de usuario y continuidad del servicio. En estos entornos, la calidad de la documentación suele ser crítica.

Infraestructura energética y de servicios públicos

Centrales eléctricas, subestaciones, plantas de tratamiento de agua, sitios de petróleo y gas y proyectos de energía renovable usan SAT para confirmar funciones de monitoreo, control, comunicación, seguridad, medición y alarmas.

Estos sitios pueden requerir comprobaciones adicionales de redundancia, puesta a tierra, protección contra sobretensiones, condiciones ambientales, ciberseguridad y procedimientos de respuesta ante emergencias.

Problemas comunes encontrados durante las pruebas

Instalación incompleta

Algunas fallas se deben a una instalación inacabada y no a defectos del producto. Cables faltantes, etiquetas incorrectas, terminales flojos, puesta a tierra sin conectar, cableado de gabinete incompleto o licencias faltantes pueden impedir que la prueba pase.

Una comprobación de preparación previa al SAT ayuda a reducir estos problemas antes de que comience la prueba presenciada por el cliente.

Desajuste de configuración

Los errores de configuración son comunes. Direcciones IP, permisos de usuario, umbrales de alarma, reglas de enrutamiento, ID de dispositivos, ajustes de hora, conexiones de base de datos o parámetros de protocolo pueden no coincidir con el diseño aprobado.

Estos errores a menudo pueden corregirse rápidamente, pero aun así deben registrarse para que la configuración final sea trazable.

Falla de interfaz

Las interfaces de terceros pueden fallar por diferencias de protocolo, bloqueos de firewall, credenciales faltantes, incompatibilidad de versiones, mapeo de datos incorrecto o configuración incompleta de API.

Las pruebas de interfaz deben involucrar a ambos lados de la conexión. No basta con que un sistema envíe datos; el sistema receptor debe procesarlos correctamente.

Criterios de aceptación poco claros

Si el plan de prueba no define las condiciones de aprobación y fallo, pueden surgir disputas. Una parte puede considerar aceptable el sistema, mientras que otra espera un nivel de rendimiento más alto o un flujo de trabajo diferente.

Los criterios claros deben acordarse antes de que comience la prueba. Esto evita juicios subjetivos durante la entrega.

Capacitación deficiente del usuario

A veces el sistema funciona, pero los usuarios no saben cómo operarlo. Esto puede parecer una falla técnica durante la aceptación.

La capacitación, las guías rápidas de referencia y los procedimientos operativos basados en roles deben incluirse antes de la entrega final.

Muchas fallas de SAT no se deben a equipos dañados. Provienen de instalación incompleta, alcance poco claro, documentación débil, mala planificación de interfaces o flujos de trabajo reales no probados.

Buenas prácticas para una entrega fluida

Prepare la lista de verificación con anticipación. La lista de SAT no debe redactarse en el último minuto. Debe desarrollarse a partir de los requisitos del contrato, las especificaciones técnicas, los planos aprobados, los flujos de trabajo del usuario y los puntos de riesgo del proyecto.

Invite a las personas correctas. Las pruebas deben incluir representantes del proveedor, instalador, cliente, equipo de usuarios finales, departamento de TI, equipo de seguridad y equipo de mantenimiento cuando corresponda. La ausencia de partes interesadas puede retrasar la aceptación porque algunos controles importantes quizá deban repetirse más tarde.

Registre evidencia. Capturas de pantalla, fotos, registros, informes exportados, mediciones, registros de llamadas, registros de alarmas y formularios firmados ayudan a demostrar que una prueba se completó.

Use una lista de pendientes. Si quedan problemas menores, regístrelos con claridad indicando responsable, prioridad, acción correctiva y fecha objetivo de finalización. Esto permite que el proyecto avance sin perder el control de los elementos no terminados.

No ignore las pruebas negativas. No basta con demostrar que la operación normal funciona. Cuando se requiera, el sistema también debe probarse frente a alarmas de falla, entradas inválidas, interrupción de energía, pérdida de comunicación, conmutación por error y recuperación.

Qué debe incluir el informe final

El informe final debe incluir nombre del proyecto, alcance del sistema, fecha de prueba, participantes, entorno de prueba, documentos de referencia, resultados de la lista de verificación, elementos aprobados, elementos fallidos, acciones correctivas, fotos o registros, registros de configuración y firmas de aceptación.

Si existen desviaciones, deben documentarse. Una desviación puede ser aceptada por el cliente, corregida antes de la entrega o añadida a una lista de pendientes para completarse más tarde. Lo importante es que no permanezca oculta ni ambigua.

El informe también debe incluir información de versiones. Versión de software, versión de firmware, versión de base de datos, revisión de planos y fecha de respaldo de configuración son datos útiles para el mantenimiento futuro.

FAQ

¿Puede realizarse el SAT antes de que todo el trabajo del sitio esté completo?

Puede realizarse parcialmente, pero la aceptación final normalmente debe esperar hasta que la instalación, el cableado, la configuración, las interfaces y las condiciones operativas requeridas estén listos. De lo contrario, los resultados pueden no reflejar el sistema real.

¿Quién debe firmar el informe de aceptación?

Los firmantes dependen del proyecto, pero suelen incluir al proveedor o integrador, el representante del cliente, el gerente del proyecto, el responsable del usuario final y, a veces, representantes de mantenimiento, seguridad o calidad.

¿Qué ocurre si un elemento de prueba falla?

La falla debe registrarse con la causa, la parte responsable, la acción correctiva, la prioridad y el requisito de repetición de prueba. Las fallas críticas normalmente deben corregirse antes de la aceptación, mientras que los problemas menores pueden añadirse a una lista de pendientes si el cliente está de acuerdo.

¿Se requiere SAT para proyectos solo de software?

Sí, puede requerirse. El software desplegado en un sitio del cliente o en un entorno cloud puede necesitar pruebas de aceptación para configuración, roles de usuario, integraciones, rendimiento, seguridad, informes y flujos operativos.

¿Qué documentos deben estar listos antes de iniciar las pruebas?

Los documentos útiles incluyen la especificación técnica aprobada, planos del sistema, plan de red, lista de I/O, hoja de configuración, lista de cuentas de usuario, lista de verificación de pruebas, manual de operación, guía de mantenimiento e informe FAT previo si está disponible.