I test SAP spiegati: tipi, fasi e responsabili

I test SAP sono il lavoro con cui si dimostra che un sistema SAP configurato esegue correttamente i processi della sua azienda, con i suoi dati e ai suoi volumi, prima del go-live e ogni volta che cambia in seguito. In un programma S/4HANA comprendono sei tipi di test: unit test, test di integrazione di sistema (SIT), test di accettazione utente (UAT), test di regressione, test di performance e prove di cutover.

Ogni tipo risponde a una domanda diversa, e nessuno sostituisce un altro. Nella mia esperienza i test assorbono circa il 35 percento dell'impegno del programma. Per questo meritano un piano, un budget e dei responsabili propri, non qualche settimana alla fine del build.

Questa pagina è la panoramica. Ogni tipo di test ha una guida dedicata, collegata dalle sezioni qui sotto.

Un sistema SAP è fatto di configurazione, dati anagrafici, codice custom e interfacce che lavorano insieme. Una modifica in un punto può rompere un processo altrove, spesso in un modulo che nessuno ha toccato.

Per questo i test SAP si organizzano attorno ai processi aziendali, non alle schermate. Order to cash, procure to pay e record to report attraversano più moduli, e un test che si ferma a una singola transazione dimostra ben poco.

E i test non finiscono con il go-live. Le modifiche di supporto, le release SAP e i nuovi rollout cambiano tutti il sistema, quindi la stessa disciplina prosegue nella fase Run.

Questi sono i sei tipi che pianifico in un programma S/4HANA. La tabella mostra che cosa dimostra ciascuno, quando si esegue e chi deve esserne responsabile.

Tipo di test	Che cosa dimostra	Dove si colloca in SAP Activate	Chi ne è responsabile
Unit test	Ogni elemento di configurazione, programma o enhancement funziona da solo	Realize, dentro ogni sprint di build	Consulenti funzionali e tecnici
Test di integrazione di sistema (SIT)	I processi completi girano attraverso moduli e interfacce con dati realistici	Realize, in cicli, una volta che il build è stabile	Test lead del programma, con i process owner
Test di accettazione utente (UAT)	Il business riesce a eseguire i propri scenari reali sul sistema	Fine di Realize, prima di Deploy	Il business
Test di regressione	Ciò che funzionava prima funziona ancora dopo una modifica	Da Realize in poi, poi a ogni release in Run	Test lead, con automazione dove i volumi la giustificano
Test di performance	Il sistema regge molti utenti e volumi di produzione contemporaneamente	Realize, completato prima del go-live	Responsabile performance a livello di programma, con il Basis
Prova di cutover	La sequenza di go-live, i caricamenti dati e i tempi funzionano dall'inizio alla fine	Deploy	Cutover manager

I test SAP lungo SAP Activate

1. 01

   Prepare

   Predisporre lo strumento di test, il team e il landscape di test.

2. 02

   Explore

   Scrivere la strategia di test mentre si prendono le decisioni di fit-to-standard, così i requisiti sono testabili.

3. 03

   Realize

   Unit test negli sprint, poi cicli di SIT, test di performance e UAT una volta che il build è stabile.

4. 04

   Deploy

   Prove di cutover su una checklist concordata, poi la decisione di go-live.

5. 05

   Run

   Test di regressione per ogni modifica di supporto, upgrade e release.

Unit test

Gli unit test li esegue chi ha costruito l'elemento. Un consulente funzionale verifica una condizione di prezzo, uno sviluppatore verifica un enhancement o il mapping di un'interfaccia.

Sono necessari, non sufficienti. Uno unit test pulito non dice nulla su ciò che succede quando quell'elemento incontra il resto del processo.

Test di integrazione di sistema

Il SIT è il momento in cui il programma scopre se il disegno funziona. Un ordine di vendita deve scorrere verso consegna, fatturazione, contabilità e reporting, e ogni interfaccia lungo il percorso deve registrare correttamente.

Pianifico il SIT in cicli, non come un passaggio unico. I difetti trovati nel primo ciclo vengono corretti, e il ciclo successivo dimostra che le correzioni non hanno rotto nient'altro. Come si incastrano cicli, criteri di ingresso e criteri di uscita lo spiego nella mia guida alla strategia di test S/4HANA.

Test di accettazione utente

La UAT è il business che conferma che il sistema supporta il modo in cui lavorerà dopo il go-live. Appartiene al business, non al system integrator, perché solo il business può accettare il sistema.

La UAT richiede almeno 6-8 settimane. Se la comprime per far posto a un build in ritardo, ottiene un'approvazione sulla carta e problemi in produzione. La mia guida al test di accettazione utente SAP tratta script, ruoli e approvazione.

Test di regressione

Il test di regressione riesegue test già superati dopo una modifica, per intercettare tutto ciò che la modifica ha rotto. In un programma lungo, le correzioni del supporto in esercizio e le modifiche di progetto attraversano il sistema nello stesso momento.

Il mio approccio è gestire due landscape separati, uno per il progetto e uno per l'operatività corrente (BAU). Le modifiche del supporto in esercizio e quelle di progetto vengono così testate separatamente, e nessuna nasconde un difetto dell'altra. La mia guida al test di regressione SAP tratta l'approccio a due landscape, gli upgrade e l'analisi d'impatto.

Test di performance

Il test di performance va fatto prima del go-live. I test che contano di più sono quelli di concorrenza, con molti utenti che eseguono transazioni nello stesso momento.

Una transazione corretta per un utente può andare in timeout con duecento. Il test funzionale non glielo mostrerà mai. La mia guida per i leader IT sul test di performance SAP tratta load test, stress test e soak test e come scrivere i criteri di accettazione.

Prova di cutover

La prova di cutover mette alla prova il go-live stesso: la sequenza dei passi tecnici, i caricamenti dati, le riconciliazioni e le approvazioni, con i relativi tempi. In una conversione brownfield pianifico tre mock conversion prima del cutover.

Il criterio di go-live su cui insisto è una checklist di cutover dettagliata, concordata in anticipo. Se la checklist si scrive durante il weekend di cutover, le prove non erano vere prove.

Nella mia esperienza i test assorbono circa il 35 percento dell'impegno del programma. È un dato che sorprende gli sponsor abituati a vedere il test come il breve intervallo tra build e go-live.

L'impegno è distribuito su molte persone. I consulenti eseguono gli unit test, un team di test prepara ed esegue il SIT, gli utenti di business eseguono la UAT, mentre i team Basis e di integrazione supportano i test di performance e le prove di cutover.

La migrazione dei dati corre in parallelo e da sola assorbe dal 30 al 40 percento dell'impegno. Le due attività si sovrappongono molto, perché ogni ciclo di test ha bisogno di dati migrati che somiglino a quelli di produzione.

L'errore di test più comune che vedo è semplicemente fare troppo pochi test in SIT e UAT. I cicli vengono tagliati quando il build è in ritardo, e la data di go-live resta dov'era. Nei 21 programmi SAP che ho guidato o recuperato, l'errore più grande resta non pianificare bene all'inizio, e di solito è proprio nei test che questo emerge per primo.

I test valgono quanto i dati su cui girano. La mia regola è: dati mascherati, ma a livello di produzione. Volumi su scala di produzione e record realistici, con i campi personali e sensibili mascherati.

Dati di test piccoli e puliti nascondono i problemi che contano. Un report che gira in pochi secondi su qualche migliaio di record può girare per ore su un anno intero di registrazioni.

L'ambiente conta quanto i dati. Pianifichi il landscape di test in Prepare, decida come aggiornarlo tra un ciclo e l'altro e tenga separate le modifiche di progetto da quelle BAU. La mia guida alla gestione dei dati di test SAP tratta copie, mascheramento e dati di test selettivi.

La mia regola sull'automazione è semplice. Quando c'è un gran numero di casi di test che richiedono test estesi e ripetuti, automatizzi. Al di sotto di quella soglia, il test manuale va bene.

La regressione è di solito il primo ambito in cui l'automazione ripaga, perché gli stessi test girano dopo ogni modifica. La UAT resta in gran parte manuale, perché il suo scopo è il giudizio di un utente di business, non quello di uno script.

C'è un motivo pratico per decidere presto. I test automatizzati richiedono tempo per essere costruiti e mantenuti, quindi ripagano solo quando girano molte volte. La mia guida all'automazione dei test SAP spiega da dove partire e quando conviene.

Gli strumenti si dividono in tre gruppi: gestione dei test, automazione funzionale e test di performance. I team che ho guidato o con cui ho lavorato hanno usato Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath e LoadRunner.

Ecco che cosa fa ciascun gruppo e quali prodotti ne fanno parte:

Gruppo di strumenti	Che cosa fa	Prodotti usati comunemente dai team
Gestione dei test	Piani di test, casi di test, registrazioni delle esecuzioni, difetti e tracciabilità verso i requisiti	SAP Cloud ALM, SAP Solution Manager, Panaya
Automazione dei test funzionali	Esegue test scriptati o basati su modelli su applicazioni SAP e non SAP	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Test di performance	Simula molti utenti concorrenti e volumi di produzione	OpenText LoadRunner, oggi venduto come OpenText Professional Performance Engineering

Prima di scegliere conviene conoscere alcuni fatti sui prodotti.

1. SAP Cloud ALM è incluso per i clienti con SAP Enterprise Support o con una sottoscrizione cloud che contiene Enterprise Support, cloud editions (SAP Support). La sua gestione dei test copre la preparazione dei test, i piani di test e l'esecuzione, compresi i casi di test manuali per la UAT (SAP Learning).
2. SAP Solution Manager 7.2: la manutenzione mainstream termina alla fine del 2027, con una manutenzione estesa opzionale fino alla fine del 2030 per un sottoinsieme di funzioni, tra cui la test suite (SAP Support).
3. SAP Test Automation by Tricentis è il prodotto di automazione rivenduto da SAP, integrato con SAP Cloud ALM e pensato per sistemi SAP e di terze parti (SAP).
4. LoadRunner è un prodotto OpenText. LoadRunner Professional oggi si chiama OpenText Professional Performance Engineering e supporta i protocolli SAP GUI e SAP Web (OpenText).

Se sta avviando un nuovo programma, pianifichi la gestione dei test in Cloud ALM anziché in Solution Manager. Per un confronto più approfondito, legga la mia guida agli strumenti di test SAP.

Su SAP Cloud ERP public edition (S/4HANA Cloud Public Edition), SAP aggiorna tutti i clienti secondo il proprio calendario. SAP Learning descrive upgrade ogni sei mesi, attualmente a febbraio e ad agosto, con nuove funzionalità rilasciate ogni mese nel frattempo (SAP Learning).

La data dell'upgrade non la sceglie lei, quindi il test di regressione diventa una scadenza fissa di calendario anziché un progetto. È l'argomento più forte per automatizzare presto la regressione su un sistema public cloud.

Su private cloud e on-premise è lei a decidere i tempi degli upgrade. Ognuno richiede comunque un ciclo di regressione dimensionato sui processi toccati dalla modifica.

Prima di tutto, inserisca i test nel piano come un filone di lavoro con un responsabile e un budget propri, dimensionato a circa un terzo dell'impegno. Poi nomini il responsabile di business della UAT e blocchi subito 6-8 settimane nel calendario, prima che il build le comprima.

Colleghi i risultati dei test alle decisioni go/no-go con criteri di uscita misurabili. La mia guida ai quality gate SAP mostra come fare. Se il suo programma è già in difficoltà, le mie note sul recupero dei programmi SAP spiegano che cosa correggere per primo.

Se desidera un parere indipendente su una strategia di test o su una decisione di go-live, aiuto le organizzazioni proprio su questo. Può contattarmi qui.

Che cosa sono i test SAP?

I test SAP dimostrano che un sistema SAP configurato esegue correttamente i processi della sua azienda, con i suoi dati e ai suoi volumi. In un programma S/4HANA comprendono unit test, test di integrazione di sistema, test di accettazione utente, test di regressione, test di performance e prove di cutover. Proseguono dopo il go-live per ogni modifica di supporto e ogni release.

Quali sono i tipi di test SAP?

I sei tipi principali sono unit test, test di integrazione di sistema (SIT), test di accettazione utente (UAT), test di regressione, test di performance e prove di cutover. Gli unit test verificano i singoli elementi, il SIT verifica i processi completi attraverso moduli e interfacce, e la UAT è il business che accetta il sistema. Regressione, performance e prove di cutover proteggono da modifiche, carico e dal go-live stesso.

Quanto dura il test di accettazione utente SAP?

Preveda almeno 6-8 settimane per la UAT. Il business deve esserne responsabile, eseguire i propri scenari reali e approvarla. Fare troppo pochi test in UAT e SIT è l'errore di test più comune che vedo.

Quanta parte di un progetto SAP è dedicata ai test?

Nella mia esperienza i test assorbono circa il 35 percento dell'impegno del programma. Ciò comprende la preparazione e l'esecuzione di unit test, cicli di SIT, UAT, regressione, test di performance e prove di cutover. La migrazione dei dati corre in parallelo e richiede dati simili a quelli di produzione per ogni ciclo di test.

I test SAP vanno automatizzati?

Automatizzi quando ha un gran numero di casi di test che richiedono test estesi e ripetuti, il che di solito significa la regressione. Al di sotto di quella soglia, il test manuale va bene. La UAT resta in gran parte manuale, perché il suo scopo è il giudizio del business.

Quale strumento si usa per i test SAP?

La maggior parte dei programmi combina uno strumento di gestione dei test con uno strumento di automazione e uno di test di performance. Le scelte comuni sono SAP Cloud ALM o Solution Manager per la gestione dei test, Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft o UiPath per l'automazione e OpenText LoadRunner per la performance. I nuovi programmi dovrebbero puntare su Cloud ALM, dato che la manutenzione mainstream di Solution Manager termina nel 2027.