Glossario · Fondamenti del testing
Risk-based testing (test basato sul rischio)
In inglese: Risk-based testing
Detto anche: test basato sul rischio, testing basato sul rischio, risk based testing, strategia di test basata sul rischio
Definizione
Approccio che assegna le priorità ai test in base al rischio, cioè probabilità di guasto per impatto, così le aree più rischiose vengono testate prima e più a fondo.
Il risk-based testing (test basato sul rischio) accetta che non si possa mai testare tutto e decide dove investire il tempo in base al rischio. A ogni funzionalità o area viene assegnato un punteggio per la probabilità di guasto (complessità, quantità di modifiche, difetti passati, tecnologia nuova) e per l’impatto in caso di guasto (denaro, sicurezza, dati, esposizione legale, numero di utenti). Le aree ad alto rischio ricevono test più precoci, più approfonditi e più vari; quelle a basso rischio controlli più leggeri.
Esempio
Un rilascio tocca quattro aree. Assegna a ciascuna un punteggio da 1 a 5:
| Area | Probabilità | Impatto | Rischio (P x I) | Profondità dei test |
|---|---|---|---|---|
| Migrazione del provider di pagamento | 5 | 5 | 25 | Test funzionali completi, negativi, di integrazione, di performance, esplorativi |
| Nuove regole fiscali per una regione | 4 | 4 | 16 | Test sui valori limite e con tabelle decisionali, regressione dei totali |
| Pagina profilo ridisegnata | 3 | 2 | 6 | Flussi principali più un controllo visivo |
| Aggiornamento di un link nel footer | 1 | 1 | 1 | Controllo rapido |
Se la scadenza viene anticipata di due giorni, sai già cosa tagliare: la profondità sulle righe a basso rischio, non la migrazione dei pagamenti.
Perché è importante
Ogni piano di test fa dei compromessi. Il risk-based testing li rende espliciti e condivisi. Offre anche un modo chiaro per riportare lo stato: “tutte le aree ad alto rischio testate, due rischi medi testati in parte, restano queste lacune note” è molto più utile per decidere un rilascio di “eseguito l’83% dei test case”.
Errori comuni
- Assegnare i punteggi da soli. I product owner conoscono l’impatto, gli sviluppatori la probabilità. Valutate i rischi insieme.
- Assegnare i punteggi una volta sola. I rischi cambiano man mano che arriva codice e compaiono bug. Un modulo che continua a produrre difetti deve salire in classifica.
- Ignorare del tutto le aree a basso rischio. Rischio più basso significa test più leggeri, non assenza di test. Di solito è la regressione automatizzata a coprire questa base.
- Confonderlo con la severità dei bug. La severità valuta un difetto già trovato. Il rischio è una stima fatta prima di testare, usata per decidere dove guardare.