Corso ISTQB — Modulo 4: Testing statico

Quando si pensa al testing, viene quasi sempre in mente l’idea di lanciare un programma e controllare cosa fa. Quella però è solo metà della storia. Esiste un’intera famiglia di tecniche che permette di trovare difetti senza mai eseguire il codice: è il testing statico. Per l’esame ISTQB CTFL questo capitolo (capitolo 3 del syllabus) vale alcune domande quasi garantite, soprattutto sui ruoli nelle revisioni e sui tipi di revisione. Sono argomenti che si imparano bene con un po’ di logica, e in questo modulo te li spiego con esempi concreti.

Che cos’è il testing statico e perché conviene

Il testing statico consiste nell’esaminare i prodotti di lavoro (codice, documenti, modelli) senza eseguirli. Si analizza ciò che è scritto, non ciò che il software fa quando gira. È l’opposto del testing dinamico, dove invece il software viene fatto funzionare con dei dati di ingresso per osservarne il comportamento.

Il punto chiave, e qui l’esame insiste molto, è il momento in cui si applica. Il testing statico può iniziare prestissimo, anche prima che esista una sola riga di codice: posso revisionare un documento di requisiti o un disegno di architettura. Questo è enorme dal punto di vista economico. Un requisito ambiguo individuato durante una revisione costa pochissimo da correggere; lo stesso requisito ambiguo che si trasforma in un difetto di codice, sfugge ai test e arriva in produzione può costare ordini di grandezza in più. Trovare i problemi prima riduce sia il costo di correzione sia il rischio di consegnare in ritardo.

Un esempio. Immagina un team che sviluppa l’app di prenotazione di una catena di palestre. Il documento dei requisiti dice “l’utente può disdire la prenotazione in anticipo” senza specificare quante ore prima. Un revisore attento segnala l’ambiguità in fase di analisi: bastano cinque minuti di chiarimento con il cliente. Se nessuno lo nota, lo sviluppatore sceglierà un valore a caso (diciamo 1 ora), il tester proverà lo scenario senza sapere quale sia la regola corretta, e il difetto verrà scoperto solo quando un cliente si lamenterà di non poter disdire. Stesso difetto, costo radicalmente diverso.

Cosa si può esaminare con il testing statico

Quasi ogni prodotto di lavoro leggibile può essere sottoposto a testing statico: specifiche dei requisiti, criteri di accettazione, diagrammi di architettura e di progettazione, codice sorgente, casi di test, user story, manuali utente, contratti e persino i modelli. La condizione è una sola: deve avere una struttura comprensibile, in modo che si possa ragionare su correttezza, completezza e coerenza.

Il testing statico non trova solo difetti. Ha anche un valore legato alle persone: migliora la comunicazione nel team, allinea tutti su una comprensione condivisa del prodotto e fa crescere chi è più giovane attraverso il confronto. Spesso una revisione produce, oltre alle correzioni, una migliore intesa tra chi scrive i requisiti e chi li implementa.

Le due grandi forme: revisioni e analisi statica

Il testing statico si divide in due grandi attività.

Revisioni (review): le svolgono le persone. Si leggono e discutono prodotti di lavoro per individuare anomalie. Vanno bene per qualunque documento, anche quelli che una macchina non saprebbe valutare (per esempio se un requisito è davvero ciò che vuole il cliente).
Analisi statica (static analysis): la svolgono gli strumenti automatici. Esaminano il codice sorgente o altri artefatti formali alla ricerca di problemi seguendo regole predefinite.

L’analisi statica trova cose come codice irraggiungibile (istruzioni che non verranno mai eseguite), variabili dichiarate e mai usate, violazioni delle convenzioni di scrittura del codice, possibili divisioni per zero, dipendenze tra moduli problematiche e vulnerabilità di sicurezza note. Tutto questo senza eseguire il programma. Strumenti come i linter, i compilatori con i warning attivi o le piattaforme di analisi della qualità del codice ricadono qui.

Una sfumatura importante: l’analisi statica trova difetti, non guasti (failure). Poiché non esegue il codice, non può osservare un comportamento sbagliato a runtime; può però segnalare la causa che lo provocherebbe. È una distinzione che all’esame torna spesso.

Testing statico contro testing dinamico

Vale la pena fissare bene le differenze, perché l’esame ama metterle a confronto.

Il testing statico trova difetti direttamente nel prodotto di lavoro. Il testing dinamico osserva i guasti e da lì si risale al difetto che li ha causati.
Alcuni difetti si trovano molto più facilmente con uno o con l’altro. Requisiti mancanti, contraddizioni nei documenti, codice non manutenibile e deviazioni dagli standard emergono meglio in statico. Comportamenti errati a runtime, problemi di prestazioni reali e questioni d’uso effettivo emergono solo in dinamico.
Il testing statico può rilevare difetti che con quello dinamico sarebbero difficili o costosi da scovare, e viceversa. Per questo le due forme sono complementari, non alternative: un buon processo le usa entrambe.

Esempio per fissare il concetto. Un requisito che dice “il sistema deve essere veloce” è un difetto evidente in revisione (non è verificabile, è vago) ma nessun test dinamico potrà mai dirti se è “giusto”, perché non c’è una soglia da misurare. Al contrario, un calcolo dell’IVA che produce un centesimo di differenza in certi arrotondamenti è quasi impossibile da vedere leggendo il codice, ma salta fuori al primo test dinamico mirato.

Il processo di revisione e le sue attività

Il syllabus descrive una revisione come un’attività strutturata, non come una lettura improvvisata. Le attività principali sono queste, e conviene ricordarne la logica più che l’elenco a memoria.

Pianificazione: si definisce l’ambito (cosa si revisiona), l’obiettivo, quali prodotti di lavoro, chi partecipa, quali criteri di ingresso e di uscita, e — quando serve — quali metriche raccogliere. Più formale è la revisione, più questa fase conta.
Avvio della revisione (initiate review): si distribuisce il materiale ai partecipanti e ci si assicura che tutti abbiano ciò che serve e abbiano capito ruoli e obiettivi.
Revisione individuale: ogni revisore esamina per conto proprio il prodotto di lavoro e annota possibili anomalie, domande e commenti. È qui che si trova la maggior parte dei difetti.
Comunicazione e analisi dei risultati (issue communication and analysis): le anomalie trovate vengono raccolte, discusse e valutate. Si decide quali sono difetti reali e quali no, si assegna una severità e si decidono le azioni.
Correzione e reportistica (fixing and reporting): si correggono i difetti (di solito è l’autore a farlo), si registra lo stato e si verifica se sono stati raggiunti i criteri di uscita.

Non tutte le revisioni passano per tutte le attività con lo stesso rigore: una revisione informale ne salta diverse, un’ispezione le segue tutte in modo disciplinato.

I ruoli in una revisione

Questa è una delle parti più “redditizie” per l’esame: le domande sui ruoli sono frequenti e si rispondono bene se conosci con precisione chi fa cosa. Attenzione a non confonderli.

Autore (author): chi ha creato il prodotto di lavoro sotto revisione. Di norma è anche chi corregge i difetti trovati. Ha tutto l’interesse a migliorare il proprio lavoro.
Management: chi pianifica la revisione, decide cosa revisionare, alloca tempo e risorse e tiene conto dei risultati a livello di processo. Non entra nel merito tecnico dei singoli difetti.
Facilitatore (facilitator, detto anche moderatore): garantisce che la riunione si svolga in modo efficace, mantiene il clima costruttivo, fa da mediatore tra i punti di vista e impedisce che la discussione degeneri o si perda. È la figura che “tiene insieme” la sessione.
Leader della revisione (review leader): ha la responsabilità complessiva della revisione, decide chi vi partecipa, quando e dove si svolge.
Revisori (reviewers): esaminano il prodotto di lavoro e individuano le anomalie. Possono essere esperti di dominio, colleghi sviluppatori, tester, persone con prospettive diverse. Sono il cuore operativo della revisione.
Scriba (scribe, detto anche recorder): raccoglie e registra le anomalie emerse e le decisioni prese durante la riunione, così che nulla vada perso.

Un trucco mnemonico: il facilitatore si occupa del come si svolge la riunione (il clima, la mediazione), mentre il leader si occupa del se, quando e con chi. Lo scriba scrive, i revisori trovano i difetti, l’autore li corregge, il management sta sopra il processo. Una stessa persona può ricoprire più ruoli in revisioni piccole, ma l’esame chiede la definizione “pura” di ciascuno.

I tipi di revisione

Le revisioni variano per grado di formalità, da una chiacchierata informale fino a un processo molto strutturato. Il syllabus elenca quattro tipi tipici, in ordine crescente di formalità. Memorizzarne le caratteristiche distintive è quasi obbligatorio per l’esame.

Revisione informale (informal review): nessun processo formale, niente documentazione obbligatoria dei risultati. Per esempio due colleghi che guardano insieme uno schermo. L’obiettivo principale è trovare anomalie con il minimo sforzo. Risultati molto variabili a seconda di chi partecipa.
Walkthrough: è l’autore a guidare i partecipanti attraverso il prodotto di lavoro, spiegandolo passo passo. Serve a valutare la qualità, a costruire una comprensione condivisa, a formare i partecipanti e a raccogliere idee. La preparazione individuale dei revisori è facoltativa.
Revisione tecnica (technical review): condotta da pari tecnicamente qualificati (peer). Punta a raggiungere consenso e a prendere decisioni tecniche, oltre che a individuare anomalie. La preparazione individuale è prevista; idealmente è presente un facilitatore, ma la revisione può svolgersi anche senza una figura dedicata.
Ispezione (inspection): è il tipo più formale. Segue un processo rigoroso e definito, con ruoli ben distribuiti, criteri di ingresso e di uscita, raccolta di metriche e preparazione individuale prevista. L’autore non può fare da leader della revisione né da scriba. Oltre a trovare difetti, mira a migliorare il processo di sviluppo stesso.

Per ricordarli, pensa a una scala: informale (zero burocrazia) → walkthrough (l’autore fa da guida) → tecnica (decidono gli esperti pari grado) → ispezione (massima formalità, metriche, ruoli rigidi). La parola chiave del walkthrough è “l’autore guida”; quella dell’ispezione è “formale, con metriche e regole sui ruoli”.

Fattori di successo delle revisioni

Una revisione può fallire non per come è progettata ma per come viene vissuta dalle persone. Il syllabus elenca alcuni fattori che ne determinano l’efficacia. I principali, raggruppati per tipo:

Fattori organizzativi: definire obiettivi chiari e misurabili per ogni revisione; scegliere il tipo di revisione adatto agli obiettivi, al prodotto e al team; dare tempo adeguato e inserire le revisioni nella pianificazione; revisionare in pezzi piccoli e circoscritti, perché revisioni troppo grandi affaticano e i revisori perdono concentrazione.
Fattori legati alle persone: coinvolgere le persone giuste con le competenze giuste; valorizzare i difetti trovati come un risultato positivo e non come una colpa; condurre la revisione in un clima di fiducia, mai come uno strumento di valutazione delle persone; evitare comportamenti che mettano l’autore sulla difensiva.

Il messaggio di fondo che l’esame vuole sentire è questo: una revisione serve a migliorare il prodotto, non a giudicare l’autore. Nel momento in cui le persone temono di essere punite per i difetti che emergono, smettono di collaborare e la revisione perde valore.

Termini chiave

Testing statico = esame di un prodotto di lavoro senza eseguirlo, per trovare difetti o valutarne la qualità.
Testing dinamico = esecuzione del software con dati di ingresso per osservarne il comportamento e individuare guasti.
Analisi statica = forma di testing statico eseguita da strumenti automatici su codice o artefatti formali, basata su regole predefinite.
Revisione = attività umana, strutturata in misura variabile, in cui si esamina un prodotto di lavoro per trovare anomalie e migliorarne la qualità.
Anomalia = qualsiasi cosa che diverge da ciò che ci si aspetta; in una revisione, un candidato difetto da valutare.
Walkthrough = revisione in cui è l’autore a guidare i partecipanti attraverso il prodotto di lavoro.
Ispezione = il tipo di revisione più formale, con processo rigoroso, ruoli definiti, criteri di ingresso/uscita e metriche.
Facilitatore = ruolo che garantisce lo svolgimento efficace e costruttivo della sessione di revisione.
Scriba = ruolo che registra anomalie e decisioni emerse durante la revisione.
Criteri di ingresso/uscita = condizioni che stabiliscono quando una revisione può iniziare e quando può considerarsi conclusa.

Errori comuni all’esame

Pensare che il testing statico esegua il codice. Non lo fa mai. Se una domanda parla di “esecuzione”, “dati di ingresso” o “comportamento a runtime”, sei nel dinamico.
Confondere difetti e guasti nell’analisi statica. L’analisi statica trova difetti direttamente; non osserva guasti, perché non manda in esecuzione nulla.
Scambiare facilitatore e leader. Il facilitatore cura il come della riunione (clima, mediazione); il leader decide se, quando, dove e con chi. Sono ruoli distinti.
Attribuire la guida del walkthrough al facilitatore. Nel walkthrough è l’autore a guidare. Questo è il dettaglio che distingue il walkthrough dagli altri tipi.
Dimenticare la regola dei ruoli nell’ispezione. Nell’ispezione l’autore non può fare da leader della revisione né da scriba: è una caratteristica tipica della massima formalità.
Credere che le revisioni servano solo per il codice. Si revisiona qualsiasi prodotto di lavoro leggibile: requisiti, contratti, casi di test, manuali, modelli.
Vedere statico e dinamico come alternative. Sono complementari: trovano difetti diversi e un buon processo li usa entrambi.

In sintesi

Il testing statico esamina i prodotti di lavoro senza eseguirli; può iniziare prestissimo e perciò abbatte costi e rischi trovando i difetti in anticipo.
Si articola in revisioni (fatte da persone) e analisi statica (fatta da strumenti); quest’ultima trova difetti, non guasti.
Statico e dinamico sono complementari: scoprono tipi di difetti differenti.
Il processo di revisione passa per pianificazione, avvio, revisione individuale, comunicazione/analisi dei risultati e correzione/reportistica.
Ricorda con precisione i ruoli (autore, management, facilitatore, leader della revisione, revisori, scriba) e i quattro tipi in ordine di formalità: informale, walkthrough, tecnica, ispezione.
Le revisioni riescono quando hanno obiettivi chiari, pezzi piccoli, le persone giuste e un clima di fiducia: servono a migliorare il prodotto, non a giudicare l’autore.