Strategia di test S/4HANA: cicli, criteri e ruoli

Una strategia di test S/4HANA decide quali cicli di test eseguire, in quale ordine, chi è responsabile di ciascuno e quali evidenze permettono di passare da uno al successivo. Nei miei programmi copre il test di integrazione di sistema (SIT) in cicli, il test di accettazione utente (UAT) in cicli e il test di regressione, ciascuno con criteri di ingresso e di uscita scritti e un'approvazione nominativa.

Nei programmi S/4HANA che pianifico i test assorbono circa il 35 percento dell'impegno del programma, quindi la strategia merita la stessa cura del piano di build.

I tipi di test in sé sono trattati nella mia guida ai test SAP spiegati. Questo articolo è il livello della strategia: cicli, criteri, ruoli e lo schema del documento.

SAP Activate colloca la maggior parte dei test in Realize. Il materiale SAP sulla strategia di test per S/4HANA Cloud Private Edition considera informali gli unit test e gli string test. I test completi dei processi aziendali, di integrazione, di migrazione dei dati e di accettazione utente sono formali e vanno documentati.

Questa è la sequenza che pianifico in un programma S/4HANA:

I cicli di test S/4HANA

1. 01

   Unit e string test

   I consulenti testano ogni funzione configurata e brevi catene man mano che costruiscono.

2. 02

   Cicli di SIT

   Catene di processo complete attraverso moduli, interfacce e dati migrati.

3. 03

   Cicli di UAT

   Gli utenti di business dimostrano, ciclo dopo ciclo, che il sistema esegue i loro processi.

4. 04

   Regressione

   Ritestare ciò che era già stato superato dopo correzioni, trasporti e release.

5. 05

   Mock conversion e prova generale

   Eseguire il cutover come avverrà la notte reale, seguendo la checklist.

6. 06

   Go-live

   Partire solo quando la checklist di cutover concordata è completa.

Unit test e string test

Consulenti e sviluppatori testano ogni elemento di configurazione e ogni sviluppo man mano che lo costruiscono. Gli string test concatenano alcuni passi, per esempio un ordine di vendita fino alla consegna.

Informali nella terminologia SAP, ma non facoltativi.

Test di integrazione di sistema in cicli

Il SIT testa processi aziendali completi attraverso moduli, interfacce e dati convertiti o caricati. Lo pianifico in cicli anziché come un unico evento, così i difetti corretti dopo un ciclo vengono ritestati nel successivo.

Non ho un numero fisso di cicli di SIT. Il numero dipende da quanti processi, interfacce e società rientrano nel perimetro, e la strategia deve dire quanti cicli e perché.

Test di accettazione utente in cicli

La UAT è il momento in cui il business conferma che il sistema esegue i suoi processi, con le proprie persone e dati realistici. Come il SIT, la pianifico in cicli, così le correzioni di un ciclo vengono ritestate nel successivo.

La UAT richiede almeno 6-8 settimane. I tester di business la svolgono accanto al loro lavoro ordinario, e hanno bisogno di tempo per più di un ciclo. La mia guida al test di accettazione utente SAP tratta in dettaglio script, cicli e approvazione.

Test di regressione

Ogni correzione, trasporto e release può rompere qualcosa che aveva già superato i test. Il test di regressione riesegue i processi che contano dopo ogni modifica, durante il programma e dopo il go-live.

Il materiale SAP colloca la regressione soprattutto in Run, dopo gli upgrade di release, ma un programma ne ha bisogno anche prima. Approccio, analisi d'impatto e configurazione degli ambienti sono nella mia guida al test di regressione SAP.

Mock conversion e prova di cutover

In una conversione brownfield pianifico tre mock conversion prima del cutover. Ognuna verifica la conversione stessa, i tempi e la riconciliazione, non solo i processi.

L'ultima prova deve svolgersi come la notte reale: stessa sequenza, stesse persone, stessa checklist. La mia timeline di migrazione S/4HANA e piano di progetto mostra dove si collocano queste esecuzioni nel piano.

La decisione di responsabilità più importante in assoluto: il test di accettazione utente è responsabilità del business. Non del system integrator e non dell'IT.

Un integratore può preparare gli script e correggere i difetti. Solo le persone che gestiscono la chiusura contabile, l'order to cash o lo stabilimento possono confermare che quei processi funzionano.

Le indicazioni di SAP vanno nella stessa direzione. Gli esperti di configurazione del partner creano i casi di test, mentre gli esperti di linea di business del cliente eseguono la UAT e registrano i risultati.

Ecco come ripartirei le responsabilità tra i cicli:

Ciclo	Responsabile	Esegue	Approva
Unit e string test	Responsabile del team di build	Consulenti e sviluppatori	Responsabili funzionali e tecnici
Cicli di SIT	Test manager	Consulenti, con i key user che si uniscono nei cicli successivi	Test manager e process owner
Cicli di UAT	Il business, tramite process owner nominati	Key user e tester di business	Process owner, poi lo sponsor
Regressione	Test manager	Team di test, con automazione dove i volumi la giustificano	Test manager e change board
Mock conversion e prova generale	Cutover lead	Team tecnici, dati e funzionali	Cutover lead, data lead e sponsor

Nella strategia scriva i nomi, non i ruoli. «Process owner finance» è un ruolo; una persona con nome e cognome che ha accettato di firmare è un responsabile.

I criteri di ingresso impediscono che un ciclo inizi prima di poter riuscire. I criteri di uscita impediscono che finisca solo perché lo dice il calendario.

Li scriva entrambi prima che inizi Realize, quando nessuno è sotto pressione per le scadenze. La mia guida ai quality gate SAP spiega come questi criteri diventano gate formali con un responsabile in grado di dire «non siamo pronti».

La tabella qui sotto è una traccia da adattare, non uno standard da copiare. Fissi le percentuali e i limiti di difetti con il suo sponsor e li registri nella strategia:

Ciclo	Criteri di ingresso	Criteri di uscita
Unit e string test	Disegno approvato; configurazione e sviluppo completati per gli elementi in test	Tutti gli elementi testati e documentati; difetti corretti o registrati a carico del SIT
Ciclo di SIT	Unit test completati per i processi in perimetro; ambiente di test costruito e interfacce collegate; dati di test caricati; script revisionati	Quota concordata di script eseguiti e superati; nessun difetto critico aperto; ogni difetto minore aperto ha un responsabile e una data di correzione
Ciclo di UAT	Criteri di uscita del SIT soddisfatti; tester di business nominati e sollevati dal lavoro ordinario; script revisionati dai process owner; formazione sul sistema di test completata	Ogni processo in perimetro eseguito dagli utenti di business; nessun difetto critico aperto; i process owner hanno firmato i propri processi
Regressione	Una modifica, un lotto di correzioni o una release pronti per il passaggio; pacchetto di regressione concordato per i processi interessati	Pacchetto di regressione superato; ogni errore corretto e ritestato prima che la modifica prosegua
Mock conversion o prova generale	Copia di produzione disponibile; checklist di cutover e run book in bozza; regole di riconciliazione concordate	Conversione o caricamento completati entro la finestra pianificata; riconciliazione firmata dal data lead; checklist aggiornata con le lezioni apprese
Go-live	Tutti i criteri di uscita precedenti soddisfatti; checklist di cutover concordata in anticipo	Ogni voce della checklist completata e firmata; decisione go/no-go registrata dallo sponsor

Due regole fanno funzionare la tabella. Ogni criterio dà una risposta sì o no, e ogni uscita ha un firmatario nominato.

Se un ciclo non soddisfa i criteri di uscita e il business vuole comunque andare avanti, ne faccia una decisione scritta. Indichi la persona che ha accettato il rischio e i difetti portati avanti.

Lo scrive il test manager in Prepare o all'inizio di Explore, e lo approva lo sponsor. Lo tenga abbastanza breve perché i process owner lo leggano.

Queste sono le sezioni che mi aspetto di trovare:

1. Perimetro e obiettivi. Quali processi, società, interfacce e report vengono testati, e quali sono esplicitamente esclusi.
2. Tipi di test e cicli. Unit test, string test, cicli di SIT, cicli di UAT, regressione, performance, test di migrazione dei dati e mock conversion, con il numero di cicli e la motivazione.
3. Calendario e impegno. Le date di ogni ciclo dentro il piano SAP Activate, con almeno 6-8 settimane per la UAT, e l'impegno a budget rispetto alla quota di circa il 35 percento dedicata ai test.
4. Ruoli e responsabilità. La tabella delle responsabilità qui sopra, con i nomi.
5. Criteri di ingresso e di uscita. Un set per ciclo, con il firmatario di ciascuno.
6. Ambienti. Quali sistemi si usano per quale ciclo, come vengono aggiornati e come le modifiche di progetto restano separate da quelle del supporto in esercizio.
7. Dati di test. Da dove vengono i dati, come vengono mascherati e come vengono aggiornati tra un ciclo e l'altro. La mia guida alla gestione dei dati di test SAP approfondisce il tema.
8. Gestione dei difetti. Definizioni di gravità, cadenza del triage, chi decide la priorità e il tempo di correzione obiettivo per ogni livello di gravità.
9. Strumenti. Dove risiedono casi di test, risultati, difetti e approvazioni, con un unico sistema di riferimento.
10. Approccio all'automazione. Quali test vengono automatizzati, quali restano manuali e perché.
11. Reporting. Che cosa mostra il report settimanale sui test e chi lo riceve.
12. Criteri di cutover e go-live. La checklist di cutover, le prove che la convalidano e chi prende la decisione go/no-go.
13. Rischi e ipotesi. Disponibilità dei tester, date degli ambienti, prontezza dei dati e dipendenze da terze parti.

Quanto agli strumenti, SAP Cloud ALM è la scelta predefinita per i nuovi programmi. SAP dichiara che non esiste una licenza separata per SAP Cloud ALM: è inclusa in Enterprise Support, e le sue app di gestione dei test contengono i casi di test formali, le esecuzioni e i risultati.

SAP Solution Manager 7.2 è ancora in uso in molti programmi, ma la sua manutenzione mainstream termina alla fine del 2027. Per l'automazione SAP vende SAP Test Automation by Tricentis, che funziona con Cloud ALM; il mio confronto tra strumenti di test SAP tratta la scelta più ampia.

L'errore di test più comune che vedo è fare troppo pochi test in UAT e SIT.

Un meccanismo frequente: il build va in ritardo, la data di go-live resta fissa e le settimane vengono tolte ai cicli di test, perché stanno alla fine del piano.

Questi sono gli schemi che lo causano, e che cosa fare per ciascuno:

1. Il SIT inizia prima che gli unit test siano finiti. Il primo ciclo di SIT diventa un ciclo di unit test. Tenga fermi i criteri di ingresso.
2. La UAT viene pianificata per due o tre settimane. In quel tempo gli utenti di business non riescono a testare bene accanto al loro lavoro ordinario. Pianifichi almeno 6-8 settimane e liberi i tester.
3. L'integratore esegue la UAT al posto del business. Gli script vengono superati, e il business scopre le lacune dopo il go-live. Lasci la responsabilità della UAT ai process owner.
4. I test vengono messi a budget come una piccola voce. Con circa il 35 percento dell'impegno, test finanziati con una frazione di quella cifra sono i primi a essere tagliati.
5. I criteri di uscita vengono scritti durante il ciclo. Finiscono per coincidere con qualunque risultato il team abbia raggiunto. Li scriva prima di Realize.
6. Il go-live si decide sulla fiducia, non su una checklist. Nessuno può mostrare che cosa era stato concordato, quindi nessuno può dire che cosa manca.

Quest'ultimo punto è quello su cui insisto. Il mio criterio di go-live è una checklist di cutover dettagliata, concordata in anticipo con il business, l'IT e l'integratore.

Copre passi tecnici, caricamenti dati, riconciliazioni, validazioni di business, passaggi delle interfacce, accessi utente e punti di go/no-go. Se una voce non è completata e firmata, il programma non è pronto, qualunque cosa dica la data.

Prima che inizi Realize, chieda al suo test manager il documento di strategia di test e lo confronti con lo schema qui sopra. Se non ha un responsabile UAT nominato, dà alla UAT meno di 6-8 settimane o non ha criteri di ingresso e di uscita per ogni ciclo, corregga prima questo.

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

Che cos'è una strategia di test S/4HANA?

È il piano che decide quali cicli di test eseguire, in quale ordine, chi è responsabile di ciascuno e lo approva, e quali evidenze permettono al programma di passare da un ciclo al successivo. In un programma S/4HANA di solito copre unit test e string test, cicli di SIT, cicli di UAT, regressione, test di migrazione dei dati e prove di cutover.

Quanta parte di un programma S/4HANA è dedicata ai test?

Nei programmi che pianifico, i test assorbono circa il 35 percento dell'impegno del programma. Li metta a budget a quel livello fin dall'inizio, perché i test sottofinanziati sono la prima cosa che si taglia quando il build va in ritardo.

Quanto deve durare la UAT in un progetto S/4HANA?

Almeno 6-8 settimane. I tester di business eseguono la UAT accanto al loro lavoro ordinario, e hanno bisogno di tempo per più di un ciclo, così le correzioni del primo ciclo vengono ritestate.

Chi deve essere responsabile del test di accettazione utente in SAP?

Il business, tramite process owner nominati. Il system integrator può preparare gli script, gestire l'ambiente e correggere i difetti, ma solo le persone che gestiscono i processi possono confermare che il sistema funziona per loro.

Che cosa sono i criteri di ingresso e di uscita nei test SAP?

I criteri di ingresso sono le condizioni di cui un ciclo ha bisogno prima di iniziare, come unit test completati, un ambiente costruito e dati di test caricati. I criteri di uscita sono le condizioni che deve soddisfare prima di concludersi, come script eseguiti, nessun difetto critico aperto e l'approvazione dei process owner. Ognuno deve dare una risposta sì o no e avere un firmatario nominato.

Che cosa deve includere una checklist di go-live S/4HANA?

Passi tecnici di cutover, caricamenti dati e riconciliazioni, validazioni di business, passaggi delle interfacce, accessi utente e i punti di decisione go/no-go. La concordi in anticipo, la provi nelle mock conversion o nella prova generale e vada live solo quando ogni voce è completata e firmata.