Corso ISTQB — Modulo 3: Testing nel ciclo di vita di sviluppo del software

Questo modulo copre il capitolo 2 del syllabus e affronta una domanda che all’esame ritorna spesso: quando e come il testing si inserisce nel modo in cui un software viene costruito. Non basta sapere “come si prova un programma”: occorre capire che il momento e la frequenza con cui si testa dipendono dal modello di sviluppo scelto. La buona notizia è che molte domande di questa area sono di natura concettuale (riconoscere un livello di test, distinguere conferma da regressione, capire cosa significa shift-left): con definizioni nitide e qualche esempio mentale si portano a casa punti senza troppa fatica. È un’area che pesa nel computo complessivo delle domande, quindi conviene padroneggiarla.

Come il modello di sviluppo influenza il testing (syllabus §2.1)

Il ciclo di vita di sviluppo del software (in inglese SDLC, Software Development Lifecycle) è il modo organizzato in cui un gruppo di lavoro trasforma un’idea in software funzionante: analisi dei requisiti, progettazione, scrittura del codice, prove, rilascio, manutenzione. Il punto centrale per l’esame è che il testing non è un’attività relegata alla fine, ma cambia forma a seconda del modello adottato.

In un modello dove si pianifica tutto all’inizio e si rilascia di rado, le attività di test tendono a essere formali e addensate verso le fasi conclusive. In un modello dove si consegna un piccolo incremento ogni paio di settimane, il testing diventa continuo, ripetuto a ogni ciclo e fortemente automatizzato per reggere il ritmo. Una buona pratica trasversale, valida in qualunque modello, è che a ogni attività di sviluppo dovrebbe corrispondere una corrispondente attività di test: nel momento in cui qualcuno definisce i requisiti, qualcun altro dovrebbe già ragionare su come verificarli.

Esempio concreto: immagina un’app per la prenotazione di visite mediche. Con un modello sequenziale il gruppo redige l’intero documento dei requisiti, poi progetta, poi sviluppa per mesi e solo alla fine prova il sistema completo. Con un modello iterativo, invece, il primo ciclo produce soltanto la funzione “cerca un medico e consulta gli orari disponibili”, la si testa subito, e il ciclo seguente aggiunge “prenota e ricevi la conferma”.

Shift-left: anticipare il testing (syllabus §2.1)

L’espressione shift-left indica l’idea di spostare le attività di test verso sinistra lungo la linea temporale del progetto, cioè avviarle il prima possibile anziché rimandarle. Non vuol dire eliminare i test finali: vuol dire affiancarvi verifiche già nelle prime fasi.

La ragione è insieme economica e pratica: un difetto individuato mentre si scrive un requisito ambiguo costa pochissimo da rimuovere (basta riformulare una frase), mentre lo stesso difetto scoperto dopo il rilascio può imporre di rimettere mano al codice, ripetere i test e gestire utenti insoddisfatti. Anticipare il controllo abbatte in modo netto il costo della correzione.

Alcuni esempi di shift-left: revisionare i requisiti per stanare ambiguità prima di programmare; scrivere i test prima del codice (come nel test-driven development); far girare analisi statiche automatiche sul codice appena prodotto; coinvolgere i tester nelle riunioni di progettazione. Una raccomandazione tipica è introdurre lo shift-left per gradi: se il gruppo non è abituato, conviene partire da una singola pratica e ampliarla nel tempo, perché un cambiamento culturale imposto di colpo tende a non attecchire.

Buone pratiche, retrospettive e DevOps (syllabus §2.1)

Tra le buone pratiche legate al testing nel ciclo di vita rientrano la retrospettiva (a fine ciclo il gruppo si ferma per chiedersi cosa ha funzionato e cosa migliorare, anche sul fronte del testing), l’integrazione continua (ogni modifica al codice viene fusa di frequente e verificata in automatico) e l’inserimento del testing nei flussi DevOps, dove sviluppo e operations cooperano per rilasciare in modo rapido e affidabile. In questi contesti è proprio l’automazione dei test a garantire un riscontro veloce a ogni cambiamento.

Modelli sequenziali e modelli iterativi/incrementali (syllabus §2.1)

Per l’esame conviene tenere distinte due grandi famiglie.

Un modello sequenziale procede per fasi ordinate, una dopo l’altra: si conclude una fase prima di iniziare la successiva. L’esempio classico è il modello a cascata. Una variante che valorizza il testing è il modello a V, in cui a ogni fase di sviluppo (requisiti, progettazione di sistema, progettazione di dettaglio, codifica) si associa specularmente un livello di test pianificato fin dall’inizio. Attenzione a un equivoco frequente: il modello a V favorisce la pianificazione anticipata dei test, ma resta un modello sequenziale e l’esecuzione dei test avviene comunque dopo le rispettive fasi di sviluppo.

Un modello iterativo e incrementale costruisce il sistema a piccoli blocchi. Incrementale significa aggiungere funzionalità un pezzo alla volta; iterativo significa rivedere e raffinare ciò che si è già realizzato tramite cicli ripetuti. Gli approcci agili (per esempio Scrum) appartengono a questa famiglia. Qui ogni incremento va testato non appena è pronto e, poiché si continuano ad aggiungere parti nuove, diventa fondamentale ripetere prove già eseguite per assicurarsi che le novità non danneggino ciò che funzionava: per questo, in questi modelli, regressione e automazione assumono un peso particolare.

Livelli di test (syllabus §2.2)

I livelli di test sono raggruppamenti di attività organizzati in base all’oggetto che si sta provando e al momento in cui lo si prova. Il syllabus ne individua cinque.

Test di componente (detto anche test di unità): prova singoli pezzi di software in isolamento, per esempio una singola funzione che calcola lo sconto. Di norma lo eseguono gli sviluppatori, spesso con test automatizzati.
Test di integrazione dei componenti: verifica che i singoli componenti, una volta connessi tra loro, comunichino correttamente. Esempio: il modulo “carrello” che invoca il modulo “calcolo prezzo”.
Test di sistema: prova il comportamento del sistema nel suo insieme, end-to-end, dal punto di vista dell’intero prodotto. Esempio: percorrere l’intero flusso di acquisto sull’app, dall’accesso al pagamento.
Test di integrazione di sistema: verifica che il nostro sistema si integri correttamente con sistemi esterni o di terze parti. Esempio: la nostra app che dialoga con il gateway di pagamento di una banca e con un servizio di geolocalizzazione esterno.
Test di accettazione: stabilisce se il sistema è pronto per l’uso e soddisfa le esigenze degli utenti o del committente. Spesso lo conducono utenti o clienti.

Due precisazioni utili. Primo: i livelli si distinguono per oggetto del test e per obiettivo, e non vanno confusi con i tipi di test (vedi sotto). Secondo: l’elenco non rappresenta una scala di “dimensioni crescenti” rigida; in particolare il test di integrazione dei componenti collega parti interne al sistema, mentre il test di integrazione di sistema collega il nostro sistema con il mondo esterno: sono attività diverse, da non scambiare.

Tipi di test (syllabus §2.3)

Mentre i livelli rispondono a “cosa e quando“, i tipi di test rispondono a “quale caratteristica stiamo verificando”. I principali sono:

Test funzionale: verifica cosa fa il sistema, cioè se le funzionalità producono i risultati attesi. Esempio: inserendo un codice sconto valido, il prezzo finale si riduce correttamente.
Test non funzionale: verifica come il sistema si comporta in termini di qualità: prestazioni, sicurezza, usabilità, affidabilità, compatibilità e così via. Esempio: la pagina di ricerca risponde entro due secondi anche con mille utenti collegati contemporaneamente.
Test black-box (basato su comportamento): i test si progettano osservando ingressi e uscite dall’esterno, senza fare riferimento al codice interno. È legato alle specifiche e alle aspettative sul comportamento.
Test white-box (basato sulla struttura): i test si progettano conoscendo la struttura interna, per esempio il codice, allo scopo di coprirne gli elementi come istruzioni o decisioni.

Distinzione che ricorre spesso all’esame: funzionale / non funzionale riguarda cosa si verifica, mentre black-box / white-box riguarda su quale base si progettano i test. Sono assi indipendenti: si possono fare test funzionali in modalità black-box oppure test strutturali white-box, e le combinazioni sono lecite.

Test di conferma e test di regressione (syllabus §2.3)

Questi due concetti sono tra i più richiesti, perché vengono di frequente scambiati.

Il test di conferma (in inglese confirmation testing, o re-test) serve a verificare che un difetto sia stato davvero corretto: si riesegue il caso di test che aveva fatto emergere il problema e ci si attende che ora superi la prova. Esempio: il pulsante “Paga” non funzionava su un certo browser; dopo la correzione lo riprovo proprio su quel browser.

Il test di regressione serve invece a verificare che una modifica (una correzione oppure una nuova funzionalità) non abbia introdotto difetti in parti del software che prima funzionavano. Il principio è che intervenire su un punto può, involontariamente, comprometterne un altro. Esempio: dopo aver sistemato il pulsante “Paga”, ricontrollo anche il calcolo del totale e l’invio dell’email di conferma, pur non avendoli toccati. Poiché i test di regressione vanno ripetuti molte volte, sono tra i primi candidati all’automazione.

Test di manutenzione e analisi di impatto (syllabus §2.4)

Dopo il rilascio, il software continua a cambiare: correzioni, aggiornamenti, nuove funzioni, adeguamenti normativi, migrazioni di ambiente. Il test di manutenzione è il testing eseguito su un sistema già in esercizio quando questo viene modificato, per accertarsi che le modifiche funzionino e che il resto non si sia guastato.

Strumento chiave in questo contesto è l’analisi di impatto: prima di intervenire si valuta quali parti del sistema potrebbero risentire del cambiamento, così da decidere quali test di regressione eseguire. Una buona analisi di impatto evita due estremi: testare tutto inutilmente (costoso) oppure testare troppo poco e lasciar passare effetti collaterali. Esempio: aggiorno la libreria che gestisce le date; l’analisi di impatto suggerisce che potrebbero risultarne coinvolte la prenotazione, lo storico e i promemoria, quindi concentrerò la regressione su quelle aree.

Test alpha e test beta (syllabus §2.2)

Sono due forme particolari di test di accettazione, utili soprattutto per il software destinato a molti utenti.

Test alpha: si svolge presso l’organizzazione che sviluppa il software, ma non a opera del gruppo che lo ha scritto; tipicamente lo conducono potenziali utenti o un gruppo interno indipendente, nell’ambiente del produttore.
Test beta: si svolge presso gli utenti reali, nel loro ambiente, fuori dall’organizzazione produttrice. È il classico “rilascio in beta” a un insieme di clienti che provano il prodotto sul campo e segnalano i problemi riscontrati.

Regola mnemonica: alpha = nell’ambiente del produttore; beta = nell’ambiente dell’utente.

Termini chiave

SDLC (ciclo di vita di sviluppo) = il processo organizzato con cui un software viene ideato, costruito, rilasciato e mantenuto.
Shift-left = pratica di avviare le attività di test il più presto possibile nel ciclo di vita, per scoprire i difetti quando costano meno.
Modello sequenziale = approccio in cui le fasi si succedono in ordine, ciascuna conclusa prima della successiva (es. cascata, modello a V).
Modello iterativo e incrementale = approccio che costruisce il software a blocchi successivi, raffinandoli attraverso cicli ripetuti (es. agile).
Livello di test = gruppo di attività di test organizzato in base all’oggetto provato e al momento (componente, integrazione componenti, sistema, integrazione di sistema, accettazione).
Tipo di test = categoria di test definita dalla caratteristica verificata o dalla base di progettazione (funzionale, non funzionale, black-box, white-box).
Test di conferma = riesecuzione di un test prima fallito per accertare che il difetto sia stato corretto.
Test di regressione = test che verifica che una modifica non abbia danneggiato parti prima funzionanti.
Test di manutenzione = testing eseguito su un sistema in esercizio quando viene modificato.
Analisi di impatto = valutazione di quali parti del sistema sono toccate da una modifica, per mirare la regressione.
Test alpha = test di accettazione svolto presso il produttore, ma non dal gruppo di sviluppo.
Test beta = test di accettazione svolto dagli utenti reali nel loro ambiente.

Errori comuni all’esame

Confondere conferma e regressione. La conferma riprova il difetto corretto; la regressione controlla che il resto non si sia rotto. È probabilmente lo scambio più frequente nelle domande.
Pensare che shift-left significhi “niente test finali”. Significa aggiungere verifiche presto, non rimuovere quelle successive.
Ritenere che il modello a V non sia sequenziale. Lo è: pianifica i test in anticipo ma li esegue dopo le fasi di sviluppo.
Mescolare livelli e tipi di test. “Test di sistema” è un livello, “test non funzionale” è un tipo: una stessa attività può essere un test di sistema di tipo non funzionale.
Scambiare integrazione dei componenti con integrazione di sistema. La prima collega parti interne al sistema, la seconda collega il sistema con sistemi esterni.
Invertire alpha e beta. Promemoria: alpha presso il produttore, beta presso gli utenti.
Associare un livello a un solo responsabile fisso. Chi esegue un livello può variare a seconda del contesto; non dare per scontato, ad esempio, che il test di sistema lo conducano sempre gli sviluppatori.

In sintesi

Il modo di sviluppare (sequenziale oppure iterativo/incrementale) determina quando e con quale frequenza si testa; in ogni caso a ogni attività di sviluppo dovrebbe corrispondere un’attività di test.
Shift-left = anticipare le verifiche per ridurre il costo dei difetti; va introdotto per gradi.
I cinque livelli (componente, integrazione componenti, sistema, integrazione di sistema, accettazione) si distinguono per oggetto e obiettivo, non per pura dimensione.
I tipi di test rispondono a quale qualità si verifica: funzionale/non funzionale e, sul piano della progettazione, black-box/white-box.
Conferma = il difetto è stato risolto? Regressione = ho rotto qualcos’altro? La regressione è il candidato ideale all’automazione.
La manutenzione si appoggia all’analisi di impatto per mirare i test; alpha sta presso il produttore, beta presso gli utenti.