Strumenti, pratiche e metodologie che abilitano la qualità: il testing

Il software, ormai, è dappertutto: automobili, aerei, caldaie, case, pacemaker, apparecchi acustici e così via. La qualità del software è quindi una caratteristica che può fare la differenza nella nostra vita di ogni giorno: dobbiamo pensare ad un prodotto che funzioni come da specifiche, che, se fallisce, rimanga in controllo e in sicurezza, che possa essere manutenuto, modificato ed evoluto in modo semplice, continuando a garantire le performance desiderate.

La prima attenzione da avere a questo proposito è che non può esistere qualità senza test. La puntata di oggi affronta proprio l’argomento del testing, un processo cruciale per una Agile Digital Factory come la nostra.

Testing

Riteniamo un’automobile di qualità se è durevole nel tempo, se è comoda, se possiede tutti gli optional possibili ed immaginabili, ma soprattutto se è sicura. Tutti ci aspettiamo che le automobili disponibili in commercio in Italia siano sicure, giusto? Che abbiano superato test severi prima di poter essere considerate idonee a viaggiare su strada, come crash test per resistenza agli urti frontali, laterali e posteriori, sistemi di sicurezza attivi e passivi (airbag, ESP, ABS), ecc.

Ancora, salireste mai su un prototipo di aeroplano che non è stato testato accuratamente? Infine, dareste ad un neonato dell’acqua non indicata? E se l’acqua è dichiarata come indicata, vi aspettate che siano stati fatti i test del caso, vero? 

Anche per il software valgono le stesse regole. Quanto più un modulo è testato, tanto più il team si sentirà al sicuro nel continuare ad usarlo. Inoltre, se il modulo deve essere modificato in alcuni suoi comportamenti, il team avrà una fiducia maggiore che cambiamenti involontari al comportamento originale causeranno dei fallimenti in almeno uno dei test automatici del modulo. A patto che anche i test siano di buona qualità, questo significa una diminuzione del rischio di errori e regressioni ed un aumento della velocity del team.

 Entriamo meglio nel merito dell’argomento, introducendo il triangolo del testing.

Introduciamo rapidamente queste tipologie di test:

·      Unit tests: test automatici che verificano che ogni singola unità di codice funzioni correttamente, sia nei casi normali sia in quelli di errore. Per unità si intende solitamente una funzione o un metodo, quindi una porzione di codice limitata.

·      Integration tests: test automatici che verificano la corretta interazione tra diverse unità di codice che lavorano insieme (integrazione) per ottenere il comportamento desiderato, sia nei casi normali sia nei casi di errore.

·      UI tests: test automatici e/o manuali che interagiscono con l’interfaccia utente per verificare che i componenti integrati del sistema si comportino come atteso.

 Questa rappresentazione molto semplice permette con un colpo d’occhio di valutare diverse dimensioni.

La prima dimensione è l’effort richiesto per la scrittura ed il mantenimento dei test, ossia la freccia di sinistra. Questa indica che, quanto più ci spostiamo verso l’alto del triangolo, tanto più è complesso e costoso scrivere i test.

La seconda dimensione è l’esecuzione dei test, vale a dire la freccia di destra, che ci dà un’indicazione sulla durata attesa dei test, che è inferiore nella parte bassa del triangolo e tende ad aumentare salendo.

La terza dimensione è l’area delle sezioni di triangolo, che ci indica quanti test di quel tipo vogliamo avere in rapporto ai test totali. Potremmo considerarla come una dimensione derivata: visto che nel livello in basso i test sono più semplici da scrivere, ci costano meno, richiedono meno tempo per essere eseguiti e sono più efficaci, abilitando pratiche quali il Test Driven Development (TDD) ed il Behavior Driven Development (BDD), preferiamo scrivere molti più test di unità, meno test di integrazione ed ancora meno test di interfaccia.

Questa è sicuramente la versione più conosciuta del triangolo del testing, ma nel tempo ne sono nate altre, possiamo dire che quasi ogni team la personalizza in base alle proprie esigenze. Anche noi abbiamo sentito l’esigenza di costruire un triangolo che rispecchi meglio il nostro modo di lavorare e le pratiche che adottiamo nei progetti. L’obiettivo è quello di creare prodotti software su misura di qualità.

Vediamo velocemente tutti gli elementi nuovi rispetto al modello precedente.

·      Le fondamenta del nostro triangolo di test sono le pratiche di code quality che testiamo in modo rigoroso, in particolare relativamente alla sicurezza del codice e alla sua pulizia (efficienza, ottimizzazione, assenza di duplicazioni). Come le fondamenta di un edificio, le nostre pratiche di code quality non si vedono da fuori, ma sono essenziali per garantire una base di appoggio solida per la parte esterna. Lo consideriamo un requisito necessario ma non sufficiente per l’integrità strutturale del sistema informativo.

·      Gli integration test si dividono in due categorie: la prima è relativa ai Component and consumer driven contract tests, test di integrazione che si concentrano sui singoli componenti (classi, aggregati di classi, componenti della UI, …) e sulle integrazioni tra componenti e sistemi differenti.

·      La seconda categoria di integration test è composta dagli API tests, che verificano la corretta interazione con una o più API. Richiedono un environment completo in esecuzione. Rientrano tra questi test anche i test di performance.

·      Le nostre pipeline di CI/CD integrano l’esecuzione automatica dei check di analisi statica della code quality e dei test. Il fallimento di uno degli step annulla il rilascio delle funzionalità. L'obiettivo è elevare il livello di qualità, attraverso l’automazione dei test in modo da limitare al minimo le regressioni e portare in produzione un prodotto solido. Gli utenti finali, attraverso gli UAT, certificano in ultima istanza la bontà di quanto realizzato e la coerenza con le esigenze di business.

In questa puntata, cominciando a discutere degli strumenti e delle pratiche a supporto della qualità, siamo partiti dal testing, un processo cruciale per una Agile Digital Factory come la nostra. Nelle prossime puntate affronteremo altre pratiche a supporto della qualità del software. Stay tuned!

AUTORE

Mattia Ciriolo, Enterprise Architect in adesso.it.

Ci piacerebbe che questi articoli fossero anche uno spunto per aprire una discussione volta ad approfondire questi temi anche grazie alle vostre esperienze, opinioni e critiche, per cui ogni vostro commento è benvenuto.

📲Se trovi interessante questa puntata, ricordati di condividerla con la tua rete su LinkedIn!

Non ti vuoi perdere la prossima puntata? Iscriviti alla nostra newsletter per ricevere gli aggiornamenti sulle prossime puntate di "Inside Modern Applications". 🚀