Ogni software che usate in azienda si appoggia a decine di pezzi scritti da altri. Ogni tanto quei pezzi vanno aggiornati, di solito per chiudere una falla di sicurezza. Il programma riparte, le pagine si aprono, nessuno vede errori. E a volte una regola che prima funzionava ha smesso di funzionare. Senza avvisare nessuno.
Mi è capitato più di una volta, sui miei progetti. Meglio che se ne accorga un test automatico, prima di un cliente arrabbiato. Vi spiego cos'è in parole semplici, e cosa chiedere a chi vi sviluppa il software.
Perché non si può smettere di aggiornare
Un gestionale, un sito con area clienti o un'app su misura non è fatto solo del codice del vostro fornitore. Usa componenti già pronti: quello che legge i file caricati, quello che manda le mail, quello che parla con il database. Sono come i pezzi di ricambio di un'auto. Il meccanico non costruisce i freni, li monta.
Quando in uno di quei pezzi si scopre una falla, esce una versione corretta. Restare sulla vecchia vuol dire tenere aperta una porta che tutti ormai sanno dove trovare. Quindi si aggiorna, e va bene così. Il punto è cosa succede dopo.
Come un aggiornamento cambia le regole senza un errore
Prendiamo un esempio inventato ma realistico. Un negozio online fa uno sconto del 10% solo agli iscritti alla newsletter. La regola sta in un'impostazione di un componente esterno, quello che gestisce il carrello.
Esce un aggiornamento di sicurezza e il fornitore lo installa. Nella nuova versione quell'impostazione ha cambiato nome. Il codice del negozio usa ancora il nome vecchio, e il componente semplicemente lo ignora. Nessun messaggio d'errore, nessuna pagina bianca. Il sito vende come prima.
Solo che adesso lo sconto va a tutti. Oppure non va a nessuno, e gli iscritti scrivono all'assistenza. Nel primo caso ve ne accorgete quando guardate i margini a fine mese. Nel secondo, quando qualcuno si è già lamentato.
In un'app che tratta foto o dati sanitari, la regola che smette di funzionare può essere una protezione dei dati. Lì non si parla più di margini: si parla di quello che avete promesso ai vostri clienti.
Cos'è un test automatico, senza gergo
Un test automatico è una prova scritta una volta e ripetuta dal computer ogni volta che si cambia qualcosa. Per lo sconto sarebbe più o meno così: «un cliente non iscritto mette nel carrello un prodotto da 100 euro, il totale deve essere 100; un cliente iscritto fa lo stesso, il totale deve essere 90».
Ci vogliono pochi secondi per farla girare. Il fornitore la fa partire prima di ogni aggiornamento. Se il totale non torna, la prova diventa rossa e l'aggiornamento non va in produzione finché qualcuno non ha capito perché.
Il valore del test sta proprio qui: controlla il comportamento, cioè quello che vede il cliente, e non il codice. Il codice può sembrare identico a prima e fare un'altra cosa.
Il test che dice sempre di sì
C'è una trappola poco conosciuta. Un test può smettere di controllare e continuare a dare esito positivo. Immaginate un controllo che deve verificare che ogni pagina riservata chieda la password. Dopo un aggiornamento, il controllo non trova più nessuna pagina da verificare. Zero pagine controllate, zero problemi trovati: verde.
Per questo un buon fornitore verifica anche il contrario. Toglie apposta la regola e guarda se il test diventa rosso. Un test che non avete mai visto fallire non sapete se funziona.
Cosa chiedere al vostro fornitore
Non serve saper programmare per fare queste domande. Servono per capire se il software che pagate è tenuto sotto controllo o se si spera che vada bene.
- Ci sono test automatici sulle regole che valgono soldi o dati? Prezzi, sconti, permessi, scadenze, privacy. Si parte da quello che costa caro se si rompe.
- Chi controlla i componenti esterni, e ogni quanto? Esistono strumenti che segnalano da soli le falle note nei pezzi usati. Chiedete se girano e chi legge gli avvisi.
- Cosa succede dopo un aggiornamento? La risposta giusta è «girano i test, e se uno è rosso non si pubblica». La risposta da approfondire è «lo proviamo un po' a mano».
- Un test ha mai fermato un aggiornamento? Se la risposta è sì, è un buon segno: vuol dire che i test controllano davvero qualcosa.
- Se il fornitore cambia, i test restano? Fanno parte del progetto che pagate. Devono stare nel vostro repository, insieme al codice.
Quanto costa
Scrivere test costa tempo, quindi soldi. Ma non va fatto su tutto. Su un gestionale medio le regole davvero delicate sono poche decine. Una prova per ciascuna richiede qualche ora, e poi lavora gratis per anni.
Il conto da fare è l'altro: quanto vi costa uno sconto sbagliato per un mese, un cliente che non riesce a entrare, o una promessa sulla privacy che non viene più rispettata e nessuno lo sa.
Per chi è tecnico. Le due trappole più comuni sono di questo tipo. La prima: il codice assegna un'impostazione a un componente di terzi, il componente in una versione nuova la rinomina, e l'assegnazione con il nome vecchio non dà errore ma nessuno la legge più. La seconda: un test scorre un elenco (rotte, file, tabelle) e controlla ogni elemento; se dopo l'aggiornamento l'elenco risulta vuoto, il ciclo non gira e il test passa. Le difese sono semplici: un test che rilegge il valore dal nome attuale e ne prova l'effetto, un controllo che l'elenco non sia vuoto prima del ciclo, e l'audit delle dipendenze dentro la suite di test, così l'avviso arriva insieme ai risultati.
Di aggiornamenti di sicurezza ho scritto anche a proposito delle due falle critiche in PHP di ottobre, con i passi che ho seguito sui miei servizi. Se volete capire quanto è protetto il software che usate, o farvene costruire uno con i test giusti fin dall'inizio, ne parliamo nella prima chiamata gratuita.