Pruebas de aceptación del usuario en SAP: responsables y ejecución

Las pruebas de aceptación del usuario (UAT) en SAP son la fase en la que los usuarios de negocio ejecutan sus propios procesos en el sistema configurado y lo aceptan formalmente antes del go-live. El negocio es su responsable, TI y el socio de implementación la apoyan, y en un programa S/4HANA planifico al menos de 6 a 8 semanas para ella.

El fallo de pruebas más frecuente que veo es sencillo: probar demasiado poco en la UAT y en las pruebas de integración del sistema (SIT). Cuando el calendario se retrasa, esas dos fases se comprimen, y los huecos aparecen después del go-live.

A continuación: quién hace qué, la preparación, los guiones, la clasificación de defectos y una aprobación que signifique algo. Para ver dónde se ubica la UAT entre los demás tipos de prueba, empiece por mi visión general de las pruebas SAP explicadas.

El negocio es responsable de las pruebas de aceptación del usuario. Esa es mi posición, y no debería cambiar cuando el calendario se aprieta.

La razón está en el nombre. La aceptación es una decisión de negocio sobre si el sistema hace funcionar el negocio, así que solo pueden darla las personas que lo dirigen. Si TI o el socio aprueban la UAT, nadie ha aceptado nada.

La propia metodología de SAP dice lo mismo. Su orientación sobre la estrategia de pruebas para S/4HANA Cloud Private Edition sitúa la UAT en la fase Realize. Los expertos en configuración del socio preparan los casos de prueba manuales, y los expertos de las líneas de negocio del cliente los ejecutan y documentan los resultados.

Un reparto del trabajo que funciona es este:

Rol	Es responsable en la UAT de	No es responsable de
Responsables de proceso de negocio	Alcance de los escenarios, criterios de aceptación, aprobación final de su proceso	Corregir configuración o código
Usuarios clave y probadores	Ejecutar los guiones, registrar resultados y evidencias, comunicar hallazgos	Decidir por su cuenta que un defecto «no es un defecto»
Líder de la UAT (lado del negocio)	Plan diario, avance, presidencia de la clasificación, informes de preparación al patrocinador	Correcciones técnicas
Socio de implementación	Borradores de los guiones, preparación del sistema de pruebas, corrección de defectos, apoyo a las nuevas pruebas	Aceptación
TI interna	Entornos, accesos, interfaces con otros sistemas, transportes	Aceptación
Equipo de datos	Carga y refresco de los datos de prueba, apoyo a la conciliación	Diseño de los escenarios de negocio

El líder de la UAT debe venir del negocio, no del socio. Una UAT dirigida por el socio tiende a demostrar que la construcción funciona, que es una pregunta distinta de si el negocio puede operar con ella.

La UAT necesita al menos de 6 a 8 semanas. Con menos, el negocio prueba el camino feliz una sola vez, no tiene tiempo de volver a probar las correcciones y nunca llega a las excepciones, donde están los problemas reales.

Esas semanas solo sirven si la UAT empieza sobre un sistema estable. La orientación de SAP es que los procesos de negocio se prueban una vez configuradas las integraciones y migrados los datos del proceso. Eso significa que la SIT tiene que terminar antes, según unos criterios de salida acordados, y mi guía de la estrategia de pruebas de S/4HANA explica cómo se conectan esos ciclos.

Antes de que el primer probador inicie sesión, debe estar preparado lo siguiente:

1. Diseños de proceso aprobados. Los guiones se redactan a partir de ellos, así que diseños sin aprobar significan guiones inestables.
2. Criterios de entrada cumplidos y registrados. SIT completa, ningún defecto crítico abierto y el sistema de pruebas congelado salvo correcciones controladas.
3. Un sistema de pruebas que se parezca a producción. Configuración, interfaces, roles y autorizaciones tal como estarán en el go-live.
4. Datos de prueba realistas. Enmascarados, a nivel de producción, cargados y conciliados antes de empezar las pruebas. Mi guía de gestión de datos de prueba en SAP explica cómo.
5. Probadores liberados de su trabajo diario. Nómbrelos, acuerde sus horas con sus responsables y déjelo por escrito.
6. Probadores formados en el sistema nuevo. Un breve recorrido por las apps Fiori y las transacciones que van a usar, antes de la UAT y no durante.
7. Una sola herramienta de gestión de pruebas. Guiones, resultados, evidencias y defectos en un solo lugar, no en hojas de cálculo paralelas.

El punto 5 es donde la UAT suele fallar sin hacer ruido. Los probadores a los que se pide encajar la UAT alrededor del cierre mensual pondrán primero el cierre, y harán bien.

Un guion de UAT es un escenario de negocio, no una lista de transacciones. «Crear un pedido de cliente» prueba una pantalla. «Tomar un pedido de un cliente nuevo con bloqueo de crédito, liberarlo, entregarlo y facturarlo» prueba el negocio.

Construya los guiones a partir de los diseños de proceso aprobados y dé a cada uno un resultado esperado claro en términos de negocio. El probador debe poder decir si se supera o falla sin preguntar a un consultor.

Cubra cuatro tipos de escenario:

1. Flujos centrales. Los procesos diarios que mantienen el negocio en marcha, como order to cash, procure to pay y record to report.
2. Excepciones. Devoluciones, bloqueos de crédito, entregas parciales, cambios de precio, anulaciones y aprobaciones que se rechazan.
3. Cierre de periodo. Los pasos de cierre mensual y anual que el equipo de finanzas realmente ejecuta, en el orden en que los ejecuta.
4. Comprobaciones de roles. Cada probador trabaja con el rol que tendrá en el go-live, para que los huecos de autorización aparezcan ahora.

Deje que el socio redacte los borradores de los guiones y luego pida a los usuarios clave que los reescriban con su propio lenguaje. Si el negocio no puede seguir un guion sin ayuda, se escribió para el equipo de construcción.

En SAP Cloud ALM, los casos de prueba manuales parten de un proceso, y los planes de prueba los agrupan en ciclos. Los probadores marcan cada paso como superado o fallido, registran el resultado real y abren un defecto desde la ejecución de la prueba, lo que mantiene el vínculo entre guion y defecto.

En los programas que todavía usan SAP Solution Manager 7.2 para la gestión de pruebas, tenga en cuenta que su mantenimiento estándar termina a finales de 2027 (SAP Support). Planifique los programas nuevos en Cloud ALM.

No todos los hallazgos de la UAT son defectos. Tratarlos todos como defectos satura al socio, y tratarlos todos como solicitudes de cambio oculta fallos reales.

Celebre una reunión de clasificación cada día de la UAT. La preside el líder de la UAT del negocio, con los líderes funcionales del socio y un representante de TI, y cada hallazgo nuevo sale de la sala con un tipo, una gravedad y un responsable.

Una clasificación sencilla cubre la mayoría de los hallazgos:

Tipo de hallazgo	Qué significa	Quién actúa	Efecto en la aprobación
Defecto	El sistema no hace lo que dice el diseño aprobado	El socio corrige y el probador vuelve a probar	Los defectos críticos y altos bloquean la aprobación
Solicitud de cambio	Se cumplió el diseño, pero el negocio ahora quiere algo distinto	La autoridad de diseño decide, con costo y plazos	No bloquea, salvo que el negocio diga que el proceso no puede funcionar sin ello
Problema de datos	Datos maestros o transaccionales erróneos o ausentes	El equipo de datos corrige y el probador vuelve a probar	Bloquea si esos mismos datos van a pasar a producción
Problema de formación o de uso	El sistema funciona, pero el probador no sabía cómo usarlo	El líder de formación actualiza el material	No bloquea, pero alimenta el plan de formación
Problema de autorización	Al rol le falta acceso o tiene demasiado	El equipo de seguridad ajusta el rol	Bloquea para el rol afectado

Acuerde las definiciones de gravedad antes de que empiece la UAT, en términos de negocio. Un defecto crítico detiene un proceso sin alternativa. Uno alto tiene una alternativa que el negocio no puede sostener con volumen.

Vigile la columna de solicitudes de cambio. Una larga lista de solicitudes de cambio en la UAT suele significar que el negocio no participó como debía en el diseño, y eso hay que corregirlo antes de la siguiente ola.

La formación de SAP Activate establece que la fase Realize está completa cuando las pruebas de aceptación del usuario están completas y aprobadas. Haga de esa aprobación un documento, no un hilo de correos.

Cada responsable de proceso de negocio firma por su propio proceso. La aprobación debe registrar:

1. Qué se probó. Escenarios ejecutados, superados y fallidos, con las evidencias guardadas en la herramienta de pruebas.
2. Qué sigue abierto. Cada defecto abierto, con su gravedad, su responsable y su fecha objetivo.
3. Qué se aceptó con una alternativa. Cada caso con su nombre, junto con la alternativa que el negocio ha acordado aplicar.
4. Quién firmó y cuándo. Una persona con nombre por proceso, no un comité.

Redacte los criterios de salida antes de que empiece la UAT y no los cambie cuando lleguen los resultados. Si el negocio aun así quiere entrar en producción con huecos, regístrelo como una decisión firmada. Mi guía de quality gates en SAP explica cómo encaja esta puerta en las transiciones de fase.

La aprobación de la UAT no es la decisión de go-live. La alimenta.

El criterio de go-live en el que insisto es una lista de verificación de cutover extensa y acordada de antemano. La aprobación de la UAT es una línea de esa lista, junto a la conciliación de datos, la formación y el ensayo de cutover.

Después de la aprobación, proteja lo que se aceptó. Cada corrección y cada transporte desde ese momento hasta el go-live necesitan nuevas pruebas, y mi guía de pruebas de regresión en SAP explica cómo mantener eso bajo control.

No necesita un documento largo. Necesita un plan que responda siempre a las mismas preguntas, redactado antes de que empiece la UAT y firmado por el negocio.

Un esquema sencillo basta:

Sección	Qué contiene	Responsable
Alcance	Procesos, unidades organizativas y roles del alcance, y lo que queda explícitamente fuera	Responsables de proceso de negocio
Calendario	Fechas de inicio y fin, ciclos, ventanas para volver a probar, ejecuciones de cierre de periodo	Líder de la UAT
Equipo	Probadores por proceso, su liberación del trabajo diario, contactos de apoyo del socio y de TI	Líder de la UAT y responsables jerárquicos
Criterios de entrada	Salida de la SIT cumplida, sistema de pruebas congelado, datos cargados y conciliados, probadores formados	Líder de la UAT con el director del programa
Entorno y datos	Sistema de pruebas, interfaces del alcance, datos enmascarados a nivel de producción, plan de refresco	TI y equipo de datos
Guiones	Lista de escenarios por proceso, resultados esperados, vínculo con el diseño del proceso	El socio redacta, los usuarios clave aprueban
Proceso de defectos	Tipos de hallazgo, definiciones de gravedad, clasificación diaria, reglas para volver a probar	El líder de la UAT preside la clasificación
Informes	Avance diario, defectos abiertos por gravedad, bloqueos para el patrocinador	Líder de la UAT
Criterios de salida	Umbrales de defectos abiertos por gravedad, escenarios superados, alternativas acordadas	Responsables de proceso de negocio
Aprobación	Bloque de firma por responsable de proceso, lista de alternativas aceptadas	Responsables de proceso de negocio y patrocinador

Mantenga la misma plantilla en todas las olas. El segundo despliegue debe reutilizar los guiones y las lecciones de la primera ola, no empezar de cero.

Nombre este mes a su líder de UAT del lado del negocio y pida a cada responsable de proceso que proponga probadores con tiempo liberado. Después, incluya en el plan de 6 a 8 semanas de UAT tras la SIT y defiéndalas cuando el calendario se apriete.

Si su UAT la está dirigiendo el socio, o se sigue comprimiendo, ayudo a los programas a organizarla bien. Puede contactarme aquí.

¿Qué son las pruebas de aceptación del usuario en SAP?

Son la fase en la que los usuarios de negocio prueban el sistema SAP configurado frente a sus procesos reales y lo aceptan formalmente antes del go-live. En SAP Activate tienen lugar en la fase Realize, después de las pruebas de integración. Los usuarios clave ejecutan guiones de escenarios, registran resultados y comunican hallazgos, y los responsables de proceso dan la aprobación.

¿Quién es responsable de la UAT en un proyecto SAP?

El negocio: los responsables de proceso deciden el alcance y aprueban, y los usuarios clave ejecutan las pruebas. El socio de implementación redacta los guiones y corrige los defectos, y la TI interna proporciona entornos, accesos e interfaces. Ni TI ni el socio deben aceptar el sistema en nombre del negocio.

¿Cuánto debe durar la UAT de SAP?

Planifique al menos de 6 a 8 semanas en un programa S/4HANA. Eso deja tiempo para ejecutar los flujos centrales, las excepciones y los pasos de cierre de periodo, y después volver a probar las correcciones. Una UAT más corta suele probar el camino feliz una vez y encontrar el resto después del go-live.

¿Cuál es la diferencia entre SIT y UAT en SAP?

Las pruebas de integración del sistema (SIT) comprueban que los procesos y las interfaces funcionan juntos entre módulos y sistemas, y las ejecuta principalmente el equipo del proyecto. La UAT comprueba que el negocio puede ejecutar sus procesos en el sistema, y la ejecutan los usuarios de negocio. La SIT debe terminar antes de que empiece la UAT.

¿Qué debe incluir la aprobación de la UAT?

Los escenarios probados y sus resultados, cada defecto abierto con su responsable y su fecha, las alternativas que el negocio haya aceptado y una firma con nombre por responsable de proceso. Acuerde los criterios de salida antes de que empiece la UAT. Una aprobación con huecos debe ser una decisión de negocio registrada.

¿Se puede usar SAP Cloud ALM para la UAT?

Sí. SAP Cloud ALM admite casos de prueba manuales construidos a partir de procesos, planes de prueba para cada ciclo, registro paso a paso de superado o fallido y defectos abiertos desde la ejecución de la prueba. Según la orientación de SAP, los expertos del socio preparan los casos de prueba y los expertos de negocio del cliente los ejecutan y documentan allí los resultados.