![\"\"](\"https:\/\/e3mag.com\/wp-content\/uploads\/2025\/12\/download_banner_D_1000x125.jpg\")
<\/figure>\n\n\nLas pruebas abarcan toda una serie de actividades. En ambos extremos de un proyecto SAP se encuentran las pruebas unitarias (desarrolladores) y las pruebas de aceptaci\u00f3n del usuario (usuarios clave). Entre ambos extremos, la actividad principal es la prueba funcional, que representa alrededor del 80 % de los costes, complementada con pruebas no funcionales (por ejemplo, pruebas de seguridad, rendimiento y, ahora tambi\u00e9n, pruebas de experiencia de usuario). Las pruebas de SAP se diferencian de las pruebas de aplicaciones individuales. Aunque los conceptos b\u00e1sicos siguen siendo los mismos, las herramientas suelen ser diferentes: SAP ha establecido Tricentis como est\u00e1ndar. Adem\u00e1s, las pruebas de SAP se centran m\u00e1s en las pruebas de integraci\u00f3n y el flujo de datos entre aplicaciones. Los datos (es decir, el intercambio de datos, las tablas y los datos maestros) tienen una prioridad mucho mayor en el mundo SAP que en las aplicaciones desarrolladas individualmente.<\/p>\n\n\n\n
En los \u00faltimos veinte a\u00f1os, las pruebas funcionales se han mantenido pr\u00e1cticamente sin cambios y se han basado en un proceso b\u00e1sico: requisitos o historias de usuario, casos de prueba y scripts de prueba. Hubo numerosos intentos de automatizar este proceso. \u00bfRecuerda los \u201emarcos de pruebas sin scripts\u201c? Con la llegada de los m\u00e9todos \u00e1giles y las herramientas DevOps, surgieron nuevas plataformas, ya fueran denominadas DevOps o de pruebas continuas. El sector hablaba de hiperautomatizaci\u00f3n. Sin embargo, el proceso de requisitos, casos de prueba y scripts sigui\u00f3 siendo fundamental.<\/p>\n\n\n\n
\u00bfPor qu\u00e9 este repaso hist\u00f3rico sobre las pruebas? Los LLM cambiar\u00e1n radicalmente las pruebas. Si las historias de usuario est\u00e1n razonablemente bien redactadas, los LLM pueden generar scripts de prueba en cuesti\u00f3n de minutos, en lugar de semanas. Las ganancias en productividad son impresionantes y los costes de los LLM son m\u00ednimos en comparaci\u00f3n con la mano de obra humana (y siguen bajando). La redacci\u00f3n de scripts de pruebas ya no requiere ingenieros de pruebas, ya que se automatiza. En el futuro, las pruebas funcionales dejar\u00e1n de ser un cuello de botella en los proyectos SAP.<\/p>\n\n\n\n
Se est\u00e1 produciendo una revoluci\u00f3n cuyos efectos tendr\u00e1n un gran alcance en los pr\u00f3ximos a\u00f1os: cambiar\u00e1 el ecosistema de herramientas, har\u00e1 que las licencias y suscripciones de software sean innecesarias y reducir\u00e1 significativamente el esfuerzo de prueba. Los LLM son ideales para proyectos Greenfield, Grow o Public Cloud. La naturaleza de SAP, con su dependencia de procesos empresariales estandarizados, lo hace ideal para este tipo de proyectos en pruebas funcionales. Los procesos empresariales estandarizados de SAP est\u00e1n bien documentados y son f\u00e1cilmente accesibles, y pueden utilizarse para crear artefactos de prueba. <\/p>\n\n\n\n
El uso de LLM resulta m\u00e1s complicado en entornos brownfield (y bluefield), que, con raz\u00f3n, constituyen la mayor parte de todos los proyectos S\/4. Desde el punto de vista de las pruebas, la prioridad ya no es crear nuevos artefactos de prueba desde cero, sino comprender los conjuntos de pruebas existentes.<\/p>\n\n\n\n
La mayor\u00eda de las organizaciones (las cifras son dif\u00edciles de cuantificar) disponen de varios miles de artefactos de prueba (tambi\u00e9n dif\u00edciles de cuantificar), entre los que se incluyen requisitos, escenarios de prueba, casos de prueba y scripts. Estos artefactos son a la vez un activo (reflejan los procesos empresariales de la organizaci\u00f3n a nivel de transacciones SAP) y una carga. <\/p>\n\n\n\n
Por lo tanto, el siguiente paso consiste en comprender estos artefactos: su funci\u00f3n, su calidad y su relevancia. No es la primera vez que las organizaciones revisan sus conjuntos de pruebas: el \u00faltimo intento, hace unos a\u00f1os, utiliz\u00f3 el procesamiento del lenguaje natural (NLP) para identificar casos de prueba redundantes. Sin embargo, esta vez los LLM ofrecen capacidades de ingenier\u00eda inversa: pueden generar casos de prueba a partir de scripts de prueba o historias de usuario. En otras palabras, los LLM pueden ayudar a determinar qu\u00e9 scripts de prueba deben ejecutarse realmente, de modo que las organizaciones puedan centrarse en lo esencial, en lugar de tener que procesar todo su inventario de pruebas.<\/p>\n\n\n\n
Este es el primer paso para utilizar los LLM en la ingenier\u00eda de calidad. El mundo de los LLM est\u00e1 lleno de oportunidades, pero tambi\u00e9n de retos. Aunque los LLM aportan enormes ganancias de productividad, estas no se traducen necesariamente en ahorros significativos. Esto es algo que a\u00fan debe comprenderse mejor. Sin embargo, tenemos algunas pistas: las pruebas son un proceso con muchos pasos, m\u00e1s all\u00e1 de las pruebas funcionales, y contienen cuellos de botella (por ejemplo, la disponibilidad de entornos de prueba) que pueden afectar a la duraci\u00f3n total del ciclo de pruebas. <\/p>\n\n\n\n
Otro aspecto a tener en cuenta es c\u00f3mo utilizar\u00e1n los expertos en pruebas los LLM. \u00bfAprovechar\u00e1n el aumento de la productividad para acortar los ciclos de pruebas? \u00bfO dedicar\u00e1n parte del tiempo ganado a realizar comprobaciones de calidad adicionales y an\u00e1lisis de causas para mejorar la calidad del software? Ser\u00eda un gran avance, ya que las pruebas de software y la calidad del software nunca han estado tan estrechamente relacionadas como hoy en d\u00eda.<\/p>\n\n\n\n<\/figure>\n\n\n