La revolución LLM Pruebas SAP

Las 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ón 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én, pruebas de experiencia de usuario). Las pruebas de SAP se diferencian de las pruebas de aplicaciones individuales. Aunque los conceptos básicos siguen siendo los mismos, las herramientas suelen ser diferentes: SAP ha establecido Tricentis como estándar. Además, las pruebas de SAP se centran más en las pruebas de integración 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.

En los últimos veinte años, las pruebas funcionales se han mantenido prácticamente sin cambios y se han basado en un proceso básico: requisitos o historias de usuario, casos de prueba y scripts de prueba. Hubo numerosos intentos de automatizar este proceso. ¿Recuerda los „marcos de pruebas sin scripts“? Con la llegada de los métodos ágiles y las herramientas DevOps, surgieron nuevas plataformas, ya fueran denominadas DevOps o de pruebas continuas. El sector hablaba de hiperautomatización. Sin embargo, el proceso de requisitos, casos de prueba y scripts siguió siendo fundamental.

Enormes ganancias en productividad

¿Por qué este repaso histórico sobre las pruebas? Los LLM cambiarán radicalmente las pruebas. Si las historias de usuario están razonablemente bien redactadas, los LLM pueden generar scripts de prueba en cuestión de minutos, en lugar de semanas. Las ganancias en productividad son impresionantes y los costes de los LLM son mínimos en comparación con la mano de obra humana (y siguen bajando). La redacción de scripts de pruebas ya no requiere ingenieros de pruebas, ya que se automatiza. En el futuro, las pruebas funcionales dejarán de ser un cuello de botella en los proyectos SAP.

Se está produciendo una revolución cuyos efectos tendrán un gran alcance en los próximos años: cambiará el ecosistema de herramientas, hará que las licencias y suscripciones de software sean innecesarias y reducirá 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án bien documentados y son fácilmente accesibles, y pueden utilizarse para crear artefactos de prueba.

El uso de LLM resulta más complicado en entornos brownfield (y bluefield), que, con razón, 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.

La mayoría de las organizaciones (las cifras son difíciles de cuantificar) disponen de varios miles de artefactos de prueba (también difíciles 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ón a nivel de transacciones SAP) y una carga.

Por lo tanto, el siguiente paso consiste en comprender estos artefactos: su función, su calidad y su relevancia. No es la primera vez que las organizaciones revisan sus conjuntos de pruebas: el último intento, hace unos años, utilizó el procesamiento del lenguaje natural (NLP) para identificar casos de prueba redundantes. Sin embargo, esta vez los LLM ofrecen capacidades de ingeniería 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é 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.

Ahorro de costes, pero ¿dónde?

Este es el primer paso para utilizar los LLM en la ingeniería de calidad. El mundo de los LLM está lleno de oportunidades, pero también de retos. Aunque los LLM aportan enormes ganancias de productividad, estas no se traducen necesariamente en ahorros significativos. Esto es algo que aún debe comprenderse mejor. Sin embargo, tenemos algunas pistas: las pruebas son un proceso con muchos pasos, más allá de las pruebas funcionales, y contienen cuellos de botella (por ejemplo, la disponibilidad de entornos de prueba) que pueden afectar a la duración total del ciclo de pruebas.

Otro aspecto a tener en cuenta es cómo utilizarán los expertos en pruebas los LLM. ¿Aprovecharán el aumento de la productividad para acortar los ciclos de pruebas? ¿O dedicarán parte del tiempo ganado a realizar comprobaciones de calidad adicionales y análisis de causas para mejorar la calidad del software? Sería un gran avance, ya que las pruebas de software y la calidad del software nunca han estado tan estrechamente relacionadas como hoy en día.

Continúe con la entrada del socio: