Far funzionare il software è solo metà del lavoro. Un buon software non va valutato solo sulla base del suo funzionamento ma anche sulla capacità dello stesso di adattarsi ai cambiamenti. Nel corso della vita di un software il cliente chiederà di apportare diverse modifiche a quanto realizzato in origine. Ignorare questo fatto porta a realizzare prodotti che nel medio-lungo periodo diventeranno sempre più instabili e difficili da manutenere. In alcuni casi il livello di entropia nel codice diventa tale per cui si è costretti a riprogettare il sistema da zero. E’ pertanto necessario attuare delle strategie al fine di ridurre al minimo i costi di manutenzione. Il testing è una delle tecniche che stanno alla base della progettazione di sistemi che ambiscono ad essere stabili, robusti, facilmente manutenibili e che mirano a durare nel tempo.

Benefici del testing

I test inducono a scrivere codice più chiaro e comprensibile. Un progetto che ambisce a durare nel corso del tempo deve essere progettato pensando al fatto che i membri del team di sviluppo cambieranno. Avere una code-base più chiara e leggibile favorisce il turnover degli sviluppatori e fa sì che il successo del progetto non venga messo a repentaglio dal fatto che uno o più sviluppatori decidano di cambiare aria.

“The majority of the cost of software is incurred after the software has been first deployed. […] If I want to make my code cheap, therefore, I should make it easy to read.” – Kent Beck

I test in un certo qual modo fungono da documentazione. Avere dei test ben scritti è come avere una sorta di README che descrive in che modo i vari componenti software funzionano e interagiscono tra loro. Ciò riduce i tempi di coordinamento tra i vari membri del team di sviluppo e ne favorisce il turnover.

“Tests are stories we tell the next generation of programmers on a project.” – Roy Osherove

I test aumentano la percezione del valore del prodotto sia da parte dei committenti che degli utenti finali. Nelle applicazioni prive di test automatici spesso sono proprio committenti e utenti a rilevare i bug. Ciò riduce notevolmente il valore del prodotto da essi percepito. I committenti che sottovalutano la qualità del prodotto sono più propensi a lamentarsi e a sottopagare lo sviluppo e la manutenzione dei prodotti in essere. Nei casi peggiori gli utenti, infastiditi dai bug riscontrati, smettono di usare il software causando al committente una perdita economica oltre che di immagine.

Il battito d’ali di una farfalla può provocare un uragano dall’altra parte del mondo’. Con questa frase possiamo riassumere quello che nella teoria del caos è definito effetto farfalla. Questo effetto è osservabile anche nello sviluppo del software. Un piccolo errore di valutazione in fase di progettazione potrebbe causare gravi colli di bottiglia in termini di velocità e prestazioni in futuro o peggio ancora compromettere il funzionamento di funzionalità mission-critical. I test automatici permettono di prevenire la catastrofe e di ridurre al minimo l’impatto che le modifiche hanno sulla stabilità del prodotto. Avere una suite di test permette infatti di rilasciare nuove funzionalità sicuri che tutto continuerà a funzionare come prima. Accorgersi di un errore prima di un rilascio in produzione è decisamente meglio di ricevere la chiamata di un cliente che lamenta un bug di venerdì sera alle 23:00.

“This can’t be overstated. If you want your systems to be flexible, write tests. If you want your systems to be reusable, write tests. If you want your systems to be maintainable, write tests.” – Robert C. Martin

Quanto costa scrivere i test?

Ci sono diverse correnti di pensiero. Secondo le linee guida del TDD (Test Driven Development) la stesura dei test richiede circa il 30% del tempo di sviluppo. Questo tempo va visto come un investimento che porterà i suoi frutti nel corso della vita del progetto. Costa sicuramente più riscrivere da zero un software ogni 2 anni piuttosto che investire costantemente il 30% in più sul testing.

Qualche dettaglio tecnico

Il testing è una materia piuttosto vasta. Esistono diversi approcci, strumenti e tipologie di test. Per quanto riguarda il back-end di una web application si distinguono unit, integration e functional test.

Gli unit test (o test unitari) servono a testare una piccola unità di codice come una funzione o una classe. Gli integration test (o test di integrazione) servono a testare l’interazione tra più unità di codice. Infine i functional test (o test funzionali) servono a verificare che il prodotto soddisfi i requisiti funzionali redatti dai project manager sulla base delle specifiche del cliente. Le tre tipologie di test sono necessarie e complementari.

Fino a che punto è necessario testare?

Il testing è una di quelle cose per cui è valido il principio di Pareto (o legge 80/20): se si vuol ottenere una copertura del 100%, sarà necessario impiegare il venti percento del tempo per testare l’ottanta percento delle funzionalità. Una code-coverage dell’ottanta percento è generalmente considerata ottima. Un approccio pragmatico è quello di testare accuratamente i componenti e le funzionalità mission-critical, limitando invece l’effort su funzionalità meno importanti.

Cosa ne pensano i ‘guru’ del software development?

Il testing è ovviamente un considerato una best-practice, ritenuta imprescindibile al fine di produrre del software longevo e di qualità.

“Good architecture and design are important; but the effect of a robust suite of tests is an order of magnitude greater. It’s so much greater because those tests enable you to improve the design.” – Robert C. Martin

Come trasmettere l’importanza del testing ai clienti

Immagino non sia sempre facile far percepire ai clienti il valore del testing. A mio avviso esso non va presentato come un optional ma come qualcosa di indispensabile. Facendo un’analogia con la vendita delle automobili paragonerei il testing alle dotazioni di sicurezza indispensabili (cinture di sicurezza, air bag) piuttosto che ad altre piacevolezze non indispensabili (cerchi in lega, vernice metallizzata). A livello commerciale il testing potrebbe essere l’elemento su cui far leva per trasmettere ai nostri clienti l’idea che i nostri prodotti sono oggettivamente di qualità superiore rispetto a quelli di molti nostri concorrenti. Se dovessi trasmettere tutto ciò ad un cliente riassumerei così:

“I nostri test sono una forma di garanzia della sanità funzionale dei nostri applicativi, a differenza di chi pretende di vendervi una soluzione senza avere nessuna metrica che misuri l’integrità del prodotto”