Leadership nel Test: Test Basato sul Rischio
Nota dell’editore: Benvenuto nella serie Leadership In Test del guru e consulente del testing software Paul Gerrard. La serie è progettata per aiutare i tester con qualche anno di esperienza—specialmente coloro che lavorano in team agile—a eccellere nei loro ruoli di responsabili del test e nella gestione.
Nell’articolo precedente abbiamo esaminato l’importanza dei modelli di test. Qui, approfondiremo il concetto di rischio e vi offriremo un manifesto di testing basato sul rischio che potete applicare al vostro metodo di test basato sul rischio.
Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando saranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul che vi consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di iscriverti, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!
I rischi, se si materializzano, hanno un effetto negativo sui nostri progetti. La gestione dei rischi significa riflettere su quali rischi esistano e adottare azioni per ridurne la probabilità, eliminarli, oppure ridurne l’impatto sugli obiettivi degli stakeholder.
In alcune aziende, la gestione del rischio viene praticata con precisione ingegneristica e matematica. Nel software, non è possibile essere molto precisi. La maggior parte delle organizzazioni non pratica ancora il testing basato sul rischio in modo sistematico. Ma esiste una ragione valida per questo: una volta identificati, i rischi del prodotto software sono spesso terribilmente difficili da valutare.
Dal punto di vista del testing e dell’assicurazione qualità, un rischio è una ‘modalità di fallimento di cui preoccuparsi’. Il testing basato sul rischio è la pratica di modellare potenziali modalità di fallimento di sistema come rischi di prodotto per supportare la definizione del perimetro del test, l’adattamento e la prioritizzazione.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
In questo articolo vi proporrò un manifesto del testing basato sul rischio. Esamineremo la gestione classica del rischio e vedremo come possiamo adattarla per renderla utile ai tester. Infine, analizzeremo alcune questioni pratiche e considerazioni che vi aiuteranno ad applicare il vostro metodo di test basato sul rischio.
- Rischio di progetto, di processo e di prodotto
- Un manifesto per il testing basato sul rischio
- L’approccio classico al rischio
- Rischio di prodotto e testing
- Aspetti pratici
- Il ruolo della gestione del rischio nel testing
Useremo questa definizione di rischio: Un rischio è una minaccia a uno o più obiettivi degli stakeholder di un progetto e ha una probabilità incerta.
Rischio di progetto, di processo e di prodotto
Esistono centinaia di libri sul rischio e sulla gestione del rischio che illustrano numerosi approcci per gestire il rischio a livello progettuale. Tipicamente, questi approcci si concentrano su quelli che chiameremo rischi di progetto e di processo, con forse un singolo rischio intitolato qualcosa come “fallimento nel soddisfare i requisiti”. Avere un unico rischio legato ai requisiti non è molto utile, perché non è che si possa davvero prioritizzare un rischio per il testing.
Esistono tre tipi di rischio software.
Rischio di progetto: Questi rischi riguardano il progetto nel suo contesto. I progetti normalmente hanno dipendenze esterne come la disponibilità di competenze, la dipendenza da fornitori esterni, scadenze fisse o vincoli quali un contratto a prezzo fisso. Le dipendenze esterne sono responsabilità della gestione di progetto.
Rischio di processo: Questi rischi riguardano principalmente l’interno del progetto e la pianificazione, il monitoraggio e il controllo del progetto sono sotto esame. I rischi tipici qui includono la sottovalutazione della complessità del progetto, dello sforzo o delle competenze richieste. La gestione interna di un progetto, come una buona pianificazione, il monitoraggio del progresso e il controllo sono tutte responsabilità della gestione di progetto.
Rischio di prodotto: Il rischio di prodotto è l'area di rischio principale di interesse per i tester. Questi rischi riguardano la definizione del prodotto, la stabilità (o l’assenza di stabilità) dei requisiti, la complessità del prodotto e la predisposizione agli errori della tecnologia.
D’ora in avanti ci concentreremo sui rischi di prodotto. Useremo il termine rischio di prodotto come segue:
Un rischio di prodotto rappresenta una modalità o uno schema di fallimento che sarebbe inaccettabile in un ambiente di produzione.
Un manifesto per il testing basato sul rischio
Nei progetti in cui verranno presi dei rischi (in tutti, pensiamo), i tester devono fornire visibilità dei rischi al management e proporre metodi affidabili di testing per affrontare questi rischi durante tutto il ciclo di progetto.
Questo è il compito della gestione – eseguire e/o sovrintendere alle seguenti attività di testing basato sul rischio:
L'approccio classico al rischio
Esistono molte varianti, ma l'approccio classico al rischio cerca di essere quantitativo.
Probabilità, conseguenza ed esposizione
Per valutare un rischio di prodotto dobbiamo capire quale sia la conseguenza di quella modalità di guasto. Se si verifica un guasto, diciamo che il rischio si materializza. Successivamente ci chiediamo “quanto è grave il rischio?”, conosciuto anche come esposizione.
Per determinare l'esposizione, valutiamo il rischio su due dimensioni:
- La probabilità (o possibilità) che un rischio si materializzi. Questo valore viene generalmente espresso come percentuale compresa (ma non inclusa) tra zero e 100 percento.
- La conseguenza (o impatto o perdita) di un rischio che si materializza. Questo rappresenta il costo potenziale del danno se si verifica questa modalità di guasto.
L'esposizione di un rischio – cioè quanto è grave – si calcola come prodotto della probabilità e della conseguenza.
Esposizione = Probabilità del rischio X Conseguenza del rischio.
L'approccio classico al rischio spesso non è supportato dalle tecnologie necessarie per una gestione efficiente. Le moderne soluzioni di gestione dei test colmano questa lacuna offrendo funzionalità pensate per il testing basato sul rischio.
Attribuzione quantitativa o qualitativa
Spesso è difficile prevedere il costo potenziale di un guasto. Senza ulteriori informazioni, è quasi impossibile stimare la probabilità di un guasto con molta certezza. Di conseguenza, la maggior parte dei professionisti utilizza scale semi-quantitative o qualitative per probabilità e conseguenza.
È comune utilizzare intervalli numerici da uno a cinque per entrambe le scale, offrendo valori possibili per l'esposizione da uno a venticinque. Tuttavia, pochi tester, sviluppatori o stakeholder assegnano questi numeri con piena sicurezza, quindi spesso si preferisce valutare direttamente l'esposizione al rischio utilizzando una scala da 1 a 5, oppure — ancora più semplicemente — una classificazione a colori (rosso, ambra, verde). Alcuni arrivano a dire che i rischi sono "in-scope" o "out of scope", ma secondo noi questa è una semplificazione eccessiva.
Che tu quantifichi o codifichi a colori i rischi esaminati, l'aspetto critico delle valutazioni del rischio non è il punteggio, ma le conversazioni e il dibattito che avvengono quando si assegnano e si discutono le valutazioni.
Per parafrasare Eisenhower, il piano di rischio è nulla, la pianificazione del rischio è tutto.
Se ti viene chiesto di valutare i rischi con una precisione superiore rispetto a scale da uno a tre (o cinque al massimo), dovresti davvero chiederti se i numeri che assegni abbiano un vero valore.
La valutazione numerica può dare un'impressione di rigore scientifico, ma se i numeri sono frutto di supposizioni ti stai solo illudendo. Se i numeri mettono in evidenza differenze di opinione, ad esempio se un utente dice “cinque” e lo sviluppatore dice ‘“uno!”, lì va avviata una conversazione perché aspettative o percezioni sono evidentemente diverse.
Fai attenzione all'uso di uno schema semplice del tipo "in-scope/out of scope" per i rischi. Potrebbe essere chiaro quali rischi devono essere gestiti tramite i test. Tuttavia, i progetti imparano e si adattano nel tempo e spesso subiscono ritardi, quindi è necessario scendere a compromessi. Se i rischi non vengono prioritizzati in qualche modo, dovrai rivederli tutti per decidere quali mantenere o rimuovere dallo scope.
Parleremo nel dettaglio di scope, prioritizzazione e scale nei prossimi articoli, quindi restate aggiornati.
Rischio di prodotto e testing
La discussione sui rischi (di prodotto) metterà in luce le preoccupazioni degli stakeholder in merito alla probabilità di fallimento in aree critiche del progetto o del sistema. Data una lista di rischi di prodotto, come possiamo tradurla in azioni e piani specifici per il testing? Prima di poter rispondere a questa domanda, dobbiamo capire meglio in che modo il testing influisce o condiziona le nostre valutazioni del rischio.
Il testing non riduce il rischio – Migliora le valutazioni del rischio
Spesso sentirai dire che "il testing riduce il rischio". Non è vero — il testing a volte può persino aumentare il rischio. Il mantra "il testing riduce il rischio" nasce dalla mancanza di comprensione sia dei rischi che del testing.
Supponiamo di aver identificato un rischio che una funzionalità o caratteristica possa fallire. Formuliamo un test e lo eseguiamo. Il test può avere esito positivo o negativo. In che modo l'esito di un test influisce sulla nostra valutazione del rischio?
Innanzitutto, i test non incidono sulla nostra comprensione delle conseguenze di un guasto. Le conseguenze di un guasto sono ciò che sono e il testing non le modifica.
Esistono quattro possibili esiti di un test e relativi impatti sulla probabilità del rischio. Sono riassunti in questa tabella:
| Aumenta la probabilità di rischio | Diminuisce la probabilità di rischio | |
| Il test viene superato | No. Un test superato può solo farci sentire più sicuri che una modalità di guasto non si verificherà. (Questo presuppone che i nostri test siano significativi). | Sì, col tempo. Più test eseguiamo che vengono superati, e più esploriamo scenari diversi, minore sarà la probabilità di fallimento. |
| Il test fallisce | Possibilmente, a seconda del tipo di fallimento. Ma la probabilità diminuisce col tempo. Avevamo previsto che questa modalità di fallimento si verificasse; la nostra scelta del test è stata confermata. Fortunatamente, ora possiamo correggere questo problema e concentrare i nostri test per ridurre il rischio di altri errori di questo tipo. | Poco probabile, a meno che non abbiamo valutato male il rischio. |
Eseguire test associati a un rischio specifico ci fornisce sempre più informazioni per affinare la nostra valutazione del rischio. Se i test falliscono, la nostra scelta viene confermata. Quando correggiamo e ritestiamo, man mano che i test vengono superati la nostra valutazione del rischio dovrebbe diminuire. Tuttavia, se continuiamo a scoprire nuovi o ulteriori bug, potremmo rivalutare il rischio come più alto.
Considera questo: se esegui un test e il risultato non influisce in alcun modo sulla tua valutazione delle probabilità, probabilmente è un test inutile.
Ora che hai compreso il potenziale dei test per informare la nostra valutazione del rischio, possiamo vedere come specificare i test a partire dalle descrizioni dei rischi.
Pianificazione dei test basata sul rischio
In qualità di tester, una volta identificato un rischio di prodotto rilevante, dobbiamo formulare una serie di test che dimostrino che quella modalità di fallimento è meno probabile. Ovviamente, il nostro approccio sarà quello di stimolare la modalità di fallimento in quanti più modi possibili e, così facendo, otterremo uno dei seguenti risultati:
- Sperimentiamo fallimenti, rileviamo bug e li correggiamo (riducendo il rischio di quella specifica modalità di fallimento) oppure
- Rileviamo successi e aumenta la nostra fiducia che una modalità di fallimento sia meno probabile.
Collettivamente, i nostri test si concentrano sui modi in cui può verificarsi una specifica modalità di fallimento selezionata. Supponiamo, ad esempio, che il rischio sia "calcolo errato del premio di un'assicurazione auto". In questo caso, un opportuno obiettivo di test potrebbe essere "dimostrare tramite la tecnica delle coppie per le variabili di input che il sistema calcola correttamente il premio RC Auto". Questo obiettivo di test può essere assegnato a un tester per derivare un insieme completo di casi di test, ad esempio usando la tecnica delle coppie.
Aspetti pratici
Vediamo ora alcune considerazioni pratiche che riguardano il testing basato sul rischio.
E se gli stakeholder non sono interessati ad aiutare nella valutazione del rischio?
Potresti scoprire che non è facile ottenere il tempo degli stakeholder per aiutarti a identificare e valutare i rischi e formulare il tuo piano di test.
E se ci sono più opzioni di test per un rischio di prodotto?
Questa è quasi sempre la situazione, ovviamente. Ad esempio, per testare una funzionalità critica potresti usare una varietà di tecniche di progettazione dei test, oppure modellare la funzionalità in modo originale e derivare da lì i test. Esistono diverse metriche di copertura che potresti adottare come obiettivo. Potresti testare una funzionalità manualmente, mediante uno strumento o altra tecnologia.
Vedremo come si possano effettuare delle scelte nel prossimo articolo, 'Quanto testing è sufficiente?'.
E se testare (per coprire un rischio) costasse troppo?
Poiché esistono quasi sempre diverse opzioni e non c’è un limite a quanto testing si possa svolgere per esplorare un rischio e supportare una valutazione, va fatta una scelta. Inutile dire che alcune opzioni saranno considerate troppo costose. Quindi, quando presenti le alternative agli stakeholder, dovrai avere almeno una opzione economicamente sostenibile e una che potrebbe risultare inaccessibile.
Di nuovo: vedremo come effettuare delle scelte nel prossimo articolo, 'Quanto testing è sufficiente?'
Se testiamo di più le funzionalità a rischio elevato, testiamo meno le altre, giusto?
Se il budget per il testing è prefissato per un team, oppure il numero di membri del team e dei tester è fissato, allora la quantità di test che si può effettuare è limitata (all'interno di un periodo di tempo prestabilito). Quindi, se si pone maggiore enfasi su alcune funzionalità, inevitabilmente i test sulle altre dovranno diminuire. La copertura, o comunque lo sforzo dedicato alle funzionalità, varia a seconda del rischio.
Il modo di vedere la cosa è che quando un test fallisce e viene trovato un bug nel sistema, la gravità assegnata al bug sarà probabilmente strettamente correlata alla conseguenza di tale fallimento (in produzione). I bug più gravi vengono corretti perché sono semplicemente più rilevanti per gli stakeholder.
Un'analisi dei rischi di prodotto mette in evidenza le aree dove i bug, essendo importanti, è più probabile che vengano sistemati. Quindi, usare un'analisi del rischio per evidenziare dove effettuare i test, e/o dove concentrare più testing, significa che abbiamo maggiori probabilità di trovare bug rilevanti e minori probabilità di trovare bug in funzionalità che potrebbero interessare meno agli stakeholder.
Sarebbe bello pensare che a volte possiamo testare dappertutto in modo più uniforme. Ma quando risorse e tempi sono limitati (e lo sono sempre, vero?), un approccio basato sul rischio ti aiuta a utilizzare il tempo dei tester in modo più efficace ed efficiente.
E se il testing non fosse la risposta giusta?
Prima di impegnarti a studiare un approccio di test per un rischio di prodotto in modo dettagliato, è importante che vengano considerate anche opzioni non legate al testing. Ad esempio, supponiamo che ci sia una grande preoccupazione che un componente del sistema non sia sufficientemente performante in produzione e che i tempi di risposta o l'affidabilità siano scarsi. Certo, potresti eseguire test di carico e cercare di risolvere i problemi facendo debugging. Ma altre opzioni potrebbero essere:
- Acquistare il componente da una terza parte invece di svilupparlo, evitando così il rischio.
- Riprogettare la soluzione per distribuire i carichi su più istanze del componente.
- Spostare l'elaborazione su un sistema batch che utilizzi una copia dei dati.
- Invece di attivare tutti gli utenti in un unico passo, adottare un approccio graduale implementando i clienti regione per regione e monitorare attentamente le performance.
- E così via.
Spesso, un'azione alternativa alla prevenzione dei problemi si rivela più efficace ed economica rispetto al testing volto a scoprire quei problemi in un secondo momento.
Comprendere il ruolo del testing nella gestione del rischio
Il testing può ridurre il rischio di rilascio. Se utilizziamo una valutazione dei rischi per guidare le nostre attività di test, l'obiettivo dei tester diventa esplicitamente progettare test per individuare i difetti affinché possano essere corretti e, così facendo, ridurre il rischio di un prodotto difettoso.
L'individuazione dei difetti riduce il rischio residuo di malfunzionamenti in produzione, dove i costi aumentano in modo molto rapido. Quando un test individua un difetto che poi viene corretto, il numero di difetti si riduce e di conseguenza diminuisce la probabilità complessiva di guasti.
Si potrebbe anche vederla così: il "micro-rischio" dovuto a quel difetto è eliminato. Tuttavia, bisogna ricordare che il testing non può trovare tutti i difetti, quindi ci saranno sempre difetti latenti che non vengono individuati e sui quali il testing non ha dato informazioni dirette.
Tuttavia, se ci concentriamo sulle funzionalità critiche e troviamo difetti in queste, è meno probabile che rimangano difetti non rilevati nelle funzionalità critiche. I difetti rimasti nelle funzionalità non critiche del sistema hanno conseguenze minori.
Un'ultima nota: anche il processo di analisi del rischio è esso stesso rischioso. L'analisi del rischio può sia sovrastimare, sia sottostimare i rischi, portando a decisioni imperfette. L'analisi del rischio può inoltre contribuire ad alimentare una cultura della colpa se portata all'eccesso.
Tra gli altri possibili inconvenienti dell'analisi del rischio, è importante sapere che non esiste un rischio assoluto che possa essere calcolato alla fine del progetto. La natura dei rischi è l'incertezza. Così come per l'efficacia del testing, il valore di un'analisi del rischio può essere determinato solo col senno di poi, una volta concluso il progetto.
E con questo si conclude il nostro manifesto sul risk-based testing. Il concetto tornerà più volte nella serie Leadership in Test, quindi resta sintonizzato per altri articoli!
Iscriviti alla newsletter di The QA Lead per essere avvisato quando saranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul, che consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di iscriverti, usa il nostro coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo totale del corso!
