Corso ISTQB — Modulo 7: Pianificazione del test e gestione del rischio

Quando un gruppo di lavoro decide cosa testare, quanto testare e in quale ordine, sta già facendo gestione del rischio, anche senza chiamarla così. Testare in modo esaustivo è impossibile (lo abbiamo visto fra i principi del testing): le combinazioni di input, stati e condizioni d’esecuzione sono troppe per provarle tutte. Serve perciò un metodo per concentrare lo sforzo dove conta davvero. Questo modulo unisce due parti del capitolo 5 del syllabus che conviene leggere insieme: la pianificazione del test (come si organizza e si documenta l’attività) e la gestione del rischio (come si decide dove puntare). All’esame CTFL questi temi pesano in modo significativo e spesso le domande intrecciano i due piani: per esempio chiedono come il rischio influenza i criteri di uscita o la priorità dei casi di test. Vale la pena capirli a fondo, non solo memorizzarli.

A cosa serve il piano di test

Il piano di test è il documento che descrive gli obiettivi del testing per un determinato progetto o rilascio e i mezzi per raggiungerli. Non è un adempimento burocratico fine a sé stesso: serve a far sì che tutte le persone coinvolte (sviluppatori, tester, responsabili di progetto, parti interessate) condividano la stessa idea di che cosa significhi \”abbiamo testato a sufficienza\”. Pianificare obbliga a ragionare in anticipo su risorse, scadenze, dipendenze e rischi, invece di improvvisare quando il tempo stringe.

Immaginiamo un’organizzazione che sviluppa un’app per la prenotazione di visite mediche. Senza un piano, ogni tester andrebbe per conto proprio: uno si concentra sull’accesso, un altro sui pagamenti, e nessuno verifica la gestione delle cancellazioni perché tutti la danno per scontata. Il piano mette nero su bianco l’ambito (che cosa rientra e che cosa resta fuori), chi fa cosa, con quali strumenti e ambienti, e in quali tempi. È anche uno strumento vivo: si aggiorna mentre il progetto evolve e si scoprono elementi nuovi.

In genere un piano di test affronta: il contesto e gli obiettivi del testing, l’ambito (incluso ciò che esplicitamente non verrà testato), l’approccio e le tecniche scelte, i criteri di ingresso e di uscita, le attività di test e la loro pianificazione temporale, i ruoli e le responsabilità, gli ambienti e gli strumenti necessari, e i rischi da tenere d’occhio. Il piano collega inoltre il testing alla strategia complessiva di sviluppo e alle altre attività del progetto (syllabus §5.1).

Criteri di ingresso e di uscita

Due concetti che l’esame mette spesso alla prova. I criteri di ingresso (in inglese entry criteria) stabiliscono le precondizioni da soddisfare prima di iniziare una certa attività di test. Servono a non sprecare tempo testando qualcosa che non è ancora pronto. Esempio: prima di avviare il test di sistema sull’app medica, l’ambiente di test deve essere configurato, i dati di prova devono essere caricati e tutte le funzionalità del rilascio devono risultare installate e avviabili.

I criteri di uscita (in inglese exit criteria) stabiliscono le condizioni che devono valere per poter dichiarare conclusa un’attività di test. Esempio: tutti i casi di test pianificati sono stati eseguiti, non restano difetti aperti di gravità alta, la copertura ha raggiunto la soglia concordata, oppure il tempo o il budget previsti si sono esauriti. Attenzione a un punto che genera molta confusione: l’esaurimento del tempo o del budget è di per sé un criterio di uscita legittimo nella pratica, anche se non è quello \”ideale\”. Un criterio di uscita non significa solo \”abbiamo finito i test\”, ma può anche significare \”sono finite le risorse\”. Nei contesti agili, le condizioni che corrispondono ai criteri di ingresso e di uscita sono spesso espresse tramite la definition of ready e la definition of done; il concetto è analogo, anche se la formulazione differisce (syllabus §5.1.3).

Stimare lo sforzo di test

Stimare significa prevedere quanto lavoro, tempo e quante risorse serviranno per le attività di test. È un’attività difficile perché dipende da molti fattori: complessità del prodotto, qualità delle specifiche, esperienza del team, stabilità dell’ambiente, numero di difetti che ci si aspetta di trovare e correggere. Il syllabus presenta due tecniche di base che conviene saper distinguere:

Tecnica basata su metriche (metrics-based): si stima a partire da dati storici raccolti in progetti passati simili. Se in un progetto analogo abbiamo impiegato in media due giorni per testare ogni storia utente, possiamo proiettare lo stesso valore sul progetto attuale. È un approccio oggettivo, ma richiede di disporre di dati storici affidabili.
Tecnica basata sul giudizio degli esperti (expert-based): ci si affida all’esperienza e al parere di chi conosce il dominio o le attività da svolgere. È utile quando mancano dati storici o quando il progetto differisce molto dai precedenti, ma è più soggettiva.

Nella realtà le due tecniche spesso si combinano. Un esempio è la stima a tre punti (ottimistica, più probabile, pessimistica), che porta a un valore mediato unendo giudizio e calcolo (syllabus §5.1.4).

La piramide dei test

La piramide dei test è un modello che suggerisce come distribuire i test automatizzati su livelli diversi. Alla base, ampia, stanno i test di componente (unit test): numerosi, veloci, economici da scrivere ed eseguire, e isolati. Salendo si trovano i test di integrazione, in numero minore. In cima, stretta, ci sono i test di sistema o end-to-end che attraversano l’intera applicazione: pochi, lenti, costosi e più fragili.

L’idea è che più si sale di livello, più i test sono ampi nel coprire il comportamento del sistema, ma anche più lenti e difficili da mantenere. Conviene quindi avere molti test rapidi alla base e pochi test costosi in cima. Un anti-pattern noto è il \”cono gelato\” rovesciato: pochissimi unit test e una grande quantità di test end-to-end manuali o lenti, che rendono la suite fragile e onerosa. La piramide non va presa come una regola matematica rigida, ma come una linea guida sulle proporzioni; il numero esatto di livelli può variare a seconda del progetto (syllabus §5.1.6).

I quadranti di test

I quadranti di test (testing quadrants, modello attribuito a Brian Marick) aiutano a ragionare su tutti i tipi di test che servono, evitando di concentrarsi su una sola categoria. Il modello incrocia due dimensioni: da un lato i test che supportano il team (guidano lo sviluppo) contro quelli che criticano il prodotto (valutano ciò che è stato costruito); dall’altro i test orientati al business contro quelli orientati alla tecnologia.

Dall’incrocio nascono quattro quadranti. Per dare un’idea concreta: i test di componente e di integrazione (tecnologia, supporto al team), spesso automatizzati; i test funzionali, gli esempi e i prototipi che chiariscono i requisiti (business, supporto al team); i test esplorativi, di usabilità e le demo con gli utenti (business, critica del prodotto), tipicamente manuali; i test di prestazione, sicurezza e affidabilità (tecnologia, critica del prodotto), che si appoggiano a strumenti dedicati. Il messaggio chiave per l’esame: serve un mix bilanciato di test automatici e manuali, e insieme di test che guidano lo sviluppo e di test che lo verificano (syllabus §5.1.7).

Rischio: probabilità per impatto

In ambito testing, un rischio è un possibile evento futuro con conseguenze negative. Il suo livello si misura combinando due fattori: la probabilità che l’evento si verifichi e l’impatto (il danno) che provocherebbe se accadesse. Concettualmente: livello di rischio = probabilità × impatto. Questo non significa che si calcoli sempre un numero preciso; spesso si usano scale qualitative (basso, medio, alto), ma il ragionamento resta lo stesso.

Un esempio: nell’app medica, un difetto nel modulo che calcola il dosaggio di un farmaco ha impatto altissimo (rischio per la salute) anche se la probabilità che si verifichi è bassa; un piccolo disallineamento grafico nella pagina \”Chi siamo\” ha impatto trascurabile pur essendo molto probabile. Il primo merita molta più attenzione di test del secondo, pur risultando meno probabile. È l’effetto combinato dei due fattori che conta (syllabus §5.2.1).

Rischio di prodotto e rischio di progetto

Il syllabus distingue nettamente due categorie, e l’esame ci insiste molto.

Rischio di prodotto: riguarda la possibilità che il prodotto software in sé sia carente in qualche caratteristica di qualità (funzionalità errata, prestazioni scarse, dati corrotti, vulnerabilità di sicurezza). In altre parole, è il rischio che il prodotto possa nuocere a qualcuno o non soddisfare i bisogni degli utenti. Esempio: il pagamento della visita addebita un importo errato. Il testing agisce direttamente su questo tipo di rischio.
Rischio di progetto: riguarda la possibilità che il progetto non raggiunga i propri obiettivi di gestione: ritardi nelle consegne, ambiente di test non pronto in tempo, abbandono di una persona chiave del team, fornitore che non consegna un componente. Questi rischi minacciano la capacità di portare a termine il lavoro, non la qualità intrinseca del software.

Aiuto mnemonico: il rischio di prodotto è \”il software è difettoso\”, il rischio di progetto è \”il progetto va storto\” (per tempi, risorse, organizzazione). Una domanda d’esame classica fornisce uno scenario e chiede di classificare ciascun rischio nelle due categorie (syllabus §5.2.2).

Il testing basato sul rischio

Il testing basato sul rischio (risk-based testing) è l’approccio che usa l’analisi dei rischi di prodotto per guidare l’intero processo di test. In pratica si individuano i rischi, se ne valuta il livello (probabilità × impatto) tramite l’analisi del rischio, e si usa questa valutazione per controllarlo: decidere dove concentrare lo sforzo, in che ordine eseguire i test e quando fermarsi (controllo del rischio).

Le conseguenze pratiche sono diverse. Le aree ad alto rischio vengono testate prima (così, se ci sono problemi seri, emergono presto e resta tempo per rimediare) e più a fondo (più casi di test, tecniche più rigorose). Le aree a basso rischio ricevono meno attenzione, o un controllo più leggero. L’analisi del rischio aiuta anche a definire i criteri di uscita: si può decidere di rilasciare quando tutti i rischi alti sono stati coperti e mitigati, accettando consapevolmente un rischio residuo sulle aree minori. È bene che l’analisi del rischio sia condotta coinvolgendo più punti di vista (tecnici e di business) e che venga rivista periodicamente, perché i rischi cambiano nel corso del progetto (syllabus §5.2.3 e §5.2.4).

Termini chiave

Piano di test = documento che descrive obiettivi, ambito, approccio, risorse e tempistiche delle attività di test per un progetto o un rilascio.
Criterio di ingresso = precondizione da soddisfare prima di poter iniziare un’attività di test.
Criterio di uscita = condizione che deve valere per poter dichiarare conclusa un’attività di test (incluso l’esaurimento di tempo o budget).
Stima del test = previsione dello sforzo, del tempo e delle risorse necessari al testing, condotta con dati storici (metrics-based) o con il giudizio di esperti (expert-based).
Piramide dei test = modello che propone molti test automatizzati di basso livello (unit) e pochi test di alto livello (end-to-end), per bilanciare velocità e copertura.
Quadranti di test = modello che classifica i tipi di test su due assi (supporto al team vs critica del prodotto; orientamento al business vs alla tecnologia) per assicurarne un mix completo.
Rischio = evento futuro possibile con conseguenze negative; il suo livello dipende dalla combinazione di probabilità e impatto.
Rischio di prodotto = rischio che il software sia carente in una caratteristica di qualità.
Rischio di progetto = rischio che il progetto non raggiunga i propri obiettivi (tempi, risorse, organizzazione).
Testing basato sul rischio = approccio che usa l’analisi dei rischi di prodotto per decidere priorità, profondità e ordine dei test e per controllare il rischio.

Errori comuni all’esame

Confondere rischio di prodotto e rischio di progetto. \”L’ambiente di test non è pronto\” è un rischio di progetto; \”la funzione di pagamento sbaglia l’importo\” è un rischio di prodotto. Rileggi sempre lo scenario chiedendoti: sta minacciando la qualità del software o la riuscita del progetto?
Pensare che l’unico criterio di uscita valido sia \”tutti i test superati\”. Anche l’esaurimento del tempo o del budget è un criterio di uscita legittimo. La domanda d’esame può proporti opzioni come \”il tempo pianificato è scaduto\” quale criterio di uscita corretto.
Scambiare criteri di ingresso e di uscita. Ingresso = condizioni per iniziare; uscita = condizioni per finire. Un tranello classico presenta un criterio di ingresso descritto come se fosse di uscita.
Credere che il livello di rischio dipenda solo dalla probabilità. Un evento improbabile ma con impatto catastrofico può essere ad alto rischio. È sempre la combinazione dei due fattori.
Interpretare la piramide dei test come una regola rigida. È un modello sulle proporzioni dei test automatizzati, non una legge da applicare al millimetro; il punto è \”tanti test veloci alla base, pochi lenti in cima\”.
Pensare che il testing basato sul rischio serva solo a decidere cosa testare. Influenza anche l’ordine (prima il rischio alto), la profondità e i criteri di uscita.

In sintesi

Il piano di test definisce obiettivi, ambito, approccio, ruoli, risorse, tempistiche e rischi; serve a far convergere tutti sullo stesso \”abbastanza testato\”.
I criteri di ingresso sono le precondizioni per iniziare; i criteri di uscita sono le condizioni per concludere (tempo e budget esauriti inclusi). Nei contesti agili corrispondono spesso a definition of ready e definition of done.
Le stime si fanno con dati storici (metrics-based) o con il giudizio degli esperti (expert-based), spesso combinandoli.
Piramide dei test e quadranti di test sono modelli che aiutano rispettivamente a bilanciare i livelli di automazione e a coprire tutti i tipi di test (manuali e automatici, business e tecnologia).
Il livello di rischio = probabilità × impatto; il rischio di prodotto riguarda la qualità del software, quello di progetto la riuscita del progetto.
Il testing basato sul rischio usa l’analisi dei rischi di prodotto per stabilire priorità, ordine, profondità dei test e criteri di uscita, coprendo prima e meglio le aree più rischiose.