La dura verità sul software a zero difetti
Molti anni fa, il giorno in cui decidemmo di rilasciare un importante aggiornamento al nostro prodotto, una decisione che ovviamente richiedeva la mia approvazione come Direttore del Controllo Qualità (QA), stavo camminando lungo il corridoio e l'amministratore delegato mi passò davanti.
Si fermò e mi disse: “Quindi posso presumere che spediamo senza difetti?”
Senza riflettere quanto probabilmente avrei dovuto, risposi allegramente: “Certo che no. Non esiste un software senza difetti.”
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Lui rimase sbalordito e inorridito dalla mia risposta. Era così turbato da terminare la nostra conversazione e allontanarsi furiosamente lungo il corridoio.
All'epoca attribuii questo al fatto che fosse nuovo nel settore del software e nei suoi cicli di vita, provenendo dal settore dell'editoria (una lunga storia—un'altra volta). Perché tutti i membri del team di sviluppo sapevano che stavamo spedendo con difetti. Ma sapevamo quali fossero tali difetti fin dall'inizio, e questo faceva tutta la differenza nella nostra valutazione del rischio.
Sto però notando, con preoccupazione, che recentemente questa falsa convinzione, da parte del mio ex CEO, è diventata sempre più diffusa nel nostro settore. Il software senza bug, il “software a zero difetti”, è una nuova vanteria/mantra che vedo e sento sempre più spesso. E non solo da amministratori delegati ignari (ridondante, lo so), ma da persone del settore che dovrebbero saperne di più. E che in realtà lo sanno. Il che trovo davvero preoccupante.
C’è un senso in cui il pensiero del "zero difetti" non è solo un’assurdità menzognera e autoreferenziale. In occidente è per lo più aria fritta e atteggiamento di circostanza. Ma in Giappone ha davvero un significato. In tutte le sue industrie.
Ho lavorato in Giappone per un anno, e questo mi sconvolse, ma in senso positivo. Perché la loro definizione di "difetto" è molto diversa dalla nostra. Ad esempio, se viene trovato un involucro di gomma da masticare sul pavimento della fabbrica, questo è considerato un difetto, tanto quanto lo è un problema con i macchinari o con l'output di un processo. Se davvero prendessimo sul serio lo "zero difetti", ci occuperemmo di questa questione come fanno i giapponesi. Ma non lo facciamo, quindi non lo faremo.
Quello che cercavo di dire a quel povero CEO, forse in modo troppo brusco, è che qualsiasi software commerciale moderno è infinitamente complesso, e i modi in cui può interagire con se stesso o con il suo ambiente sono quindi anch'essi infiniti. È possibile trovare ogni difetto solo se si ha a disposizione un tempo infinito per testare. Ma nessuno di noi è immortale.
Anche se potessi trovare ogni singolo difetto al primo colpo, non avresti il tempo di correggerli tutti e spedire un prodotto in questo secolo—il time-to-market è una realtà. Quindi, anche se trovati, dovrai spedire comunque con loro.
Quindi l’intera nozione di “software a zero difetti” è intrinsecamente illusoria fin dall’inizio.
Da dove nasce la nozione di software a zero difetti?
La radice di questa illusione è che il ruolo del QA sia “garantire” la qualità. Non è così. Questo è compito del Product Management e dell’Ingegneria. Il ruolo dell’assicurazione qualità è *valutare* quanto siano stati bravi in questo.
Ma c'è un altro strato insidioso in questo problema.
Di recente stavo discutendo proprio di questo tema con uno sviluppatore software. Mi ha fatto notare che il modo in cui gli era stato spiegato il significato di “software a zero difetti” era proprio quello che ho appena detto sopra. Significa spedire dopo aver risolto tutti i bug che il team ha deciso di correggere per rilasciare. E poi spedire con tutti i difetti che hanno scelto di non correggere. Una definizione con cui il mio interlocutore, per inciso, non era d’accordo.
Questa è chiaramente solo una farsa definitoria. In realtà state spedendo con difetti, e lo sapete, ma utilizzate lo slogan dello "zero difetti" per nascondere questo fatto a voi stessi—e al management, ovviamente. Che, come sappiamo tutti, è facilmente ipnotizzato da slogan vuoti che li fanno sentire di successo.
Si tratta solo di una riduzione selettiva dei difetti, nulla di più.
Come usciamo dalla farsa dello zero difetti?
E il fondamento di questa farsa è la lingua stessa, una lingua che modella e vincola il nostro pensiero ancor prima che possiamo iniziare a rispondere concettualmente a ciò che si sta affermando. È proprio questo linguaggio falso che crea in primo luogo la situazione in cui bisogna spiegare perché è sbagliata. E così finiamo per essere messi alle strette dal vocabolario di uno slogan.
Questa è una pratica molto comune nello sviluppo software. Purtroppo non si limita a mentire a noi stessi sullo "zero difetti". Contamina ogni livello del nostro pensiero e delle nostre azioni, come collaudatori, nel processo di sviluppo, nelle nostre metodologie e nelle nostre metriche.
Ascolta, iniziamo ad affrontare la realtà su ciò che stiamo facendo e su ciò che non stiamo facendo. E il primo passo verso questa presa di coscienza è usare un linguaggio che descriva onestamente ciò che facciamo e ciò che non facciamo. Perché se già il modo in cui comunichiamo queste realtà è a sua volta fondamentalmente fraudolento, disonesto e illusorio, non stiamo producendo software di alta qualità. Stiamo fabbricando propaganda.
L'altro problema con il discorso del “software a zero difetti” è che anche se questo è un obiettivo sinceramente condiviso — nel senso che le persone credono sinceramente che sia possibile, e non si tratta solo di un esercizio di cinismo — un altro problema, più serio, limita l'utilità di questa idea. Quel problema è il seguente:
Come si potrebbe mai sapere, e dimostrare, di aver trovato "tutti" i difetti presenti nel software in fase di test? E non solo il numero di difetti che si è riusciti a trovare nel tempo a disposizione? Come potresti dimostrare a te stesso che l’insieme dei bug trovati è l’insieme completo dei bug effettivamente contenuti dal software?
Non puoi. Perché ciò richiederebbe un processo esterno al QA stesso per determinarlo. Altrimenti è solo un ragionamento circolare. E quale sarebbe questo processo esterno?
E questo è vero, qualunque sia il numero di bug che hai già trovato. Potresti averne trovati un milione. Questo non dimostra che non ce ne sia un milione e uno nascosto tra le ombre del software.
C'è Qualcosa di Valido Nel Concetto di Zero Difetti?
I lampanti problemi logici ed epistemologici nel parlare e pensare in termini di “software a zero difetti” sono semplicemente insormontabili. Lo stesso epiteto è irrecuperabile, qualunque sia la sua riformulazione.
Ma se guardiamo oltre lo slogan ingannevole, verso ciò che lo rende attraente e concettualmente valido per persone altrimenti razionali, possiamo trovare qualcosa su cui valga la pena focalizzarsi.
Quel “qualcosa” è una domanda diversa, ma che risponde ai bisogni pratici ed emotivi apparentemente soddisfatti dal falso discorso del software a zero difetti, e lo fa in modo più coerente e difendibile.
La questione con cui, facendo ricorso all’autoinganno, le persone che lavorano nel software cercano davvero di fare i conti è in realtà ingannevolmente semplice. Ovvero: “Quando sappiamo di poter smettere di testare?”
È l’unica domanda che faccio ai candidati per ruoli di leadership QA nella mia organizzazione. Perché, davvero, è l’unica domanda a cui il QA deve rispondere. E se non può farlo, il QA è una totale perdita di tempo. Per rispondere a quella domanda, dobbiamo prima rispondere ad una domanda anteriore.
Zero Difetti vs % Copertura dei Test
Come facciamo a sapere se i difetti già trovati — qualunque sia il loro numero — possono essere plausibilmente accettati come rappresentativi della soglia di rischio creata dalle modalità con cui il software in test è stato specificato e ingegnerizzato? Vale a dire: possiamo affermare con fiducia che i difetti residui e ancora inosservati rappresentano un rischio accettabile per una decisione di rilascio al pubblico?
Posta in questi termini, vediamo che questa domanda non riguarda affatto i difetti. Si tratta di una domanda sulla copertura dei test. La tua analisi dei bug trovati, per quanto numerosi, non significa nulla se non può essere correlata con — e confrontata rispetto ad — una comprensione analitica della copertura dei test raggiunta finora dallo sforzo QA, rispetto alla copertura ancora da raggiungere.
Perché se quell’insieme di difetti noti, qualunque sia il tempo dedicato a testare, rappresenta soltanto il 30% di reale copertura dei test — e non lo sai — allora non hai alcuna base razionale per comprendere cosa questo significhi in relazione alla decisione di pubblicare il software.
La reale discussione e il vero obiettivo di ogni sforzo QA davvero efficace non può riguardare i “difetti zero”, ma deve riguardare la “copertura dei test al 100%”. Per la ragione che ho illustrato sopra.
Il grande vantaggio di questo modo di pensare la qualità del software è che si basa su una definizione della copertura dei test adeguata, effettuata dal QA stesso prima dell’avvio dei test. Questa definizione può quindi essere verificata rispetto a specifiche, requisiti, problemi riscontrati dai clienti in passato ed esigenze dei clienti, ecc., e modificata se necessario.
Guardare Avanti: Copertura dei Test Senza Lacune
Pensare a questo problema in termini di difetti fallisce proprio perché non è qualcosa che può essere definito in modo significativo in anticipo, poiché il numero e la gravità dei problemi possono essere scoperti solo dopo l’esecuzione dei test.
Inoltre, non viene misurato rispetto a una definizione preesistente (e significativa) di ciò che la soglia di “zero” potrebbe effettivamente rappresentare. È una perdita di tempo definire il successo in base a una variabile che è essa stessa indefinita e indefinibile.
Ecco perché l’unico modo per salvare l’idea del software a zero difetti è indirizzare quel pensiero e quell’attività di pianificazione verso una copertura dei test senza lacune. La motivazione dietro il mantra dello zero difetti non è sbagliata in sé. È semplicemente stata rivolta a un obiettivo sbagliato. Aggiusta il tiro, e diventa possibile avere definizioni significative e misurabili di qualità software accettabile.
Se sei pronto a saperne di più e a imparare da esperti e CEO, ecco un podcast che pensiamo possa interessarti: TEAMWORK, AI, E CONTAINERIZZAZIONE (CON MICHAEL RITCHSON DELLA NASA)
Lettura correlata: I 10 MIGLIORI STRUMENTI DI TRACCIAMENTO DEI DIFETTI PER IL SOFTWARE TESTING
