2. Introduzione
Vi siete mai chiesti perchè non esistono sistemi software bugs-free?
Per ogni sistema software nel mondo reale il numero di test può
risultare enorme se non infinito...
...e sfortunatamente il tempo per testare è finito, spesso troppo
breve
E’ quindi necessario scegliere un numero finito di Casi di Test, e
questa selezione deve essere fatta per garantire nel contempo
Qualità e Sicurezza
3. Quality Risks
Si può pensare alla Qualità in termini di Esiti (soddisfazione del
Cliente, conformità ai requisiti,...) e di Attributi (funzionalità,
prestazioni, sicurezza,...)
Un rischio può essere definito come la possibilità che si verifichi
un esito negativo
Un rischio nell’ambito della Qualità del Software (Quality Risk) è
quindi la possibilità che il sistema software non presenti gli
attributi di qualità richiesti, generando esiti negativi
L’obiettivo è quindi la riduzione del livello di Quality Risks, e la
soluzione è il Risk Based Testing
4. Benefici
I Casi di Test vengono eseguiti in ordine di rischio, aumentando la
probabilità di rilevare anomalie in ordine di gravità
L’efficacia del test aumenta inevitabilmente
«Pick the right tests out of the infinite cloud of possible tests»
L’analisi dei risultati dei test durante la loro esecuzione consente di
conoscere il livello residuo di Quality Risks
«Release when risk of delay balances risk of dissatisfaction»
Se il tempo per i test non è sufficiente, si eliminano Casi di Test in
ordine di rischio inverso
«Give up tests you worry about the least»
5. Quality Risk Analisys
La Quality Risk analisys rappresenta la base del Risk Based
Testing, e prevede:
Identificazione dei Quality Risks
Valutazione del livello di rischio associato con ogni Quality
Risk
6. Identificazione dei rischi
Il coinvolgimento dei Project Stakeholders (sia business che
tecnici) è cruciale. Questo può avvenire in due modi:
Unica sessione di brainstorming per tutti i gruppi di stakeholders
Tipicamente la sessione dura un giorno intero
Sessioni singole
Le interviste durano in media 90-120 minuti
E’ molto importante la scelta del framework da utilizzare:
Checklist con categorie di rischi – Keep it easy –
ISO 9126 – Caratteristiche della Qualità – Strutturata ma
complessa
Checklist per area funzionale – Troppo rifinita per System Test
Checklist per sottosistemi – Ottima per sistemi HW
7. Valutazione dei rischi
Per ogni rischio rilevato devono essere valutati:
La probabilità che il sistema contenga un’anomalia relazionabile
al rischio
Nasce da considerazioni tecniche
L’impatto che l’anomalia potrebbe causare se rilasciata nella
versione finale del sistema software
Nasce da considerazioni legate al business
Sia per la probabilità che per l’impatto vengono definite delle
scale, che vengono successivamente utilizzate per definire il:
Risk Priority Number (RPN)
8. Risk Priority Number
Probabilità Valore Impatto Valore
Molto probabile 1 Molto alto 1
Probabile 2 Alto 2
Poco probabile 3 Medio 3
Improbabile 4 Basso 4
Molto improbabile 5 Molto basso 5
RPN = Probabilità X Impatto
La cui scala varia da 1 (caso peggiore) a 25 (caso migliore)
9. Risk Priority Number
Il Risk Priority Number (RPN) misura il livello di rischio associato
con ogni elemento di rischio precedentemente identificato
I Casi di Test vengono progettati per coprire gli elementi di
rischio
I Casi di Test ereditano il RPN dell’elemento di rischio dal quale
discendono
Il RPN determina l’ordine di esecuzione dei Casi di Test,
determinando quindi l’allocazione dell’effort di test
10. L’Effort di Test
RPN Range Test Scope
1-2 Molto vasto
3-5 Ampio
6-10 Rapido
11-15 Occasionale
16-20 Anomalies reporting only
21-25 Nessuno
