Collaudare un software aziendale: le prove da fare prima di usarlo ogni giorno

Il collaudo di un gestionale fallisce quasi sempre allo stesso modo: si convoca chi lo userà, si dice «provatelo», e le persone provano le cose che sanno già fare. Il software passa. Poi, il primo giorno di lavoro vero, arriva l’ordine da annullare dopo la spedizione, e quello non l’aveva provato nessuno.

Collaudare significa scrivere prima che cosa deve succedere, poi verificare che succeda. La differenza fra le due cose sta tutta nella parola «prima».

Uno scenario di prova non è «provare il programma»

Uno scenario ha quattro parti, e se ne manca una la prova non è né ripetibile né discutibile.

• I dati di partenza: quale cliente, quale ordine, quale magazzino, con quali valori.
• Il ruolo: chi la esegue e con quali permessi.
• I passi: che cosa si fa, nell’ordine in cui si fa.
• Il risultato atteso: che cosa deve essere vero alla fine, scritto prima di eseguire.

Il risultato atteso è la parte che si salta ed è l’unica che conta. Senza, la prova finisce con «mi sembra che funzioni», che non è un esito ma un’impressione, e non si può contestare né confermare.

Un piano di collaudo: la commessa

Esempio illustrativo su un modulo che gestisce commesse. Le prove sono scelte per coprire i tre tipi che servono sempre: il caso normale, l’eccezione e ciò che deve essere impedito.

Le ultime tre righe sono quelle che si dimenticano sempre. Un sistema si giudica anche da ciò che rifiuta, e il rifiuto deve essere comprensibile: un’operazione bloccata senza spiegazione produce le stesse telefonate di un errore.

Le prove che nessuno pensa a fare

• Le operazioni non autorizzate, provate davvero con l’utente limitato e non solo lette nella tabella dei permessi. Vanno controllate anche stampe ed esportazioni, da cui i dati riservati escono più spesso che dalle schermate.
• I dati sporchi: nomi con apostrofi, indirizzi lunghissimi, importi a zero, allegati pesanti, righe duplicate.
• Le interruzioni: la connessione che cade a metà di un salvataggio, due persone che modificano lo stesso record, la stessa operazione inviata due volte.
• Le integrazioni quando l’altro sistema non risponde: che cosa vede l’utente, che cosa resta in sospeso, che cosa succede quando l’altro sistema torna disponibile.
• I momenti di chiusura, se il software li tratta in modo particolare.

Classificare i difetti invece di elencarli

Un elenco di sessanta segnalazioni senza classificazione blocca il progetto: nessuno sa da dove cominciare e ogni riunione diventa una trattativa. Bastano quattro categorie, concordate prima di iniziare.

• Bloccante: impedisce di lavorare e non esiste una via alternativa. Va corretto prima dell’avvio.
• Grave: si può lavorare, ma con un giro lungo o con rischio di errore. Va corretto prima dell’avvio o subito dopo, con una data.
• Minore: fastidio, forma, testo poco chiaro. Si raccoglie e si sistema in gruppo.
• Richiesta nuova: non è un difetto, è una funzione che non era prevista. Va riconosciuta come tale e valutata a parte.

La distinzione fra l’ultima categoria e le altre è quella che salva il progetto. Confondere una funzione mancante con un difetto sposta il costo su chi sviluppa e la data su tutti, e trasforma il collaudo in un cantiere senza fine.

Verificare le correzioni senza rompere il resto

Ogni correzione va verificata da chi ha aperto la segnalazione, non da chi l’ha risolta, rieseguendo la prova originale e non una simile. Insieme va ripetuto un gruppo ristretto di prove sui percorsi principali: le correzioni si portano dietro effetti collaterali, ed è normale che accada.

Conviene fissare un numero limitato di consegne durante il collaudo — per esempio una alla settimana — invece di correggere di continuo. Provare un sistema che cambia sotto le mani rende ogni risultato inaffidabile e ogni segnalazione discutibile.

Avvio, assistenza e via di ritorno

1. Decidete come si parte: tutti insieme, un reparto per volta, o in parallelo al sistema precedente per un periodo definito. Il parallelo è sicuro ma raddoppia il lavoro, quindi va dato un termine scritto.
2. Stabilite chi risponde nei primi giorni, dove si scrive e in quanto tempo si risponde. Le prime due settimane generano più domande di tutto il resto dell’anno.
3. Definite la via di ritorno: a quali condizioni si torna indietro, chi lo decide, e che fine fanno i dati inseriti nel frattempo. Se questa risposta non esiste, l’avvio è una scommessa.

Quello che questa guida non copre

Qui si parla di accettare processi con un risultato prevedibile: dato un ingresso, il sistema deve fare una cosa precisa, sempre la stessa. La verifica di sistemi che rispondono in modo probabilistico — assistenti e risponditori automatici, dove la stessa domanda può ricevere risposte diverse e la correttezza è una questione di grado — richiede un metodo differente, trattato altrove. Anche la scelta di che cosa entra nella prima versione di un gestionale ha una guida propria.