Quando il test diventa l’arte di nascondere i problemi

Esiste un fenomeno affascinante nel mondo dello sviluppo software: la programmazione simbiotica accidentale. Due sistemi che comunicano perfettamente, scambiandosi dati senza apparenti problemi, funzionando in armonia come un meccanismo ben oliato. Poi scopri che entrambi condividono esattamente gli stessi bug, creati dallo stesso sviluppatore o coordinati dallo stesso team. Togli uno di questi bug e l’intero ecosistema crolla come un castello di carte durante un terremoto.

Questo è l’emblema della fragilità dei sistemi costruiti senza testing adeguato: funzionano solo per miracolo, collassano al minimo cambiamento, e lasciano futuri manutentori a maledire il giorno in cui hanno accettato il progetto.

La filosofia del “basta che funzioni”

Esiste un universo parallelo dove il testing semplicemente non esiste come concetto. In questo mondo, governato dalla filosofia del “basta che funzioni”, la qualità del codice è un lusso inutile. Il code review è tempo sprecato. Ritorni sul codice già scritto solo se assolutamente costretto da crash imbarazzanti in produzione.

La logica è cristallina nella sua semplicità: se il codice funziona ora, funzionerà per sempre. Come se il software fosse una statua di marmo invece che un organismo vivente che evolve, cambia, si adatta. Come se i requisiti non mutassero, le dipendenze non si aggiornassero, i contesti d’uso rimanessero congelati nel tempo.

Questa mentalità produce sistemi dove ogni modifica è un’avventura nel territorio inesplorato. Non sai mai cosa si romperà quando tocchi una riga di codice. Ogni deploy in produzione diventa una lotteria dove speri che i numeri estratti non siano quelli delle funzionalità critiche.

L’iceberg del testing vero

La punta visibile dell’iceberg sono quei pochi test superficiali che molti progetti implementano. La massa sommersa rappresenta l’enorme complessità che un testing veramente efficace dovrebbe avere. La distanza tra i due è abissale.

Comprendere concettualmente cosa sia un test unitario è facile. Scrivere suite di test complete, mantenibili, che aggiungano reale valore è tremendamente complesso. Il paradosso è crudele: per testare efficacemente un sistema devi comprenderlo profondamente, ma proprio quella comprensione ti rende soggetto agli stessi bias cognitivi che potrebbero averti portato a introdurre bug durante lo sviluppo.

Il Test Driven Development brilla nella teoria ma si scontra con la realtà dei requisiti in continua evoluzione. Il TDD presuppone chiarezza e stabilità che raramente esistono nei progetti reali. Quando i requisiti cambiano settimanalmente, i test scritti prima del codice diventano rapidamente obsoleti o fuorvianti.

Il mocking porta questa complessità a livelli surreali. Finisci per creare un universo parallelo fatto di simulazioni dove ogni componente è sostituito da un’imitazione. A quel punto sorge spontanea la domanda: stai testando il sistema reale o solo la tua capacità di immaginarlo? È come costruire un modellino in scala di una città per testare il traffico: incredibilmente utile ma straordinariamente complesso da realizzare correttamente.

La metrica ingannevole della copertura

C’è un mito pericoloso nel mondo del testing: la copertura del codice come misura di qualità. Raggiungere il 90% di code coverage sembra un traguardo impressionante. Fino a quando non realizzi che quei test verificano solo che il codice non vada in crash, non che faccia effettivamente la cosa giusta.

Puoi avere test che passano gloriosamente mentre il codice produce risultati completamente sbagliati. Puoi avere suite intere di test che verificano solo casi banali, ignorando tutti gli edge case problematici. La copertura misura quante righe vengono eseguite durante i test, non se quelle righe fanno la cosa corretta.

Ancora più paradossale è il fenomeno dei test che testano i test. Scrivi codice per verificare che il codice di test funzioni correttamente. A quel punto ti ritrovi in un loop meta-cognitivo dove non sei più sicuro di cosa stia realmente verificando cosa.

L’arte della mano grossa

Esisteva un tempo una tecnica raffinata per gestire i problemi durante le presentazioni. Quando proiettavi una demo del sistema, e c’era un malfunzionamento evidente, o una funzione che doveva esistere ma ancora non c’era, la soluzione era elegante: usare la mano come puntatore gigante per coprire strategicamente metà schermo.

Non stavi indicando un punto specifico, stavi letteralmente nascondendo il problema. Attiravi l’attenzione sulla parte funzionante dello schermo mentre la mano copriva quella rotta. Una metafora fisica perfetta di come affrontiamo le criticità nei progetti software: mascherando invece di risolvendo.

Questa mano gigante è l’incarnazione di tutte quelle pratiche che mirano a occultare piuttosto che sistemare. I test superficiali che danno l’illusione di qualità senza garantirla. Le demo accuratamente coreografate che evitano i path code problematici. Le presentazioni che mostrano solo i casi d’uso che funzionano.

Il problema non è solo estetico. Quando nascondi sistematicamente i problemi invece di affrontarli, accumuli debito tecnico esponenziale. Ogni bug mascherato diventa due bug nel futuro. Ogni funzionalità mancante nascosta diventa un ostacolo più grande quando finalmente devi implementarla.

System test e la documentazione fantasma

I test di sistema richiedono documentazione esaustiva che raramente esiste. Per testare significativamente serve comprensione approfondita di requisiti funzionali e non funzionali, casistiche limite, interazioni tra componenti. Informazioni che nel mondo reale sono documentate con la precisione di un oroscopo generico.

Come puoi scrivere test completi quando le specifiche sono vaghe, i requisiti cambiano oralmente durante caffè informali, e la documentazione ufficiale risale a tre versioni fa del prodotto? Finisci per testare quello che pensi il sistema dovrebbe fare, non necessariamente quello che fa o quello che dovrebbe effettivamente fare.

Trovare l’equilibrio pragmatico

Riconoscere la complessità del testing non significa concludere che sia futile. Al contrario, proprio la difficoltà ne sottolinea l’importanza. Ma serve un approccio pragmatico che riconosca vincoli reali di tempo e risorse.

L’obiettivo non è la perfezione teorica o la copertura al 100%. Quanti possono realmente affermare di avere mezzi per raggiungerla? L’obiettivo è massimizzare la riduzione del rischio entro limiti pratici del progetto. Concentrarsi sulle aree critiche, quelle dove i bug costano di più in termini economici o di reputazione.

Un testing efficace non è questione di aderenza dogmatica a metodologie, ma di intelligente allocazione di risorse limitate. Test sufficientemente robusti da catturare problemi reali, ma non così teoricamente perfetti da richiedere più tempo della scrittura del codice stesso.

La chiave sta nel costruire gradualmente una cultura che valorizzi qualità senza paralizzare lo sviluppo. Integrare test nel processo quotidiano, automatizzare dove possibile, documentare le assunzioni, revisionare il codice critico. È un percorso che richiede investimento e pazienza, ma produce software più robusto e basi di codice più manutenibili.

Dal rituale alla sostanza

Il rischio è che le pratiche di testing diventino gesti rituali che danno illusione di qualità senza garantirla. Come quella mano gigante che copre i problemi durante la demo, anche test mal concepiti possono mascherare fragilità invece di rivelarle.

Gli strumenti più potenti sono anche i più difficili da padroneggiare. Il TDD, il mocking, l’integration testing sono incredibilmente efficaci quando applicati correttamente.

La differenza tra testing efficace e teatro della qualità sta nell’onestà intellettuale. Ammettere i limiti, concentrarsi su ciò che conta, accettare che alcuni rischi rimarranno. Meglio pochi test significativi che coprono casi realmente problematici, che centinaia di test inutili che verificano l’ovvio ignorando il critico.

Il software perfetto non esiste. Software sufficientemente robusto da non crollare al primo cambiamento, sufficientemente testato da dare fiducia nel deploy, sufficientemente documentato da non essere un mistero per i futuri manutentori – questo è raggiungibile. Richiede disciplina, non perfezione. Pragmatismo, non dogmatismo.

La vera sfida non è scrivere test, è scrivere i test giusti. Quelli che ti salvano da disastri reali, non quelli che incrementano metriche senza senso. E quando trovi un bug, la risposta non dovrebbe essere nasconderlo con una grossa mano, ma chiederti perché i tuoi test non l’hanno catturato prima.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• Sistemista IT in una PMI: mansioni e competenze
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider
• Fortinet per Sistemisti: perché è lo standard nelle PMI italiane