Nel 2002, il National Institute of Standards and Technology (NIST) ha pubblicato un rapporto che descriveva in dettaglio l'impatto economico di test software inadeguati (Rapporto NIST, 2002). Il rapporto concludeva che:
“… si stima che i costi annuali nazionali di un’infrastruttura inadeguata per i test del software varino da 22,2 miliardi di dollari a 59,5 miliardi di dollari.”
Il rapporto del NIST ha inoltre evidenziato che lo stato delle pratiche di test del software era tristemente carente.
Sette anni dopo, Wong et al., in un rapporto della IEEE Reliability Society (Wong et al., 2009), hanno esaminato 15 guasti software ampiamente pubblicizzati, molti dei quali hanno portato alla perdita di vite umane, e hanno concluso che:
“…è necessario implementare procedure e pratiche di test migliori, e questo è particolarmente vero per il software correlato ai sistemi critici per la sicurezza.”
In un articolo più recente, Wong et al. hanno esaminato una serie di guasti software in diversi settori (Wong et al., 2017) e hanno sollevato un punto piuttosto serio:
“…la deludente verità è che il software è tutt’altro che privo di difetti e ogni anno vengono spese ingenti somme di denaro per riparare o mantenere software (difettoso).”
L'articolo ha analizzato i guasti software in un periodo di 30 anni, dal 1985 al 2015; ha identificato la natura dei bug software che hanno causato i guasti, insieme ad altri fattori contribuenti, come l'errore dell'utente; e ha classificato i guasti in due categorie: quelli fatali (che hanno causato la perdita di vite umane) e quelli che non sono stati fatali ma hanno causato una perdita economica sostanziale. I guasti fatali includevano l'incidente del Therac-25 del 1985, in cui almeno sei pazienti hanno ricevuto dosi eccessive di radiazioni, così come gli incidenti dell'aviazione civile tra il 1995 e il 1997, in cui hanno perso la vita più di 650 persone. Includeva anche l'incidente dell'Ebola del 2014 in cui un guasto del software delle cartelle cliniche elettroniche ha causato la diagnosi errata di un paziente infetto da Ebola, con conseguente decesso. I guasti non fatali includevano un guasto del software di una centrale nucleare, che ha causato una perdita di 2 milioni di dollari, così come il guasto del software dell'Ariane 5, che ha causato una perdita di 7 miliardi di dollari. Nella loro conclusione, gli autori hanno offerto la seguente osservazione:
“… l’ubiquità del software incorporato nelle infrastrutture pubbliche, nei sistemi di trasporto, nei prodotti di consumo e altro ancora ci lascia increduli che qualcuno che ha lavorato su sistemi software complessi possa credere che sia possibile costruire tali sistemi senza difetti…”
Purtroppo, nonostante questi resoconti seri sui tipi di sistemi software da cui dipendiamo sempre di più, manca un punto chiave in queste discussioni. Vale a dire, la maggior parte dei guasti software non vengono rilevati e segnalati. In alcuni casi, il guasto è sottile, o addirittura intermittente, e quindi è facilmente trascurabile. Ad esempio, un'applicazione software statistica può presentare statistiche calcolate in modo errato. Tali statistiche calcolate in modo errato sono guasti, ma potrebbero non essere immediatamente evidenti, soprattutto a un non esperto. Tuttavia, tali guasti possono portare a decisioni errate o subottimali e potrebbero quindi avere conseguenze molto gravi.
È evidente che l'arte di scrivere software, indipendentemente dalla complessità degli ambienti di sviluppo integrati utilizzati, dalla complessità dei metodi di programmazione o dall'abilità dei programmatori, è un'arte imperfetta e darà luogo a bug. Questa realtà significa che spetta al rigore dello sforzo di test del software scoprire questi bug prima che il software venga rilasciato. Come indicano NIST e Wong et. al., il fallimento in questo può portare a conseguenze significative. Barry Boehm, una figura iconica nella comunità dell'ingegneria del software, ha sottolineato nel suo articolo fondamentale sull'economia dell'ingegneria del software (Boehm, 1984), che il costo per trovare e correggere un bug dopo la distribuzione del software è solitamente almeno 100 volte superiore all'identificazione e alla correzione del bug prima della distribuzione.
Considerato questo contesto, è allora vero che i metodi di test del software sono semplicemente inadeguati? Io sostengo che non è così. In effetti, la ricerca sui test del software è stata un'area di indagine solida per oltre 50 anni. Nel 2014, Orso e Rothermel hanno scritto dei notevoli progressi nello sviluppo di metodi di test del software nei 15 anni precedenti al loro articolo (Orso e Rothermel, 2014). Il periodo di 15 anni precedente al 2000 è stato anche un periodo di sviluppo drammatico nei metodi di test del software. Glenford Myers (Myers, 1978) e Boris Beizer (Beizer, 1984), due figure iconiche nella comunità dei test del software, hanno svolto il loro lavoro pionieristico negli anni '70 e '80. Purtroppo, il problema principale è l'adozione, non l'adeguatezza dei metodi di test. La comunità di sviluppo software è stata lenta nell'adottare metodi rigorosi di test del software nel corso degli anni, nonostante le prove empiriche disponibili della loro utilità (Kuhn et. al., 2015, Morgan, 2018). Questa situazione è stata esacerbata da due realtà dello sviluppo software. Gli sforzi di test del software sono notoriamente sottofinanziati e sottorisorse. Inoltre, la velocità e la complessità degli sforzi di sviluppo software sono cresciute drasticamente negli ultimi anni
I sistemi software sono ora più pervasivi che mai e svolgono un ruolo sempre più importante nelle nostre vite. L'importanza critica di metodi di testing software robusti è evidente ed è un aspetto dello sviluppo software di cui tutti i professionisti dello sviluppo software devono essere più consapevoli. Per rispondere a questa esigenza, abbiamo intrapreso questa serie di post del blog. Questo post è il secondo di quella serie e ne arriveranno altri.
Opere citate
Beizer, Boris. Test del sistema software e garanzia della qualità . Van Nostrand Reinhold Co., 1984.
Boehm, Barry W. “Economia dell'ingegneria del software”. Transazioni IEEE sull'ingegneria del software (1984): 4-21.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). “Test combinatorio: teoria e pratica.” Advances in computers , 99 , 1-66.
Myers, Glenford J. “Un esperimento controllato nei test del programma e nelle verifiche/ispezioni del codice”. Comunicazioni dell'ACM 21.9 (1978): 760-768.
Morgan, J. (2018). “Test combinatorio: un approccio ai test di sistemi e software basato su array di copertura”. Metodi analitici nei test di sistemi e software , 131-158.
Rapporto NIST. "Gli impatti economici di infrastrutture inadeguate per il test del software". National Institute of Standards and Technology Planning Report 02-3. Maggio 2002.
Orso, A., e Rothermel, G. (2014) “Software testing: un diario di viaggio di ricerca (2000–2014)”, in Proceedings on the Future of Software Engineering , ACM, maggio 2014, pp. 117–132
Wong, W. Eric, Vidroha Debroy e Andrew Restrepo. "Il ruolo del software nei recenti incidenti catastrofici". IEEE Reliability Society 2009 Annual Technology Report 59.3 (2009).
Wong, W. Eric, Xuelin Li e Philip A. Laplante. "Conosciamo meglio i nostri nemici e spianiamo la strada: una revisione dei ruoli che i bug hanno svolto nei guasti del software". Journal of Systems and Software 133 (2017): 68-94.
Il test combinatorio (vedi sotto per i riferimenti dal post) è un approccio al test che si concentra sui difetti dovuti alle interazioni. L'oggetto matematico sottostante è un array di copertura e quindi è un approccio altamente efficiente, anche quando ci sono migliaia di input! Questo sarà un argomento di un blog futuro.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). “Test combinatorio: teoria e pratica.” Advances in computers , 99 , 1-66.
Morgan, J. (2018). “Test combinatorio: un approccio ai test di sistemi e software basato su array di copertura”. Metodi analitici nei test di sistemi e software , 131-158.
@Vins , ci sono metodi in fase di sviluppo per farlo. Quindi, la risposta è "Sì e Sì". Solo poche settimane fa, al MEMOCODE-2024 ( https://memocode2024.github.io/program.html ), il nostro collega ha presentato un discorso su questo. L'idea è di usare l'analisi bayesiana per guidare la selezione dei casi di test successivi (vale a dire, un metodo di progettazione di casi di test sequenziali). Il titolo del documento è:
"MaLT: progettazione di casi di test guidati dall'apprendimento automatico e localizzazione degli errori di sistemi software complessi."
Gli atti della conferenza MEMOCODE-2024 saranno presto disponibili, ma potresti trovare l'articolo se fai una ricerca su Google Scholar sul titolo. Probabilmente ne parlerò un po' nel mio blog sui test combinatori.
