Risk Based Testing

954 views

Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Risk Based Testing

  1. 1. Risk Based Testing
  2. 2. IntroduzioneVi 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. 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 negativiL’obiettivo è quindi la riduzione del livello di Quality Risks, e la soluzione è il Risk Based Testing
  4. 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. 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. 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. 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. 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 ImpattoLa cui scala varia da 1 (caso peggiore) a 25 (caso migliore)
  9. 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. 10. L’Effort di TestRPN Range Test Scope 1-2 Molto vasto 3-5 Ampio 6-10 Rapido 11-15 Occasionale 16-20 Anomalies reporting only 21-25 Nessuno
  11. 11. ContattiVia Chiomonte, 26 – 10141 – Torino www.ixmasoft.it0039.011.04.37.746 info@ixmasoft.it

×