Pruebas SAP explicadas: tipos, fases y responsables

Las pruebas SAP son el trabajo de demostrar que un sistema SAP configurado ejecuta correctamente sus procesos de negocio, con sus datos y con sus volúmenes, antes de entrar en producción y cada vez que cambia después. En un programa S/4HANA abarcan seis tipos de prueba: unitarias, de integración del sistema (SIT), de aceptación del usuario (UAT), de regresión, de rendimiento y el ensayo de cutover.

Cada tipo responde a una pregunta distinta y ninguno sustituye a otro. En mi experiencia, las pruebas consumen cerca del 35 por ciento del esfuerzo del programa. Por eso merecen su propio plan, presupuesto y responsables, no unas pocas semanas al final de la construcción.

Esta página es la visión general. Cada tipo tiene su propia guía, enlazada desde las secciones siguientes.

Un sistema SAP es configuración, datos maestros, código a medida e interfaces funcionando juntos. Un cambio en un punto puede romper un proceso en otro lugar, a menudo en un módulo que nadie tocó.

Por eso las pruebas SAP se organizan en torno a procesos de negocio y no a pantallas. Order to cash, procure to pay y record to report atraviesan varios módulos, y una prueba que se detiene en una sola transacción demuestra muy poco.

Las pruebas tampoco terminan en el go-live. Los cambios de soporte, las versiones de SAP y los nuevos despliegues modifican el sistema, así que la misma disciplina continúa en la fase Run.

Estos son los seis tipos que planifico en un programa S/4HANA. La tabla muestra qué demuestra cada uno, cuándo se ejecuta y quién debe ser responsable.

Tipo de prueba	Qué demuestra	Dónde se ubica en SAP Activate	Quién es responsable
Pruebas unitarias	Cada elemento de configuración, programa o ampliación funciona por sí solo	Realize, dentro de cada sprint de construcción	Consultores funcionales y técnicos
Pruebas de integración del sistema (SIT)	Los procesos completos funcionan entre módulos e interfaces con datos realistas	Realize, en rondas una vez que la construcción es estable	Líder de pruebas del programa, con los responsables de proceso
Pruebas de aceptación del usuario (UAT)	El negocio puede ejecutar sus escenarios reales en el sistema	Final de Realize, antes de Deploy	El negocio
Pruebas de regresión	Lo que funcionaba antes sigue funcionando después de un cambio	De Realize en adelante, y luego en cada versión durante Run	Líder de pruebas, con automatización donde el volumen lo justifique
Pruebas de rendimiento	El sistema aguanta muchos usuarios y volúmenes de producción a la vez	Realize, terminadas antes del go-live	Líder de rendimiento a nivel de programa, con Basis
Ensayo de cutover	La secuencia del go-live, las cargas de datos y los tiempos funcionan de principio a fin	Deploy	Responsable del cutover

Pruebas SAP a lo largo de SAP Activate

1. 01

   Prepare

   Prepare la herramienta de pruebas, el equipo y el entorno de pruebas.

2. 02

   Explore

   Redacte la estrategia de pruebas mientras se toman las decisiones de fit-to-standard, para que los requisitos se puedan probar.

3. 03

   Realize

   Pruebas unitarias en los sprints y, cuando la construcción es estable, rondas de SIT, pruebas de rendimiento y UAT.

4. 04

   Deploy

   Ensayos de cutover contra una lista de verificación acordada y, después, la decisión de go-live.

5. 05

   Run

   Pruebas de regresión para cada cambio de soporte, actualización y versión.

Pruebas unitarias

Las pruebas unitarias las hacen quienes construyeron el elemento. Un consultor funcional comprueba una condición de precio; un desarrollador comprueba una ampliación o el mapeo de una interfaz.

Son necesarias, pero no suficientes. Una prueba unitaria limpia no dice nada de lo que ocurre cuando ese elemento se encuentra con el resto del proceso.

Pruebas de integración del sistema

En la SIT el programa descubre si el diseño funciona. Un pedido de cliente tiene que fluir hacia la entrega, la facturación, la contabilidad y los informes, y cada interfaz del camino tiene que contabilizar correctamente.

Planifico la SIT en rondas, no en una sola pasada. Los defectos de la primera ronda se corrigen, y la siguiente demuestra que las correcciones no rompieron nada más. Cómo encajan las rondas y los criterios de entrada y de salida está en mi guía de estrategia de pruebas de S/4HANA.

Pruebas de aceptación del usuario

La UAT es el negocio confirmando que el sistema respalda la forma en que trabajará después del go-live. Pertenece al negocio, no al integrador de sistemas, porque solo el negocio puede aceptar el sistema.

La UAT necesita al menos de 6 a 8 semanas. Si la comprime para compensar una construcción tardía, obtendrá una aprobación en papel y problemas en producción. Mi guía de pruebas de aceptación del usuario en SAP trata los guiones, los roles y la aprobación.

Pruebas de regresión

Las pruebas de regresión vuelven a ejecutar pruebas ya superadas después de un cambio, para detectar lo que ese cambio haya roto. En un programa largo, las correcciones del soporte en vivo y los cambios del proyecto pasan por el sistema al mismo tiempo.

Mi enfoque es mantener dos entornos separados, uno para el proyecto y otro para la operación diaria (BAU). Así los cambios del soporte en vivo y los del proyecto se prueban por separado, y ninguno oculta un defecto del otro. Mi guía de pruebas de regresión en SAP trata el enfoque de dos entornos, las actualizaciones y el análisis de impacto.

Pruebas de rendimiento

Las pruebas de rendimiento tienen que hacerse antes del go-live. Las que más importan son las de concurrencia, con muchos usuarios ejecutando transacciones en el mismo momento.

Una transacción correcta para un usuario puede agotar el tiempo de espera con doscientos. Las pruebas funcionales nunca le mostrarán eso. Mi guía para líderes de TI sobre pruebas de rendimiento en SAP trata las pruebas de carga, de estrés y de resistencia, y cómo redactar los criterios de aceptación.

Ensayo de cutover

El ensayo de cutover prueba el propio go-live: la secuencia de pasos técnicos, las cargas de datos, las conciliaciones y las aprobaciones, con sus tiempos. En una conversión brownfield planifico tres conversiones de prueba antes del cutover.

El criterio de go-live en el que insisto es una lista de verificación de cutover extensa y acordada de antemano. Si la lista se redacta durante el fin de semana del cutover, los ensayos no fueron realmente ensayos.

En mi experiencia, las pruebas consumen cerca del 35 por ciento del esfuerzo del programa. Esa cifra sorprende a los patrocinadores que ven las pruebas como el breve intervalo entre la construcción y el go-live.

El esfuerzo se reparte entre muchas personas. Los consultores ejecutan las pruebas unitarias, un equipo de pruebas prepara y ejecuta la SIT, los usuarios de negocio ejecutan la UAT, y los equipos de Basis y de integración apoyan las pruebas de rendimiento y los ensayos de cutover.

La migración de datos corre en paralelo y consume por sí sola entre el 30 y el 40 por ciento del esfuerzo. Ambas se solapan mucho, porque cada ronda de pruebas necesita datos migrados que se parezcan a producción.

El fallo de pruebas más frecuente que veo es, sencillamente, probar demasiado poco en SIT y UAT. Las rondas se recortan cuando la construcción se retrasa y la fecha de go-live no se mueve. En los 21 programas SAP que he dirigido o rescatado, el mayor error sigue siendo no planificar bien desde el principio, y las pruebas suelen ser donde eso se nota primero.

Las pruebas valen lo que valen los datos con los que se ejecutan. Mi regla es datos enmascarados, pero a nivel de producción: volúmenes a escala de producción y registros realistas, con los campos personales y sensibles enmascarados.

Unos datos de prueba pequeños y limpios ocultan los problemas que importan. Un informe que tarda segundos con unos pocos miles de registros puede tardar horas con un año completo de contabilizaciones.

El entorno importa tanto como los datos. Planifique el entorno de pruebas en Prepare, decida cómo se refresca entre rondas y mantenga separados los cambios del proyecto y los de BAU. Mi guía de gestión de datos de prueba en SAP trata las copias, el enmascaramiento y los datos de prueba selectivos.

Mi regla sobre la automatización es sencilla. Cuando hay un gran número de casos de prueba que exigen pruebas extensas y repetidas, automatice. Por debajo de eso, las pruebas manuales están bien.

La regresión es donde la automatización suele rendir primero, porque las mismas pruebas se ejecutan después de cada cambio. La UAT sigue siendo en gran parte manual, porque su propósito es el criterio de un usuario de negocio, no el de un guion.

Hay una razón práctica para decidirlo pronto. Las pruebas automatizadas llevan tiempo construirlas y mantenerlas, así que solo se amortizan cuando se ejecutan muchas veces. Mi guía de automatización de pruebas SAP trata por dónde empezar y cuándo compensa.

Las herramientas se dividen en tres grupos: gestión de pruebas, automatización funcional y pruebas de rendimiento. Los equipos que he dirigido o con los que he trabajado han usado Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath y LoadRunner.

Esto es lo que hace cada grupo, con sus productos:

Grupo de herramientas	Qué hace	Productos que los equipos usan con frecuencia
Gestión de pruebas	Planes de prueba, casos de prueba, registros de ejecución, defectos y trazabilidad hasta los requisitos	SAP Cloud ALM, SAP Solution Manager, Panaya
Automatización de pruebas funcionales	Ejecuta pruebas con guion o basadas en modelos en aplicaciones SAP y no SAP	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Pruebas de rendimiento	Simula muchos usuarios concurrentes y volúmenes de producción	OpenText LoadRunner, que ahora se vende como OpenText Professional Performance Engineering

Conviene conocer algunos datos de producto antes de elegir.

1. SAP Cloud ALM está incluido para los clientes con SAP Enterprise Support o con una suscripción en la nube que incluya Enterprise Support, cloud editions (SAP Support). Su gestión de pruebas cubre la preparación de pruebas, los planes de prueba y la ejecución, incluidos casos de prueba manuales para la UAT (SAP Learning).
2. El mantenimiento estándar de SAP Solution Manager 7.2 termina a finales de 2027, con un mantenimiento extendido opcional hasta finales de 2030 para un subconjunto de funciones, entre ellas el conjunto de pruebas (SAP Support).
3. SAP Test Automation by Tricentis es el producto de automatización que SAP revende, integrado con SAP Cloud ALM y diseñado para sistemas SAP y de terceros (SAP).
4. LoadRunner es un producto de OpenText. LoadRunner Professional se llama ahora OpenText Professional Performance Engineering y admite los protocolos SAP GUI y SAP Web (OpenText).

Si va a iniciar un programa nuevo, planifique la gestión de pruebas en Cloud ALM y no en Solution Manager. Para una comparación más detallada, lea mi guía de herramientas de pruebas SAP.

En SAP Cloud ERP public edition (S/4HANA Cloud Public Edition), SAP actualiza a todos los clientes según su propio calendario. SAP Learning describe actualizaciones cada seis meses, actualmente en febrero y agosto, con nuevas funciones entregadas mensualmente entre una y otra (SAP Learning).

Usted no elige la fecha de actualización, así que las pruebas de regresión pasan a ser una cita fija en el calendario y no un proyecto. Ese es el argumento más sólido para automatizar pronto la regresión en un sistema de nube pública.

En la nube privada y on-premise usted controla cuándo se actualiza. Cada actualización sigue necesitando un ciclo de regresión dimensionado según los procesos que toca el cambio.

Antes que nada, incluya las pruebas en el plan como un frente de trabajo con su propio responsable y presupuesto, dimensionado en cerca de un tercio del esfuerzo. Después, nombre al responsable de negocio de la UAT y reserve ahora de 6 a 8 semanas en el calendario, antes de que la construcción las comprima.

Vincule los resultados de las pruebas a sus decisiones de go/no-go con criterios de salida medibles. Mi guía de quality gates en SAP muestra cómo. Si su programa ya está en problemas, mis notas sobre recuperación de programas SAP explican qué corregir primero.

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

¿Qué son las pruebas SAP?

Las pruebas SAP demuestran que un sistema SAP configurado ejecuta correctamente sus procesos de negocio, con sus datos y con sus volúmenes. En un programa S/4HANA incluyen pruebas unitarias, pruebas de integración del sistema, pruebas de aceptación del usuario, pruebas de regresión, pruebas de rendimiento y el ensayo de cutover. Continúan después del go-live con cada cambio de soporte y cada versión.

¿Cuáles son los tipos de pruebas SAP?

Los seis tipos principales son las pruebas unitarias, las pruebas de integración del sistema (SIT), las pruebas de aceptación del usuario (UAT), las pruebas de regresión, las pruebas de rendimiento y el ensayo de cutover. Las pruebas unitarias comprueban elementos sueltos, la SIT comprueba procesos completos entre módulos e interfaces, y la UAT es el negocio aceptando el sistema. La regresión, el rendimiento y el ensayo de cutover protegen frente a los cambios, la carga y el propio go-live.

¿Cuánto duran las pruebas de aceptación del usuario en SAP?

Planifique al menos de 6 a 8 semanas para la UAT. El negocio debe ser su responsable, ejecutar sus escenarios reales y aprobarla. Probar demasiado poco en UAT y SIT es el fallo de pruebas más frecuente que veo.

¿Qué parte de un proyecto SAP son las pruebas?

En mi experiencia, las pruebas consumen cerca del 35 por ciento del esfuerzo del programa. Eso abarca preparar y ejecutar las pruebas unitarias, las rondas de SIT, la UAT, la regresión, las pruebas de rendimiento y los ensayos de cutover. La migración de datos corre en paralelo y necesita datos similares a los de producción para cada ronda de pruebas.

¿Se deben automatizar las pruebas SAP?

Automatice cuando tenga un gran número de casos de prueba que exijan pruebas extensas y repetidas, lo que normalmente significa la regresión. Por debajo de eso, las pruebas manuales están bien. La UAT sigue siendo en gran parte manual, porque su propósito es el criterio del negocio.

¿Qué herramienta se usa para las pruebas SAP?

La mayoría de los programas combinan una herramienta de gestión de pruebas con una de automatización y otra de pruebas de rendimiento. Las opciones habituales son SAP Cloud ALM o Solution Manager para la gestión de pruebas; Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft o UiPath para la automatización; y OpenText LoadRunner para el rendimiento. Los programas nuevos deberían planificar con Cloud ALM, ya que el mantenimiento estándar de Solution Manager termina en 2027.