Qualità del software: il vero costo dei “problemi tecnici”

Quando una App di una banca o di un e-tailer si blocca, quando un portale di servizi sanitari non risponde, si parla comunemente di “problemi tecnici”. Una espressione generica che nasconde spesso una realtà ben diversa: nella maggior parte dei casi, questo disservizio ha origine non in un guasto hardware o in una Rete congestionata, ma in un software che non è stato adeguatamente testato.

Quando l’app si blocca: il costo nascosto dei “problemi tecnici”

A riprova del peso economico di queste interruzioni, i dati annuali di ITIC (Information Technology Intelligence Consulting) evidenziano che per oltre il 60% delle aziende enterprise, una singola ora di inattività dei sistemi critici comporta costi superiori ai 300.000 dollari, potendo superare il milione di euro nei casi più severi.

La qualità di un’applicazione è qualcosa di invisibile, spesso sottovalutata nonostante sia centrale per qualsiasi organizzazione che eroga servizi digitali. È infatti l’elemento che determina, da un lato, la disponibilità del servizio – ovvero la sua capacità di reggere sotto carico e di non interrompersi nei momenti più critici – e dall’altro la sua correttezza funzionale, cioè la garanzia che il sistema faccia esattamente ciò per cui è stato progettato. Ma non è tutto: la qualità del software è un anello imprescindibile anche della sicurezza, poiché attesta l’assenza di vulnerabilità che potrebbero compromettere dati, transazioni e identità degli utenti. Ignorare il software testing, o relegarlo a fase meramente residuale e compressa di un progetto IT, significa per le organizzazioni esporsi a rischi concreti su tutte e tre queste dimensioni.

Il debito di testing: il rischio invisibile che erode i servizi digitali

Nel mondo IT si parla molto di debito tecnico che identifica i costi progressivi causati da uno sviluppo software affrettato o con compromessi tecnici, come una funzione scritta male o un’architettura non scalabile. Ma, esiste un debito parallelo, altrettanto pericoloso e molto meno sotto attenzione: il debito di testing.

L’impatto di questa trascuratezza è macroscopico: secondo i report del CISQ (Consortium for Information & Software Quality), il Cost of Poor Software Quality (CPSQ) supera stabilmente i 2 trilioni di dollari all’anno nei soli Stati Uniti, e la fetta più ampia di questa spesa è dovuta proprio alla risoluzione di problemi operativi generati da difetti software non intercettati prima del rilascio.

Una ricaduta negativa che si manifesta ogni volta che un ciclo di sviluppo si chiude senza una copertura di test adeguata, per esempio quando il collaudo viene velocizzato per rispettare una scadenza o i test di regressione vengono saltati perché un aggiornamento sembra “di routine”. Le conseguenze non sono mai immediate: emergono mesi dopo, spesso in produzione, spesso sotto carico e molto spesso con l’utente finale.

I disservizi digitali più gravi, quelli che finiscono sui giornali, che aprono procedimenti di audit, che compromettono la reputazione dell’organizzazione, raramente derivano da un singolo bug; più spesso sono il risultato di un’erosione silenziosa della qualità dell’applicazione che non è stata davvero testata e quindi può fallire in qualsiasi momento e in qualsiasi condizione.

Il debito di testing non si manifesta solo con interruzioni di servizio — spesso nei momenti più critici, come picchi di vendita, scadenze fiscali o erogazione di prestazioni — con conseguente perdita di fiducia da parte degli utenti. Si traduce anche in vulnerabilità di sicurezza che emergono quando sono già state sfruttate e in costi di remediation esponenzialmente superiori rispetto a un approccio preventivo.

Il QA come strumento di governance

Ridurre il debito di testing richiede un cambiamento nel modo in cui le organizzazioni trattano la qualità del software adottando il Quality Assurance (QA) che non consiste in un semplice momento di collaudo finale, ma in un insieme di pratiche, processi e responsabilità che accompagnano lo sviluppo software dall’inizio alla fine, definendo in anticipo i criteri con cui un sistema può essere considerato pronto, pianificando test sistematici di funzionalità, di carico, di sicurezza e di regressione, e documentando sia i problemi trovati sia le decisioni prese.

Nelle organizzazioni che erogano servizi digitali, questo approccio non è solo una questione di efficienza operativa, è uno strumento di governance. La documentazione prodotta dai processi di QA — piani di collaudo, report sui difetti, criteri di accettazione — è la base su cui si fondano decisioni di rilascio, contratti di servizio e rendicontazioni. In altre parole, è la materia prima con cui un’organizzazione dimostra di avere il controllo su ciò che mette in produzione.

Un approccio maturo al QA consente di rispondere a domande che le organizzazioni si pongono quasi sempre solo dopo un incidente: il sistema era pronto per andare in produzione? Chi ha certificato cosa? Quali rischi erano stati identificati e quali erano stati accettati consapevolmente?

Non sorprende, quindi, che nelle grandi organizzazioni il QA stia evolvendo da funzione di controllo finale a una di monitoraggio continuativo di tutto il ciclo di vita del software. L’obiettivo non è più infatti soltanto trovare bug prima del rilascio, piuttosto costruire la qualità software in ogni fase per ridurre i rischi e garantire la continuità di servizi su cui le persone contano ogni giorno.

La qualità del software è molto più che un collaudo

Offrire servizi digitali efficienti è, in ultima analisi, una scommessa sull’affidabilità della tecnologia adottata. Ma una tecnologia affidabile non emerge per caso, è il risultato di processi e strumenti adeguati e di una cultura che considera la qualità del software centrale.

Troppe organizzazioni sono ancora legate a modelli tradizionali di sviluppo in cui il testing viene percepito come una fase finale, quasi un rito burocratico da espletare nel più breve tempo possibile. Eppure le analisi indicano inequivocabilmente che ogni difetto rilevato in produzione costa in media dieci volte di più rispetto a uno rilevato in fase di sviluppo.

Il futuro dei servizi digitali non passa solo dall’adozione di tecnologie innovative, ma da un cambio di paradigma: la qualità non può essere un effetto collaterale del processo. Deve diventare una leva di governo, integrata nei cruscotti progettuali e nei cicli di rilascio e sostenuta da una manutenzione continua; perchè anche dopo il go-live, ogni aggiornamento richiede test rigorosi per garantire affidabilità, sicurezza e continuità del servizio.

Tutto ciò in un’epoca in cui la credibilità di un’azienda, di un marchio o di un ente pubblico si misura anche, e sempre di più, sulla continuità e sul valore dei suoi servizi digitali. Non va sottovalutato infatti che le aspettative dei cittadini e utenti sono cresciute sotto la spinta dei livelli di servizio dei grandi player nativi digitali e quindi il loro giudizio come le loro scelte dipendono sempre più anche dalla qualità del software che sta dietro ogni loro esperienza online.