Estrategia de pruebas de S/4HANA: ciclos, criterios y roles

Una estrategia de pruebas de S/4HANA decide qué ciclos de prueba ejecuta, en qué orden, quién es responsable de cada uno y qué evidencia le permite pasar de uno al siguiente. En mis programas abarca pruebas de integración del sistema (SIT) en rondas, pruebas de aceptación del usuario (UAT) en rondas y pruebas de regresión, cada una con criterios de entrada y salida escritos y una aprobación con nombre.

En los programas S/4HANA que planifico, las pruebas consumen cerca del 35 por ciento del esfuerzo del programa, así que la estrategia merece tanto cuidado como el plan de construcción.

Los tipos de prueba en sí están en mi guía de pruebas SAP explicadas. Este artículo es la capa de estrategia: ciclos, criterios, roles y el esquema del documento.

SAP Activate sitúa la mayor parte de las pruebas en Realize. El propio material de estrategia de pruebas de SAP para S/4HANA Cloud Private Edition trata las pruebas unitarias y de cadena como informales. Las pruebas de procesos de negocio completos, de integración, de migración de datos y de aceptación del usuario son formales y deben documentarse.

Esta es la secuencia que planifico en un programa S/4HANA:

Ciclos de prueba de S/4HANA

1. 01

   Unitarias y de cadena

   Los consultores prueban cada función configurada y cadenas cortas a medida que construyen.

2. 02

   Rondas de SIT

   Cadenas de procesos completas entre módulos, interfaces y datos migrados.

3. 03

   Rondas de UAT

   Los usuarios de negocio demuestran, ronda a ronda, que el sistema ejecuta sus procesos.

4. 04

   Regresión

   Volver a probar lo que ya se superó después de correcciones, transportes y versiones.

5. 05

   Conversiones de prueba y ensayo

   Ejecutar el cutover tal como se hará esa noche, contra la lista de verificación.

6. 06

   Go-live

   Entrar en producción solo cuando la lista de verificación de cutover acordada esté completa.

Pruebas unitarias y de cadena

Los consultores y desarrolladores prueban cada elemento de configuración y cada desarrollo a medida que lo construyen. Las pruebas de cadena encadenan unos pocos pasos, como un pedido de cliente hasta la entrega.

Informales en términos de SAP, pero no opcionales.

Pruebas de integración del sistema en rondas

La SIT prueba procesos de negocio completos entre módulos, interfaces y datos convertidos o cargados. La planifico en rondas y no como un único evento, para que los defectos corregidos tras una ronda se vuelvan a probar en la siguiente.

No tengo un número fijo de rondas de SIT. La cantidad depende del número de procesos, interfaces y entidades del alcance, y la estrategia debe decir cuántas rondas y por qué.

Pruebas de aceptación del usuario en rondas

En la UAT el negocio confirma que el sistema ejecuta sus procesos, con su propia gente y datos realistas. Como la SIT, la planifico en rondas, para que las correcciones de una ronda se vuelvan a probar en la siguiente.

La UAT necesita al menos de 6 a 8 semanas. Los probadores de negocio la hacen además de su trabajo habitual, y necesitan tiempo para más de una ronda. Mi guía de pruebas de aceptación del usuario en SAP trata en detalle los guiones, las rondas y la aprobación.

Pruebas de regresión

Cada corrección, transporte y versión puede romper algo que ya se había superado. Las pruebas de regresión vuelven a ejecutar los procesos importantes después de cada cambio, durante el programa y después del go-live.

El material de SAP sitúa la regresión principalmente en Run, después de las actualizaciones de versión, pero un programa la necesita antes. El enfoque, el análisis de impacto y la preparación del entorno están en mi guía de pruebas de regresión en SAP.

Conversiones de prueba y ensayo de cutover

En una conversión brownfield planifico tres conversiones de prueba antes del cutover. Cada una prueba la propia conversión, los tiempos y la conciliación, no solo los procesos.

El último ensayo debe ejecutarse como la noche real: la misma secuencia, las mismas personas, la misma lista de verificación. Mi cronograma y plan de proyecto de migración a S/4HANA muestra dónde se ubican estas ejecuciones en el plan.

La decisión de responsabilidad más importante: el negocio es responsable de las pruebas de aceptación del usuario. Ni el integrador de sistemas ni TI.

Un integrador puede preparar guiones y corregir defectos. Solo las personas que ejecutan su cierre financiero, su order-to-cash o su planta pueden confirmar que esos procesos funcionan.

La propia orientación de SAP va en la misma dirección. Los expertos en configuración del socio crean los casos de prueba, y los expertos de las líneas de negocio del cliente ejecutan la UAT y registran los resultados.

Así repartiría la responsabilidad entre los ciclos:

Ciclo	Responsable	Ejecuta	Aprueba
Unitarias y de cadena	Líder del equipo de construcción	Consultores y desarrolladores	Líderes funcionales y técnicos
Rondas de SIT	Gestor de pruebas	Consultores, con usuarios clave que se suman en las rondas posteriores	Gestor de pruebas y responsables de proceso
Rondas de UAT	El negocio, a través de responsables de proceso con nombre	Usuarios clave y probadores de negocio	Responsables de proceso y, después, el patrocinador
Regresión	Gestor de pruebas	Equipo de pruebas, con automatización donde el volumen lo justifique	Gestor de pruebas y comité de cambios
Conversiones de prueba y ensayo	Líder del cutover	Equipos técnico, de datos y funcional	Líder del cutover, líder de datos y patrocinador

Escriba en la estrategia los nombres, no los roles. «Responsable del proceso financiero» es un rol; una persona con nombre que ha aceptado firmar es un responsable.

Los criterios de entrada impiden que un ciclo empiece antes de poder tener éxito. Los criterios de salida impiden que termine porque lo dice el calendario.

Redacte ambos antes de que empiece Realize, mientras nadie está bajo la presión de una fecha límite. Mi guía de quality gates en SAP explica cómo estos criterios se convierten en puertas formales con un responsable que puede decir «no está listo».

La tabla siguiente es una orientación para adaptar, no un estándar para copiar. Fije los porcentajes y los límites de defectos con su patrocinador y regístrelos en la estrategia:

Ciclo	Criterios de entrada	Criterios de salida
Unitarias y de cadena	Diseño aprobado; configuración y desarrollo completos para los elementos que se prueban	Todos los elementos probados y documentados; defectos corregidos o registrados para la SIT
Ronda de SIT	Pruebas unitarias completas para los procesos del alcance; entorno de pruebas construido e interfaces conectadas; datos de prueba cargados; guiones revisados	Proporción acordada de guiones ejecutados y superados; ningún defecto crítico abierto; cada defecto menor abierto tiene responsable y fecha de corrección
Ronda de UAT	Criterios de salida de la SIT cumplidos; probadores de negocio nombrados y liberados de su trabajo diario; guiones revisados por los responsables de proceso; formación en el sistema de pruebas realizada	Cada proceso del alcance ejecutado por usuarios de negocio; ningún defecto crítico abierto; los responsables de proceso han firmado sus procesos
Regresión	Un cambio, un lote de correcciones o una versión listos para avanzar; paquete de regresión acordado para los procesos afectados	Paquete de regresión superado; cualquier fallo corregido y vuelto a probar antes de que el cambio avance
Conversión de prueba o ensayo	Copia de producción disponible; lista de verificación de cutover y run book en borrador; reglas de conciliación acordadas	Conversión o carga completada dentro de la ventana prevista; conciliación firmada por el líder de datos; lista de verificación actualizada con las lecciones aprendidas
Go-live	Todos los criterios de salida anteriores cumplidos; lista de verificación de cutover acordada de antemano	Cada punto de la lista completado y firmado; decisión de go o no-go registrada por el patrocinador

Dos reglas hacen que la tabla funcione. Cada criterio da una respuesta de sí o no, y cada salida tiene un firmante con nombre.

Si un ciclo no cumple sus criterios de salida y el negocio aun así quiere avanzar, conviértalo en una decisión escrita. Nombre a la persona que aceptó el riesgo y los defectos que se arrastran.

Lo redacta el gestor de pruebas en Prepare o al principio de Explore, y lo aprueba el patrocinador. Manténgalo lo bastante breve para que los responsables de proceso lo lean.

Estas son las secciones que espero ver:

1. Alcance y objetivos. Qué procesos, entidades, interfaces e informes se prueban y cuáles quedan explícitamente fuera.
2. Tipos de prueba y ciclos. Unitarias, de cadena, rondas de SIT, rondas de UAT, regresión, rendimiento, pruebas de migración de datos y conversiones de prueba, con el número de rondas y su justificación.
3. Calendario y esfuerzo. Fechas de cada ciclo dentro del plan de SAP Activate, con al menos de 6 a 8 semanas para la UAT, y el esfuerzo presupuestado frente a la proporción de pruebas de aproximadamente el 35 por ciento.
4. Roles y responsabilidades. La tabla de responsabilidades anterior, con nombres.
5. Criterios de entrada y salida. Un conjunto por ciclo, con el firmante de cada uno.
6. Entornos. Qué sistemas se usan en cada ciclo, cómo se refrescan y cómo se mantienen los cambios del proyecto separados de los del soporte en vivo.
7. Datos de prueba. De dónde vienen los datos, cómo se enmascaran y cómo se refrescan entre rondas. Mi guía de gestión de datos de prueba en SAP lo trata a fondo.
8. Gestión de defectos. Definiciones de gravedad, frecuencia de clasificación, quién decide la prioridad y el plazo objetivo de corrección por gravedad.
9. Herramientas. Dónde residen los casos de prueba, los resultados, los defectos y las aprobaciones, con un único sistema de registro.
10. Enfoque de automatización. Qué pruebas se automatizan, cuáles siguen siendo manuales y por qué.
11. Informes. Qué muestra el informe semanal de pruebas y quién lo recibe.
12. Criterios de cutover y go-live. La lista de verificación de cutover, los ensayos que la demuestran y quién toma la decisión de go o no-go.
13. Riesgos y supuestos. Disponibilidad de los probadores, fechas de los entornos, preparación de los datos y dependencias de terceros.

En cuanto a herramientas, SAP Cloud ALM es la opción por defecto para los programas nuevos. SAP indica que no hay una licencia separada para SAP Cloud ALM: está incluido con Enterprise Support, y sus aplicaciones de gestión de pruebas guardan los casos de prueba formales, las ejecuciones y los resultados.

SAP Solution Manager 7.2 sigue en uso en muchos programas, pero su mantenimiento estándar termina a finales de 2027. Para la automatización, SAP vende SAP Test Automation by Tricentis, que funciona con Cloud ALM; mi comparación de herramientas de pruebas SAP trata la elección más amplia.

El fallo de pruebas más frecuente que veo es probar demasiado poco en UAT y SIT.

Un mecanismo habitual: la construcción se retrasa, la fecha de go-live no se mueve y las semanas salen de los ciclos de prueba porque están al final del plan.

Estos son los patrones que lo causan y qué hacer con cada uno:

1. La SIT empieza antes de terminar las pruebas unitarias. La primera ronda de SIT se convierte en una ronda de pruebas unitarias. Mantenga los criterios de entrada.
2. La UAT se planifica para dos o tres semanas. Los usuarios de negocio no pueden probar bien en ese tiempo además de su trabajo diario. Planifique al menos de 6 a 8 semanas y libere a los probadores.
3. El integrador ejecuta la UAT en nombre del negocio. Los guiones se superan, y el negocio encuentra los huecos después del go-live. Mantenga la responsabilidad de la UAT en los responsables de proceso.
4. Las pruebas se presupuestan como una partida menor. Si suponen cerca del 35 por ciento del esfuerzo y se presupuestan en una fracción de eso, son lo primero que se recorta.
5. Los criterios de salida se redactan durante el ciclo. Acaban coincidiendo con lo que el equipo haya logrado. Redáctelos antes de Realize.
6. El go-live se decide por confianza, no por una lista de verificación. Nadie puede mostrar lo que se acordó, así que nadie puede decir qué falta.

En ese último punto es en el que insisto. Mi criterio de go-live es una lista de verificación de cutover extensa, acordada de antemano con el negocio, TI y el integrador.

Cubre los pasos técnicos, las cargas de datos, las conciliaciones, las validaciones de negocio, la conmutación de interfaces, el acceso de los usuarios y los puntos de go o no-go. Si un punto no está completo y firmado, el programa no está listo, diga lo que diga la fecha.

Antes de que empiece Realize, pida a su gestor de pruebas el documento de estrategia de pruebas y compárelo con el esquema anterior. Si no tiene un responsable de UAT con nombre, da a la UAT menos de 6 a 8 semanas o no tiene criterios de entrada y salida por ciclo, corrija eso primero.

Si quiere una revisión independiente de una estrategia de pruebas o de una lista de verificación de go-live, ayudo a las organizaciones con esto. Puede contactarme aquí.

¿Qué es una estrategia de pruebas de S/4HANA?

Es el plan que decide qué ciclos de prueba se ejecutan, en qué orden, quién es responsable de cada uno y lo aprueba, y qué evidencia permite al programa pasar de un ciclo al siguiente. En un programa S/4HANA suele abarcar pruebas unitarias y de cadena, rondas de SIT, rondas de UAT, regresión, pruebas de migración de datos y ensayos de cutover.

¿Qué parte de un programa S/4HANA son las pruebas?

En los programas que planifico, las pruebas consumen cerca del 35 por ciento del esfuerzo del programa. Presupuéstelas a ese nivel desde el principio, porque las pruebas con poca financiación son lo primero que se recorta cuando la construcción se retrasa.

¿Cuánto debe durar la UAT en un proyecto S/4HANA?

Al menos de 6 a 8 semanas. Los probadores de negocio ejecutan la UAT además de su trabajo habitual, y necesitan tiempo para más de una ronda, de modo que las correcciones de la primera se vuelvan a probar.

¿Quién debe ser responsable de las pruebas de aceptación del usuario en SAP?

El negocio, a través de responsables de proceso con nombre. El integrador de sistemas puede preparar guiones, gestionar el entorno y corregir defectos, pero solo las personas que ejecutan los procesos pueden confirmar que el sistema les funciona.

¿Qué son los criterios de entrada y salida en las pruebas SAP?

Los criterios de entrada son las condiciones que necesita un ciclo antes de empezar, como pruebas unitarias terminadas, un entorno construido y datos de prueba cargados. Los criterios de salida son las condiciones que debe cumplir antes de terminar, como guiones ejecutados, ningún defecto crítico abierto y la aprobación de los responsables de proceso. Cada uno debe dar una respuesta de sí o no y tener un firmante con nombre.

¿Qué debe incluir una lista de verificación de go-live de S/4HANA?

Los pasos técnicos del cutover, las cargas de datos y las conciliaciones, las validaciones de negocio, la conmutación de interfaces, el acceso de los usuarios y los puntos de decisión de go o no-go. Acuérdela de antemano, ensáyela en las conversiones de prueba o en el ensayo general y entre en producción solo cuando cada punto esté completo y firmado.