Pruebas de regresión en SAP: actualizaciones, versiones y alcance

Las pruebas de regresión en SAP demuestran que un cambio, un support package o una nueva versión no ha roto procesos de negocio que ya funcionaban. Su alcance se define con análisis de impacto, se ejecutan primero los procesos de mayor riesgo y se repiten cada vez que cambia el sistema, no solo una vez antes del go-live.

Lo que las activa son los transportes, las actualizaciones y las versiones en la nube. En SAP Cloud ERP public edition, SAP fija las fechas de actualización, así que su conjunto de pruebas de regresión tiene que estar listo antes de que llegue la versión.

La regresión es uno de los tipos de prueba de mi guía de pruebas SAP. Este artículo trata qué la activa, cómo definir su alcance, cuándo automatizarla y cómo evitar que un programa y el soporte en vivo rompan el trabajo del otro.

SAP es un sistema integrado. Un cambio en una condición de precio puede romper la facturación, y un campo nuevo en un pedido de cliente puede detener una interfaz. Un support package puede modificar un programa estándar del que usted depende.

Las pruebas de regresión vuelven a ejecutar pruebas sobre procesos que no debían cambiar. Las pruebas funcionales preguntan si lo nuevo funciona; la regresión pregunta si todo lo demás sigue funcionando.

Se aplican durante toda la vida del sistema, no solo durante un programa:

1. Transportes. Cada cambio que pasa de desarrollo a calidad es un riesgo de regresión para los procesos que toca.
2. Support packages y feature packs. Las correcciones y las nuevas funciones de SAP cambian el código estándar que hay debajo de su configuración.
3. Actualizaciones de versión. El paso a una nueva versión, o una versión en la nube que usted no programó, cambia muchas más cosas de golpe.
4. Conversiones. Una conversión de ECC a S/4HANA conserva su configuración y su código a medida, así que todo lo que conservó hay que volver a probarlo. Mi guía de migración de ECC a S/4HANA explica dónde encaja eso en el plan.
5. Integraciones y extensiones. Un cambio en un sistema conectado o en una extensión side-by-side puede romper el lado SAP sin ningún transporte SAP.

Mantenga el conjunto de regresión separado de las pruebas escritas para las funciones nuevas. Ese conjunto es una biblioteca estable de los procesos que el negocio no puede permitirse perder, como order to cash, procure to pay y el cierre mensual.

On-premise, usted elige cuándo actualizar. En las ediciones cloud, SAP fija una parte mayor del calendario, y las pruebas de regresión se convierten en un compromiso recurrente en la agenda.

Public edition: dos actualizaciones al año

SAP Cloud ERP public edition, antes S/4HANA Cloud Public Edition, recibe dos grandes actualizaciones al año, en febrero y agosto. Entre ellas llegan entregas de funciones más pequeñas.

SAP actualiza primero el sistema de pruebas y, unas semanas después, el de producción. Ese intervalo es su ventana de regresión, y no hay segunda oportunidad una vez actualizada la producción.

El curso de Cloud ALM de SAP sobre pruebas posteriores a la actualización y de regresión recomienda crear un plan de pruebas de regresión en Cloud ALM y reutilizarlo en cada versión. La public edition incluye además una herramienta gratuita de automatización de pruebas con guiones de prueba predefinidos, así que los procesos estándar tienen un punto de partida.

Private edition: un ciclo de versiones de dos años

SAP Cloud ERP Private, la private edition que se vende a través de RISE with SAP, sigue el ciclo de versiones de on-premise. Según SAP Learning, cada dos años sale una nueva versión base, cada seis meses le siguen los feature pack stacks y cada versión tiene siete años de mantenimiento estándar.

Debe instalar al menos una actualización cada siete años para seguir en mantenimiento estándar, y RISE le permite solicitar una actualización al año. SAP ejecuta la actualización técnica, pero la planificación, la preparación y las pruebas siguen siendo tarea del cliente o del socio.

Ese reparto importa para el presupuesto. La actualización en sí puede estar incluida en la suscripción, pero las pruebas de regresión que la rodean no lo están.

Esta tabla pone lado a lado lo que activa la regresión:

Cambio	Con qué frecuencia	Quién fija la fecha	Qué debe cubrir la ejecución de regresión
Transporte a calidad	Diaria o semanal	Su equipo	Los procesos que tocan los objetos modificados
Actualización de la public edition	Dos veces al año, febrero y agosto	SAP	Todos los procesos del alcance, primero la lógica a medida, en la ventana previa a producción
Feature pack stack de la private edition	Cada seis meses, si lo adopta	Usted, dentro del calendario de SAP	Las funciones estándar modificadas que usa, más el código a medida
Actualización de versión de la private edition	Al menos cada siete años, hasta una al año a petición con RISE	Usted, con SAP	Conjunto completo, código a medida e integraciones
Conversión de ECC a S/4HANA	Una vez	Usted	Todo lo que conservó

Ejecutar el conjunto completo después de cada cambio es lento y caro. Ejecutar demasiado poco deja pasar defectos, y el hueco aparece en producción.

El análisis de impacto se sitúa entre ambos extremos. Compara lo que cambió con lo que usted realmente usa y enumera los procesos y objetos con más riesgo, para que la ejecución de regresión empiece por ellos.

Estas son las herramientas con las que se encontrará:

1. SAP Solution Manager. El Business Process Change Analyzer, parte del Test Suite, muestra qué procesos de negocio afecta un cambio. El Scope and Effort Analyzer estima el impacto de un support package o de un enhancement package antes de instalarlo, y SAP lo define como una herramienta de planificación.
2. SAP Cloud ALM. Cloud ALM gestiona los planes de pruebas de regresión, la ejecución y los defectos, y se conecta con herramientas de automatización. Para las actualizaciones de la public edition, la herramienta Release Assessment and Scope Dependency de SAP muestra qué cambios de una versión afectan a su alcance.
3. Tricentis LiveCompare. Según la documentación de LiveCompare, identifica un conjunto mínimo de los objetos con más riesgo que hay que probar y luego informa de las coincidencias y los huecos de prueba frente a su repositorio de pruebas. SAP lo revende como SAP Change Impact Analysis by Tricentis, y se integra con Tricentis Tosca.
4. Panaya. El producto de Panaya para actualizaciones SAP combina análisis de impacto de cambios, corrección de código, gestión de pruebas y automatización, y cubre versiones de S/4HANA, feature pack stacks y support package stacks.

Compruebe la situación de su Solution Manager antes de construir sobre él. SAP Support indica que el mantenimiento estándar de Solution Manager 7.2 termina a finales de 2027. Los clientes que contratan el mantenimiento extendido de Business Suite 7 lo conservan hasta finales de 2030, y SAP recomienda pasar a Cloud ALM antes de finales de 2027.

El análisis de impacto acota el alcance. No lo fija por sí solo, así que mantenga un núcleo de procesos críticos para el negocio que se ejecute siempre, diga lo que diga la herramienta.

Mi comparación de herramientas de pruebas y validación de SAP explica cómo encajan estos productos y qué incluye ya su contrato de soporte de SAP.

La regresión es donde la automatización de pruebas se gana su lugar, porque las mismas pruebas se ejecutan una y otra vez. Eso no significa que haya que automatizar todos los conjuntos de regresión.

Mi regla 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.

Un cliente de public edition que ejecuta el conjunto completo dos veces al año, más los transportes intermedios, alcanza ese umbral enseguida. Un sistema pequeño de private edition que cambia pocas veces al año puede no alcanzarlo.

Hágase estas preguntas antes de comprar:

1. ¿Cuántos casos de prueba de regresión tiene, y cuántos se ejecutan en cada ciclo?
2. ¿Con qué frecuencia los ejecuta, contando transportes, feature packs y actualizaciones, no solo las actualizaciones de versión?
3. ¿Cuánto dura una ejecución manual, y cabe dentro de la ventana de regresión?
4. ¿Quién mantendrá los guiones cuando cambien las pantallas y los procesos?

El mantenimiento de los guiones es el costo que se subestima. Un conjunto automatizado que nadie actualiza falla por motivos que no tienen nada que ver con el sistema, y el equipo deja de confiar en él.

En los programas que he dirigido, mis equipos han usado Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager y UiPath. Elija por el encaje con sus sistemas y su equipo, no por la demo. Mi guía de automatización de pruebas SAP trata por dónde empezar y cómo valorar el retorno.

El problema de regresión más difícil en un programa SAP no son las herramientas. Son dos flujos de cambio que pasan por los mismos sistemas al mismo tiempo.

Mientras el programa construye funciones nuevas, el soporte en vivo sigue corrigiendo producción. Si ambos flujos comparten una misma ruta de desarrollo y calidad, una corrección del soporte puede romper las pruebas del proyecto y un cambio del proyecto puede colarse en una entrega del soporte. Entonces nadie sabe qué cambio causó un fallo.

Mi respuesta es mantener dos entornos separados. Uno es para el proyecto y otro para la operación diaria (BAU), de modo que los cambios del soporte en vivo y los del proyecto se prueban por separado.

Entorno del proyectoEntorno de BAU

Qué pasa por élEntorno del proyectoFunciones nuevas, configuración y código a medida del programaEntorno de BAUCorrecciones y pequeños cambios en el sistema en vivo

Foco de la regresiónEntorno del proyectoLos procesos que cambia el programa, más el conjunto centralEntorno de BAULos procesos que toca cada corrección, más el conjunto central

Llega a producciónEntorno del proyectoEn el go-live o en una ola de despliegueEntorno de BAUComo entregas de soporte, con el calendario habitual

Dos entornos resuelven la separación, pero crean una tarea nueva. Cada corrección de BAU también tiene que llegar al entorno del proyecto; si no, el proyecto entra en producción sin ella.

Planifíquelo desde el principio:

1. Incorpore cada cambio de BAU al entorno del proyecto con un ritmo fijo, y haga seguimiento de cada uno.
2. Vuelva a ejecutar las pruebas del proyecto afectadas después de cada incorporación, no solo al final.
3. Congele los cambios de BAU a medida que se acerca el cutover, salvo las correcciones urgentes, que pasan por ambos entornos.
4. Ejecute el conjunto completo de regresión en el entorno del proyecto antes del go-live, con datos enmascarados a nivel de producción.

El segundo entorno cuesta dinero, pero también lo cuesta un go-live en el que nadie sabe qué cambio rompió la facturación. Mi estrategia de pruebas de S/4HANA muestra dónde se ubican los ciclos de regresión junto a las pruebas de integración y de aceptación del usuario.

Construya un conjunto de regresión antes de necesitarlo. Enumere los procesos que el negocio no puede permitirse perder, escriba una prueba para cada uno y ejecútelas una vez a mano para ver cuánto dura un ciclo completo.

Esa cifra le dice si la próxima ventana de actualización es realista y si la automatización compensará. Si está en mitad de un programa, compruebe si los cambios del proyecto y de BAU comparten una misma ruta hacia producción.

Si quiere una opinión independiente sobre su enfoque de regresión o su plan de actualización, ayudo a las organizaciones con esto. Puede contactarme aquí.

¿Qué son las pruebas de regresión en SAP?

Vuelven a ejecutar pruebas sobre procesos de negocio SAP que no debían cambiar, para demostrar que un transporte, un support package, una actualización o una nueva versión no los ha roto. Cubren flujos integrados como order to cash y el cierre mensual, no solo los objetos modificados.

¿Con qué frecuencia necesita pruebas de regresión SAP Cloud ERP public edition?

Al menos dos veces al año, porque SAP actualiza la public edition en febrero y agosto. SAP actualiza primero el sistema de pruebas y, unas semanas después, el de producción, así que la ejecución de regresión tiene que terminar en ese intervalo. Los transportes entre versiones necesitan sus propias ejecuciones, más pequeñas.

¿Quién hace las pruebas de regresión en una actualización de la private edition de RISE with SAP?

SAP ejecuta la actualización técnica. La planificación, la preparación y las pruebas siguen en manos del cliente o del socio de implementación, así que presupueste el esfuerzo de regresión aparte de la suscripción.

¿Qué herramientas ayudan a definir el alcance de las pruebas de regresión en SAP?

Las herramientas de análisis de impacto comparan lo que cambió con lo que usted usa. Las opciones habituales son el Business Process Change Analyzer y el Scope and Effort Analyzer de SAP Solution Manager, y la herramienta Release Assessment and Scope Dependency para la public edition. Tricentis LiveCompare y Panaya hacen el mismo trabajo, mientras que SAP Cloud ALM gestiona los planes de pruebas de regresión y su ejecución.

¿Se deben automatizar las pruebas de regresión en SAP?

Automatice cuando haya un gran número de casos de prueba que exijan pruebas extensas y repetidas. Por debajo de eso, las pruebas manuales están bien. Cuente sus casos de prueba y con qué frecuencia se ejecutan antes de comprar una herramienta, y presupueste el mantenimiento de los guiones.

¿Cómo se hacen pruebas de regresión durante un programa SAP mientras se da soporte al sistema en vivo?

Mantenga dos entornos separados, uno para el proyecto y otro para la operación diaria. Así los cambios del soporte en vivo y los del proyecto se prueban por separado. Incorpore cada corrección de BAU al entorno del proyecto y vuelva a ejecutar las pruebas afectadas.