Il 19 maggio 2026, Tricentis ha annunciato la generazione automatizzata di casi di test assistita dall’intelligenza artificiale all’interno di SAP Enterprise Continuous Testing (SAP ECT): casi di test completi e end-to-end creati a partire da prompt in linguaggio naturale, distribuiti e scalabili tramite SAP AI Units, con funzionalità di autoriparazione integrate per ridurre la manutenzione. Per un’organizzazione di test SAP che ha trascorso anni a scrivere manualmente gli script dei casi di test, la domanda ovvia riguarda la sequenza operativa: si avvia ancora un nuovo progetto di test SAP alla vecchia maniera, chiedendo agli ingegneri di automazione dei test di creare prima una libreria di script, oppure si parte dai prompt e si lascia che siano gli strumenti a generare la base di riferimento? Riteniamo che la risposta sia cambiata, e vale la pena spiegare perché.
Cosa ha effettivamente annunciato Tricentis
L’annuncio, fatto ad Austin e confermato da Karl Fahrbach, Chief Partner Officer di SAP, introduce la generazione di casi di test assistita dall’intelligenza artificiale e guidata da prompt direttamente all’interno di SAP ECT, senza necessità di strumenti separati o livelli di integrazione. Le funzionalità dichiarate: generazione di casi di test completi e end-to-end a partire da descrizioni in linguaggio naturale di un processo aziendale; utilizzo di agenti di intelligenza artificiale per progettare, creare e ottimizzare scenari di test; distribuzione e scalabilità di tali test tramite SAP AI Units; riduzione della manutenzione continua grazie a test con capacità di autoriparazione che si adattano quando cambiano le schermate SAP sottostanti o le fasi del processo. Tricentis cita un beneficio medio annuo di 5,33 milioni di dollari per le organizzazioni che utilizzano le sue soluzioni di test delle applicazioni SAP e cita un caso di studio con Jaguar Land Rover come esempio di test SAP accelerati — entrambe le cifre provengono dai rapporti interni di Tricentis e non sono state sottoposte a revisione contabile indipendente.
Perché è meglio iniziare con dei suggerimenti piuttosto che con la stesura completa di una sceneggiatura
La sequenza tradizionale di un nuovo progetto di test SAP vede in primo piano gli ingegneri di automazione dei test: questi intervistano i responsabili dei processi, documentano i casi di test, quindi li programmano e li mantengono — spesso per mesi prima che esista una prima suite di regressione significativa. Tale sequenza aveva senso quando la creazione di un caso di test rappresentava la fase più costosa. Ora non è più così.
Partire dai prompt inverte l’ordine dell’investimento. Un responsabile di processo o un responsabile del controllo qualità descrive un processo aziendale in linguaggio naturale e la piattaforma genera immediatamente un caso di test funzionante ed eseguibile — prima ancora che un ingegnere dell’automazione abbia scritto anche un solo passo di script. Questo cambia radicalmente l’andamento delle prime settimane di un progetto: invece di impiegare il tempo degli ingegneri di automazione per costruire la copertura partendo da zero, lo si dedica a rivedere e correggere ciò che l’IA ha già generato, il che rappresenta un modo più veloce ed economico per raggiungere una base di riferimento funzionante. Significa inoltre che la decisione di investire maggiormente nelle capacità di ingegneria dell’automazione viene presa sulla base di dati di copertura effettivi, non come una scommessa iniziale.
C’è un secondo motivo per cui questo aspetto è particolarmente rilevante per SAP: i processi aziendali descritti in linguaggio naturale rispecchiano in modo più diretto il modo in cui i responsabili dei processi concepiscono effettivamente i propri flussi di lavoro rispetto a un caso di test basato su script. Ciò colma in parte il divario tra ciò che l’azienda ritiene di stare testando e ciò che la suite di automazione copre effettivamente — ed è proprio da quel divario, non dallo sforzo puro e semplice di scrittura degli script, che tende a originarsi una quota significativa dei difetti in produzione.
Cosa ti offre realmente un approccio “fuori dagli schemi”?
Secondo una nostra stima — che non è un dato pubblicato da Tricentis, quindi va considerata come un’ipotesi di pianificazione piuttosto che come un benchmark del fornitore — la copertura “out-of-the-box” ottenuta dai prompt in linguaggio naturale si attesta in genere tra il 40 e il 50% prima di qualsiasi messa a punto manuale, in base alla capacità di questo tipo di generazione di gestire processi aziendali ben documentati e con percorsi standard. Si tratta di un vantaggio iniziale significativo, ma è anche un limite massimo di cui vale la pena essere onesti: i test generati dai prompt sono più efficaci nelle fasi del processo che un utente aziendale è in grado di articolare chiaramente, mentre risultano più deboli nelle eccezioni, nei casi limite e negli scenari di percorso negativo che i tester esperti verificano istintivamente. Passare da quella base del 40–50% a una copertura di livello produttivo richiede comunque una progettazione mirata dei test: si tratta semplicemente di un lavoro di progettazione applicato su una base di partenza già funzionante, anziché partire da zero.
Dove si inserisce SeaLights per ABAP: in un secondo momento, non all’inizio
È qui che integreremmo Tricentis SeaLights per ABAP, e non lo faremmo deliberatamente fin dal primo giorno. SeaLights analizza continuamente le modifiche ABAP e non relative al codice e le mappa ai test che contano davvero, fornendo visibilità su quali dei “milioni di oggetti ABAP e non relativi al codice” presenti in un tipico ambiente SAP siano coperti e quali no. Per un progetto appena avviato, che sta ancora costruendo la sua prima baseline generata automaticamente, quel livello di analisi dell’impatto ha ancora pochi elementi su cui lavorare: ha bisogno di un corpus esistente di modifiche al codice e di test a cui effettuare la mappatura.
Questa combinazione acquista maggiore senso una volta che un’organizzazione ha superato la fase iniziale di espansione della copertura ed è entrata in una fase stabile di gestione del cambiamento: i prompt continuano a generare e mantenere la baseline di test man mano che i processi si evolvono, mentre SeaLights tiene traccia di quali modifiche ABAP vengono effettivamente coperte da quella baseline e segnala quelle che non lo sono — lo stesso problema che SAP ECT da solo non risolve, poiché è incentrato su test di processo end-to-end piuttosto che sull’impatto delle modifiche a livello di codice. Organizzato in questo modo, SeaLights diventa un livello di targeting che si sovrappone alla copertura già costruita dall’approccio basato sui prompt, anziché un secondo sforzo di test parallelo.
Il nostro punto di vista
Il cambiamento in atto nel settore non consiste tanto nel fatto che “ora sia l’IA a scrivere i test”, quanto piuttosto nel fatto che il modo più economico per raggiungere una base di riferimento utilizzabile per i test sia cambiato, e che di conseguenza debba cambiare anche la sequenza delle attività di test. Ai nuovi clienti SAP consigliamo di iniziare con la generazione guidata da prompt all’interno di SAP ECT per ottenere rapidamente una base di riferimento funzionante, considerando la copertura iniziale del 40–50% come un punto di partenza piuttosto che come un obiettivo, e di ricorrere a SeaLights per ABAP una volta che la velocità delle modifiche diventa il collo di bottiglia della complessità. In questo modello, gli ingegneri dell’automazione continuano a svolgere un ruolo fondamentale; il loro lavoro si sposta semplicemente dalla creazione della copertura da zero al colmare il divario tra la base generata dall’IA e ciò che le eccezioni critiche per il business richiedono effettivamente.
Se state pianificando un nuovo progetto di test SAP e desiderate assistenza per organizzare in sequenza la generazione guidata da prompt e l’analisi dell’impatto con SeaLights per il vostro ambiente, contattateci: questo è proprio il fulcro dell’attività del nostro team Agentic Testing.
