Come collaudare un gestionale prima del go-live

Durante un progetto si controlla che un pulsante funzioni, che un documento venga generato, che un dato sia importato o che una procedura termini senza errori. Sono verifiche indispensabili, ma non dimostrano che il sistema sia pronto per il lavoro quotidiano. Un ordine può coinvolgere anagrafica, disponibilità, listino, autorizzazioni, magazzino, documenti, spedizione e amministrazione.

Verificare separatamente ciascuna funzione non garantisce che l’intero percorso produca il risultato atteso. Il collaudo deve quindi seguire il processo dall’inizio alla fine.

Un buon caso di test non parte dalla schermata da verificare, ma da una situazione operativa riconoscibile: un nuovo cliente effettua un ordine, una merce viene trasferita tra due sedi, una vendita viene parzialmente restituita, un prodotto richiede una lavorazione oppure un dato esterno risulta incompleto. Per ogni scenario devono essere definiti condizione iniziale, utente e ruolo, dati necessari, operazioni, risultato atteso, controlli finali ed eccezioni. Questo permette di distinguere una sensazione generica — «sembra funzionare» — da una verifica ripetibile.

Un test eseguito con dati perfetti può nascondere molte difficoltà. Nel lavoro reale esistono anagrafiche incomplete, codici non uniformi, prodotti presenti in una sede ma non in un’altra, autorizzazioni differenti, documenti già collegati, quantità parziali e valori provenienti da sistemi esterni.

Il dataset dovrebbe comprendere casi ordinari, casi limite, dati mancanti, eccezioni frequenti e situazioni già problematiche nel sistema precedente. Lo scopo non è mettere artificialmente in difficoltà il software, ma verificare che sappia affrontare la realtà nella quale verrà utilizzato.

Molti collaudi vengono effettuati utilizzando un amministratore. Il processo funziona e soltanto durante l’avviamento si scopre che l’operatore reale non vede una funzione, non può utilizzare una causale, non accede alla sede corretta o non dispone dell’autorizzazione necessaria.

Ruoli e permessi sono parte della funzione. Ogni caso dovrebbe quindi indicare profilo utente, sede, funzioni accessibili, operazioni consentite e operazioni che devono essere bloccate. Un sistema che funziona soltanto con l’amministratore non è ancora pronto per il go-live.

Indicazioni come «il documento deve essere corretto» o «il dato deve aggiornarsi» non consentono un vero collaudo. Bisogna specificare che cosa debba accadere: stato del documento, numerazione, sede, movimentazione, disponibilità, valore economico, informazione inviata a un altro sistema oppure blocco previsto. Più il risultato è osservabile, minore sarà lo spazio per interpretazioni differenti tra azienda, consulenti e sviluppo.

Il collaudo non deve verificare soltanto i percorsi che terminano correttamente. È altrettanto importante controllare che il sistema impedisca operazioni non ammesse: utilizzare un dato obbligatorio mancante, movimentare una quantità non disponibile, accedere a informazioni riservate, emettere un documento dalla sede sbagliata, modificare un’attività consolidata o duplicare un’operazione. Un blocco previsto e comprensibile è una funzione corretta, non un ostacolo.

«Non funziona» non è una descrizione sufficiente. Ogni anomalia dovrebbe riportare ambiente, data, utente e ruolo, caso di test, dati impiegati, passaggi eseguiti, risultato atteso, risultato ottenuto, messaggi ed evidenze disponibili.

L’obiettivo non è produrre burocrazia, ma rendere il comportamento riproducibile. Un problema riproducibile può essere analizzato; un’impressione generica genera invece ulteriori domande e tentativi.

Una criticità bloccante impedisce un processo necessario e non ammette una soluzione temporanea sostenibile. Una criticità alta compromette un’attività importante o produce un risultato errato. Una criticità media consente di proseguire attraverso una procedura alternativa controllata; una bassa riguarda elementi marginali o migliorativi.

La classificazione deve considerare l’impatto sul processo, non soltanto la complessità tecnica della correzione.

Quando un’anomalia viene risolta, il caso deve essere eseguito nuovamente. Il retest verifica che il problema originario sia stato eliminato; la regressione controlla invece che la modifica non abbia compromesso ciò che funzionava già.

Se cambia una regola di magazzino possono dover essere ricontrollati trasferimenti, vendite, resi e disponibilità. Il retest controlla la correzione. La regressione protegge il sistema.

Il fornitore può verificare la correttezza tecnica, ma non può sostituire chi conosce il lavoro reale. Sono gli utenti chiave a conoscere eccezioni frequenti, informazioni indispensabili, conseguenze operative e controlli di fine giornata.

Il collaudo UAT rappresenta l’accettazione della soluzione da parte di chi dovrà utilizzarla. Non significa chiedere agli utenti di provare liberamente il sistema, ma coinvolgerli in verifiche organizzate con casi, obiettivi ed evidenze definiti.

Durante la formazione emergono domande concrete: che cosa accade se manca un dato, chi può correggere un documento, come si opera tra sedi e dove si verifica il risultato. Non sono deviazioni dalla lezione.

Possono evidenziare casi non previsti, responsabilità poco chiare o passaggi ancora da collaudare. Una buona formazione non arriva soltanto dopo il test: contribuisce a completarlo.

La decisione di avviare non dovrebbe basarsi soltanto sulla scadenza o sulla sensazione che il progetto sia quasi terminato. Devono essere noti processi indispensabili completati, test superati, anomalie bloccanti, rischi accettati, riconciliazione dei dati, utenti verificati, formazione, procedure temporanee, responsabilità e assistenza iniziale.

Il Go non significa assenza assoluta di problemi: significa che i rischi residui sono conosciuti e gestibili. Il No-Go può essere la scelta più responsabile quando una criticità minaccia la continuità operativa.

Senza criteri condivisi, ogni difficoltà rischia di trasformarsi in una discussione su chi abbia capito male e su quando una funzione potesse considerarsi terminata. Un piano di collaudo rende visibile ciò che è stato provato, separa i problemi bloccanti dai miglioramenti, assegna responsabilità e collega ogni decisione a un’evidenza. Un gestionale è realmente pronto non quando l’ultima funzione è stata consegnata, ma quando l’intero processo è stato compreso, provato e accettato.