La guida definitiva al test basato sul rischio: gestione del rischio nel test del software

ultimate guide risk based testing

La guida definitiva ai test basati sul rischio, alla gestione del rischio e al suo approccio con esempi:

Che cos'è il test basato sul rischio?

Il test basato sul rischio consiste nell'effettuare test o progettare ed eseguire gli scenari, in modo tale che i principali rischi aziendali che avranno un impatto negativo sul business identificato dal cliente siano scoperti nel loro prodotto o caratteristica all'inizio del ciclo di vita e siano mitigato implementando misure di mitigazione.

=> Fare clic qui per una serie completa di tutorial sul piano di test

L'impatto negativo può includere impatto sui costi, cliente insoddisfatto, esperienza utente negativa e persino la possibilità di perdere i clienti.

In altre parole, l'approccio RBT è quello di garantire che, il test venga eseguito in modo tale che anche se un utente trova un bug nella produzione, ciò non gli impedisce di utilizzare il software o non influisce in modo serio sull'attività.

RBT sta effettuando dei test sulla base dei rischi del prodotto. RBT è quello di scoprire con largo anticipo qual è il rischio di guasto di una particolare caratteristica o funzionalità nella produzione e il suo impatto sull'azienda in termini di costi e altri danni utilizzando una tecnica di prioritizzazione per i casi di test.

Quindi, il test basato sul rischio utilizza il principio di dare la priorità ai test delle caratteristiche, dei moduli e delle funzionalità di un prodotto o software. La definizione delle priorità si basa sul rischio della probabilità di guasto di quella caratteristica o funzionalità in produzione e sul suo impatto sui clienti.

Cosa imparerai:

• Test basati sul rischio e sua rilevanza per Agile e DevOps
  • Approccio di test basato sul rischio
    • Quando usiamo l'approccio RBT?
    • Esempio di approccio RBT
  • Modi per eseguire l'analisi dei rischi
  • Procedura di analisi dei rischi
  • Metodologia di analisi del rischio
    • Passaggio 1) Utilizzo di una griglia 3X3
    • Passaggio 2) Probabilità e impatto del fallimento
    • Passaggio 3) Test della griglia di priorità
    • Passaggio 4) Dettagli del test
  • In che modo RBT è rilevante per Agile e DevOps?
  • Vantaggi dell'approccio del test basato sul rischio
• Gestione del rischio durante la pianificazione dei test
  • Processo di gestione del rischio
    • # 1) Identificazione del rischio
    • # 2) Valutazione del rischio / Analisi dell'impatto del rischio
    • # 3) Mitigazione del rischio
  • Conclusione
• Gestione del rischio nella fase di esecuzione del test (con esempio)
  • Gestione del rischio - Con un focus sull'AUT
  • Come si svolgono i test sulle basi di rischio?
  • Conclusione
  • Lettura consigliata

Test basati sul rischio e sua rilevanza per Agile e DevOps

Trecento ore dedicate allo sviluppo del software possono essere rese inutili in soli 30 secondi con un unico difetto identificato in produzione.

Questo, a sua volta, può rovinare lo scopo dell'intero prodotto senza altra scelta che ritirarlo dal mercato. E questo è il significato e la necessità di 'test di qualità'.

Con la rapida crescita della tecnologia, il software è ospitato sul cloud che supporta più sistemi operativi, più piattaforme, infrastrutture IT complesse, ecc., Gli utenti finali stanno diventando sempre più esigenti riguardo alle funzionalità, alle opzioni e non compromettono mai la soddisfazione del cliente .

Al giorno d'oggi, la 'qualità' sta diventando un fattore cruciale nella fornitura di software, dove stanno avvenendo continui miglioramenti per migliorare la qualità al fine di mantenere i clienti felici.

Notiamo spesso che è un problema comune per quasi tutti i tester essere sotto una pressione tremenda che la loro finestra di test sia ridotta e in genere la build viene consegnata loro per il test all'ultimo minuto. Non c'è abbastanza tempo e risorse per eseguire tutti i test che hanno progettato e la copertura dell'automazione non è sempre al 100% e ha le sue sfide.

Non può mancare la tempistica di consegna e allo stesso tempo la qualità non può essere compromessa. Qualunque sia il piano B, aggiungere ulteriori risorse di test tirando fuori dalle altre squadre, non sta funzionando, il piano C, smettere di fare tutte le altre attività e deviare lo sforzo solo su questo, non aiuta davvero. Tuttavia molta aggiunta di risorse di test, alla fine, non funziona.

Non c'è altra opzione se non quella di eseguire test limitati e importanti entro il tempo e le risorse disponibili.

Quindi, come decidiamo quale test è importante in questa fase? Qualunque cosa un Tester consideri importante potrebbe non esserlo davvero per i clienti. Dal punto di vista di chi viene decisa l'importanza della caratteristica o di una funzionalità? Chi deciderà quali sono i test importanti? E continuano a sorgere molte altre domande.

Per rispondere a tutte queste domande e per gestire efficacemente la situazione di cui sopra, è stato chiamato un approccio di test 'Test basato sul rischio' , chiamato a breve 'RBT' , è nato, dove il team ha chiaramente pianificato e identificato gli scenari di test sulla base dei criteri del 'rischio di progetto'.

Sebbene il team QA abbia un quadro chiaro dei test importanti, RBT è un metodo collaudato per identificare i test cruciali e importanti dal punto di vista del cliente e del business attraverso un 'Analisi del rischio' procedura .

Quindi, ora rispetto al modo tradizionale di identificare semplicemente i difetti nel software, l'approccio e l'obiettivo QA è cambiato nel tempo a causa del cambiamento della tecnologia, aumento della concorrenza nel mercato per il rilascio di un software di qualità, introduzione di 'Automatizza tutto' e, in totale, introduzione alla pratica Agile e DevOps di fornire il software in un periodo di poche ore.

Pertanto, l'attuale tendenza del 'Principio del test' non è solo 'identificare i difetti' ma anche,

# 1) Concentrarsi sull'area del prodotto in cui vi è un forte impatto sull'attività a causa di un guasto o un'elevata probabilità di guasto nella produzione.

#Due) Concentrandosi su identificare i difetti presto e consentendo a un team di risolverlo il prima possibile e quindi consentendo al software / prodotto o funzionalità di farlo 'Fallire velocemente'.

# 3) L'aspetto più importante del servizio del team QA ora è concentrarsi sul cliente nel portare valore al cliente aumentando l'attenzione su 'End to end customer experience'.

Approccio di test basato sul rischio

È sempre come prepararsi per un esame, non si può dire che il test sia sufficiente e che non ci siano più difetti nel software, anche se si progetta ed esegue un ampio numero di test.

C'è un punto in cui la stabilità del software non sarà doppiamente garantita aumentando solo il numero di casi di test. A questo punto, non si tratta solo di concentrarsi sul numero di test, ma su ciò che il cliente si aspetta effettivamente dal rilascio.

Quindi, è essenziale trovare un equilibrio nell'ottimizzazione del test al fine di ottenere il massimo beneficio con il ragionevole sforzo del test. E questo è più importante quando le tempistiche dei test sono molto strette e non sono disponibili risorse sufficienti per eseguire test sufficienti.

Pertanto, in questo caso, l'approccio RBT gioca un ruolo chiave nell'ottimizzazione dello sforzo di QA e nella massimizzazione del beneficio del test con il minimo rischio aziendale.

Quindi, se ci concentriamo sull'aspetto di cui sopra, il lavoro di un QA sarà molto sollevato. Non devono bruciare i loro fine settimana in ufficio, testando continuamente il software e preoccupandosi di tutti i difetti S4 (Gravità 4) e P4 (Priorità 4) che emergono dai test.

Ebbene, 4 è considerata la priorità e la gravità più basse dei difetti nei test. Possono investire meglio il loro tempo in altri aspetti utili del progetto.

Per riassumere i fattori chiave dell'approccio 'Test basato sul rischio':

• Per consentire il test di 'ciò che i clienti desiderano' da una prospettiva aziendale.
• Per rispettare il calendario con la qualità attesa.
• Per ottimizzare lo sforzo di QA.

Quando usiamo l'approccio RBT?

Viene utilizzato negli scenari seguenti:

• L'approccio RBT può essere utilizzato ogni volta che esiste una limitazione o vincolo di tempo, costo e risorse di un progetto e ogni volta che è necessario ottimizzare le risorse.
• L'approccio RBT viene utilizzato quando il programma è più complesso e adatta la nuova tecnologia e quindi comporta molte sfide.
• Quando il programma è un progetto di ricerca e sviluppo ed è del primo tipo e il progetto presenta una serie di incognite e rischi.

Esempio di approccio RBT

Diversi approcci di analisi basata sul rischio vengono utilizzati nel settore IT per superare i rischi affrontati dalla produzione e il suo impatto.

Di seguito è riportato uno di questi approcci:

Questo approccio di RBT include l'identificazione delle 'Funzionalità vitali o caratteristiche chiave' del prodotto e la valutazione dei rischi a cui ciascuna di queste funzionalità è esposta nella produzione e l'implementazione di misure di mitigazione appropriate in atto per ridurre o mitigare il rischio.

Quindi l'approccio RBT include il test delle funzionalità che hanno la probabilità di guasto e il maggiore impatto sul business. I tipi di guasti potrebbero essere operativi o aziendali, tecnici, esterni, ecc.

Modi per eseguire l'analisi dei rischi

Non esiste un processo standard o un modello definito come tale per eseguire l'analisi dei rischi nel test del software per ogni caratteristica di un prodotto. Diverse organizzazioni utilizzano il proprio approccio ai metodi di analisi del rischio.

L'analisi dei rischi può essere eseguita su vari elementi del progetto per identificare i rischi e implementare un approccio RBT per l'analisi. Questi articoli includono,

• Caratteristiche
• Funzionalità
• Storie degli utenti
• Requisiti
• Casi d'uso
• Casi test

In questo caso, concentriamoci solo sui casi di test per comprendere l'implementazione dell'approccio di test basato sul rischio.

Procedura di analisi dei rischi

L'analisi dei rischi include il coinvolgimento delle parti interessate rilevanti del programma sia dal ‘ Team tecnico e team aziendale ' , che include il proprietario del prodotto, i responsabili dei prodotti, gli analisti aziendali, gli architetti, i tester e i rappresentanti dei clienti.

Saranno organizzate sessioni di brainstorming che coinvolgono questi stakeholder per condurre la discussione per identificare l'importanza di ogni caratteristica di un prodotto e dare loro la priorità in base al rischio di fallimento e al suo impatto sugli utenti finali nella produzione.

Vari 'documenti di progetto' come il documento dei requisiti, i documenti delle specifiche tecniche, i documenti di architettura e progettazione, i documenti dei processi aziendali, i documenti dei casi d'uso, ecc., Diventeranno l'input per la sessione di brainstorming.

Anche la conoscenza delle parti interessate sul prodotto e sul prodotto esistente sul mercato sarà un fattore di input per la discussione.

Poche altre fonti di input possono anche includere,

• Per raccogliere input sulle funzionalità più utilizzate.
• Input dalla consultazione di un esperto di dominio.
• Dati dalla versione precedente del prodotto o prodotto simile sul mercato.

Durante brainstorming sessione, vengono identificati i rischi relativi a ciascuna di queste caratteristiche. I tipi di rischi potrebbero essere un'operazione, tecnica o aziendale. I test e gli scenari ad essi correlati sono ponderati e i valori di rischio sono valutati sulla base della probabilità di accadimento del rischio e dell'impatto del rischio.

La 'probabilità del verificarsi del rischio' può essere dovuta a:

• Scarsa comprensione della funzione da parte del team di sviluppo del prodotto.
• Architettura e design impropri.
• Tempo insufficiente per la progettazione.
• Incompetenza della squadra.
• Risorse inadeguate: persone, strumenti e tecnologia.

L ''impatto del rischio' è l'effetto del fallimento per gli utenti e per l'azienda, se si verifica. L'impatto potrebbe essere,

• Impatto sui costi, con conseguente perdita.
• Impatto aziendale con conseguente perdita di affari o perdita di quote di mercato, procedimenti legali, perdita di licenza.
• Impatto sulla qualità, con conseguente rilascio del prodotto scadente o incompetente.
• Esperienza utente negativa, con conseguente insoddisfazione e perdita di un cliente.

L'area di interesse della valutazione del rischio di una caratteristica o di un prodotto può essere:

• Area di criticità aziendale della funzionalità.
• Caratteristiche più utilizzate e funzionalità importanti.
• Difetti aree soggette
• Funzionalità che porta l'impatto su sicurezza e protezione.
• Area di progettazione complessa e architettura.
• Modifiche apportate dalle versioni precedenti.

Metodologia di analisi del rischio

Cerchiamo di comprendere in dettaglio la 'metodologia di test basata sul rischio' ora.

L'approccio del test basato sul rischio utilizza il RISCHIO come criterio in tutte le fasi di test del ciclo di test, ovvero, pianificazione dei test , test design, test implementazione, esecuzione del test e rapporti di prova. Idealmente, si può progettare un numero elevato di possibili combinazioni di scenari di test.

Pertanto, l'approccio RBT include una classifica dei test in base alla gravità dei rischi per individuare l'area di guasto più difettosa o rischiosa, che causa un impatto elevato sul business.

L'obiettivo principale dell'analisi dei rischi è distinguere tra i file 'Alto valore' elementi come caratteristiche del prodotto, funzionalità, requisiti, storie degli utenti e casi di test e ' Basso valore' quelli e quindi in seguito concentrarsi maggiormente sui casi di test 'di alto valore', concentrandosi meno sui casi di test di 'valore basso'. Questa è la fase iniziale dell'analisi dei rischi prima di iniziare il test basato sul rischio.

Il compito principale della categorizzazione o del raggruppamento dei casi di test in valore alto e valore basso e l'assegnazione del valore di priorità a ciascuno di questi casi di test include i seguenti passaggi:

Passaggio 1) Utilizzo di una griglia 3X3

L'analisi dei rischi viene eseguita utilizzando una griglia 3X3, in cui ogni funzionalità, non funzionalità e i relativi casi di test vengono valutati da un team di stakeholder per la sua 'Probabilitàdi fallimento 'e' Impatto del fallimento '.

La probabilità di guasto di ciascuna funzionalità nella produzione è generalmente accessibile da un gruppo di 'Esperti tecnici' e sono classificati come 'Probabile guasto, abbastanza probabile e improbabile' lungo l'asse verticale della griglia.

Esempio di casi di test junit in eclipse

Allo stesso modo, l ''impatto del guasto' di queste caratteristiche e funzionalità nella produzione è sperimentato dal cliente finale, se non testato viene valutato da un gruppo di ' Business Specialists 'e sono classificati nelle categorie' Minori, Visibili e Interruzioni 'lungo l'asse orizzontale della griglia.

Passaggio 2) Probabilità e impatto del fallimento

Tutti i casi di test sono posizionati nei quadranti della griglia 3 X 3 in base ai valori identificati di probabilità di guasto e impatto del guasto che sono mostrati come punti nella figura sottostante.

Ovviamente l'elevata probabilità di guasto e l'elevato impatto del guasto (interruzione) sono raggruppati nell'angolo in alto a destra della griglia, il che è di grande importanza e quindi si identifica che i test 'Alto valore' e 'Basso valore' sono raggruppati nel angolo in basso a sinistra che è di minima o nessuna importanza per il cliente, in cui è possibile prestare minore attenzione a queste funzionalità o casi di test.

Passaggio 3) Test della griglia di priorità

Sulla base del posizionamento sopra dei casi di test nella griglia, ai test viene assegnata una priorità ed etichettati con priorità 1,2,3,4 e 5 e sono contrassegnati rispetto a ciascuno di essi. I test più importanti sono posizionati in 1^stgriglia assegnata con priorità 1 e analogamente quelle meno importanti sono classificate come 2, 3, 4 e 5.

Infine, tutti i casi di test vengono ordinati in base ai loro numeri di priorità e vengono selezionati per l'esecuzione in ordine di priorità. Quelli ad alta priorità vengono selezionati per l'esecuzione per primi e quelli a bassa priorità vengono eseguiti in seguito o de-scoped.

Passaggio 4) Dettagli del test

Il passaggio successivo consiste nel decidere il livello di dettagli del test per l'ambito definito del test. La profondità dell'ambito del test può essere decisa in base alla classifica di cui sopra secondo la griglia sottostante.

I test ad alta priorità con classificazione 1 vengono testati 'in modo più approfondito' e, di conseguenza, vengono impiegati esperti per testare queste funzionalità ad alta criticità e i relativi casi di test. Allo stesso modo, test case con priorità 2, 3 e 4. È possibile decidere di escludere le funzionalità e i test con priorità 5 in base al tempo e alle risorse disponibili.

Quindi, l'approccio Level of Detail of Testing di dare priorità alle funzionalità e ai relativi casi di test non solo aiuta i tester a identificare i `` test di alto valore '', ma li guida anche a decidere il loro `` livello di dettaglio del test '' sulla base di queste classifiche di priorità e li aiuta a eseguire test migliori e riduce i costi di test tramite il processo di ottimizzazione.

In che modo RBT è rilevante per Agile e DevOps?

Ora, dopo aver compreso l'approccio del test basato sul rischio di eseguire il test basato sulla prioritizzazione dei test in base al 'Rischio di fallimento' di una particolare caratteristica e al suo 'Impatto sul cliente' in tempo reale, ovviamente si solleverebbe la questione di la rilevanza dell'approccio del test basato sul rischio nelle pratiche Agile e DevOps.

'Automatizza tutto', 'Prova tutto', 'Prova continuamente', 'Prova ripetutamente' sono i concetti chiave di queste pratiche.

Ogni volta, quando c'è una modifica nel codice o c'è un rilascio, tutti i test progettati vengono eseguiti tramite l'automazione Integrazione continua (CI) / Consegna continua (CD) pipeline rapidamente e ripetutamente, indipendentemente dalla loro priorità.

Allora qual è la relazione tra RBT e DevOps? Dove si adatterebbe RBT e diventerebbe rilevante in Agile e DevOps ???

# 1) Sì, come ho detto prima, non è che ogni settore e ogni prodotto abbia una copertura di automazione del 100% per le loro esecuzioni di test. Quindi, se il team deve fare la scelta della priorità per l'esecuzione del test dalla scelta dei casi di test manuali e desidera risparmiare l'energia e lo sforzo delle risorse di test per altre attività, allora RBT è la scelta migliore.

L'approccio basato sul rischio è anche una scelta migliore per eseguire test automatizzati con quelli ad alta priorità e test al più presto.

#Due) Il team QA può adottare l'approccio RBT in modo più efficace durante l'analisi dei requisiti per analizzare i requisiti e fornire un rapporto anticipato dei probabili rischi dei prodotti e delle caratteristiche in modo che le azioni appropriate possano essere intraprese in modo proattivo dal team del programma per mitigarlo.

# 3) L'approccio RBT può essere efficacemente utilizzato nella progettazione dei casi di test e degli scenari basati sull'alto rischio in modo che sia possibile prestare maggiore attenzione alle caratteristiche e alle funzionalità ad alto rischio.

# 4) L'identificazione delle aree 'ad alto rischio' consente al team di controllo qualità di concentrare i propri sforzi di test su quelle aree per eseguire test 'più approfonditi' utilizzando 'tester altamente qualificati'.

# 5) 'Fail Fast', come tutti sappiamo è il concetto di 'Agile' e 'DevOps', per i quali l'approccio RBT aiuta a identificare le aree di 'alto rischio' nel software, identificare i difetti in anticipo e consentire loro di fallire velocemente e fallire prima e lascia che il team lo aggiusti.

# 6) L'obiettivo finale di Agile / DevOps è 'Focus sul cliente' e quindi l'approccio RBT consente al QA di concentrarsi sull'esperienza del cliente piuttosto che sulla semplice ricerca dei difetti.

Vantaggi dell'approccio del test basato sul rischio

Abbiamo già compreso lo scopo e l'uso dell'approccio RBT per analizzare i requisiti, progettare ed eseguire gli scenari di test. Ci sono molti vantaggi di RBT.

Possiamo consolidare ed elencare i vantaggi del test basato sul rischio come:

• Aiuta a un uso più efficiente e ottimizzato delle risorse di test.
• Aiuta a facilitare il lavoro di QA, le attività di test, progettazione e sviluppo dei test e preparazione dei test assegnando priorità.
• Aiuta a gestire meglio le risorse di QA allocando le risorse chiave verso aree ad alto interesse.
• Aiuta nell'utilizzo efficace delle risorse e devia il loro tempo e le loro energie su cose migliori nel progetto.
• Aiuta il team di controllo qualità nella pianificazione delle attività di test in base alla valutazione del rischio e all'identificazione delle aree volatili e ad alto rischio.
• Aiuta il team a ottimizzare i test da condurre a seconda dell'importanza e quindi de-scope i test di basso valore in accordo con gli stakeholder.
• Nel complesso aiuta nella riduzione dei costi attraverso attività di test ottimizzate e ridotte.
• L'approccio RBT consente al team di QA di testare prima le aree ad alto rischio e consente al prodotto di 'fallire rapidamente' e risolvere rapidamente.
• L'approccio RBT aiuta a portare chiarezza nel ‘ Copertura del test ' e l ''ambito del test' all'intero gruppo di stakeholder.
• Il team può concentrarsi maggiormente sulle aree ad alto rischio e concentrarsi meno sull'area a basso rischio.
• RBT consente al Team di decidere con largo anticipo sull'implementazione del modo più efficace di mitigazione dei rischi del prodotto.
• RBT aiuta a evitare l'effetto di un'implementazione inappropriata delle mitigazioni.
• Il test basato sul rischio consente al team di intraprendere le azioni appropriate per mitigare o pianificare la contingenza o per posizionare qualsiasi soluzione alternativa per superare il fallimento o ridurne l'impatto se il rischio si verifica in Live.
• RBT aiuta a ridurre al minimo il rischio residuo nel rilascio.
• Aiuta a raggiungere la 'qualità migliorata' attraverso difetti meno costosi nella produzione.
• In definitiva aiuta a 'migliorare l'esperienza del cliente' e 'cliente soddisfatto'.

Successivamente, impareremo come gestire i rischi nelle fasi di pianificazione dei test ed esecuzione dei test del ciclo di vita del test del software.

Gestione del rischio durante la pianificazione dei test

Come gestire i rischi durante la fase di pianificazione del test:

La vita è piena di rischi, e così è un progetto software. Tutto può andare storto in qualsiasi momento. Siamo sempre pronti a sistemare le cose, ma che ne dici di assicurarci che nulla vada storto e che quando lo fa sappiamo esattamente cosa fare? Entra nella gestione dei rischi: questa è una parte di un progetto di test del software che ci prepara a prevenire, comprendere, individuare e superare i rischi.

Un rischio è semplicemente un problema che è probabile che si verifichi e quando si verifica, causerà una perdita.

qual è il miglior software di rimozione malware

La perdita potrebbe essere qualsiasi cosa: denaro, tempo, fatica o un compromesso di qualità. La perdita non è mai buona. Non importa quanto ci diamo, non è positivo e non lo sarà mai. Perciò Gestione del rischio è parte integrante dei progetti software per assicurarci di gestire i rischi e prevenire / ridurre le perdite.

Test basati sul rischio : Dal momento che siamo una comunità di QA, cerchiamo di rimanere specifici sui rischi e sul processo ad essi correlato esclusivamente nel nostro mondo QA. I rischi vengono valutati e gestiti all'incirca in 2 fasi del ns Ciclo di vita del test del software . STLC può essere classificato in 3 fasi: pianificazione del test, progettazione del test ed esecuzione del test.

Il processo di Risk Management si verifica due volte, durante:

1. Pianificazione dei test
2. Test Case Design (fine) o talvolta nella fase di esecuzione del test

È obbligatorio nel caso 1, ma nel caso 2 è più una situazione 'basata sui bisogni'.

Serie di articoli in due parti:

Anche se il processo sottostante è lo stesso, il file tipi di rischi affrontate in entrambe queste aree sono completamente diverse. Per renderli giustizia individualmente, li tratteremo in modo diverso come una serie in due parti.

Questa sezione riguarderà 'Gestione del rischio durante la pianificazione dei test'.

Processo di gestione del rischio

Il processo generico per la gestione del rischio prevede 3 fasi importanti:

1. Identificazione del rischio
2. Analisi dell'impatto del rischio
3. Mitigazione del rischio

Rischi di test ed esempi di mitigazione:

# 1) Identificazione del rischio

Come si dice, il primo passo per risolvere un problema è identificarlo. Questa fase prevede la creazione di un elenco di tutto ciò che potrebbe potenzialmente emergere e interrompere il normale flusso degli eventi.

Il risultato principale di questo passaggio è un elenco di rischi.

Questa fase di test basata sul rischio è generalmente guidata dal responsabile / responsabile / rappresentante del QA. Tuttavia, il responsabile da solo non sarà in grado di elaborare l'intero elenco: il contributo dell'intero team di controllo qualità ha un impatto enorme. Possiamo dire che questa è un'attività collettiva guidata dal responsabile del controllo qualità.

Inoltre, i rischi identificati durante la fase di pianificazione del test sono più 'gestionali' nel senso dell'orientamento, nel senso che esamineremo tutto ciò che potrebbe avere un impatto sulla pianificazione, l'impegno, il budget, le modifiche dell'infrastruttura del progetto QA, ecc. non l'AUT, ma il modo in cui andrà avanti la fase di QA.

Rischi durante la pianificazione del test: esempi di test basati sul rischio

Di seguito è riportato un elenco di esempio di rischi che potrebbero essere elencati durante la fase di pianificazione del test. Si prega di notare che l'AUT e le sue funzionalità non sono al centro qui.

1. Il programma dei test è serrato. Se l'inizio del test è ritardato a causa di attività di progettazione, il test non può essere esteso oltre la data di inizio pianificata dell'UAT.
2. Risorse insufficienti, inserimento delle risorse troppo tardi (il processo richiede circa 15 giorni).
3. I difetti si trovano in una fase avanzata del ciclo o in un ciclo tardivo; i difetti scoperti in ritardo sono molto probabilmente dovuti a specifiche poco chiare e richiedono molto tempo per essere risolti.
4. Ambito non definito completamente definito
5. Disastri naturali
6. Non disponibilità di Indipendente Ambiente di test e accessibilità
7. Test ritardati a causa di nuovi problemi

A questo punto, puoi scegliere di essere completo quanto desideri, a seconda del tempo a disposizione.

Una volta elencati tutti i rischi, si passa alla valutazione del rischio / analisi dell'impatto del rischio.

# 2) Valutazione del rischio / Analisi dell'impatto del rischio

La tua analisi dei rischi è qualcosa del genere? :)

Analisi dei rischi nel test del software : Tutti i rischi vengono quantificati e classificati in ordine di priorità in questa fase. La probabilità di ogni rischio (la possibilità che si verifichi) e l'impatto (quantità di perdita che causerebbe quando questo rischio si materializza) sono determinati sistematicamente.

Alto Medio basso , vengono assegnati valori sia alla probabilità che all'impatto di ciascun rischio. I rischi con probabilità “alta” e impatto “alto” vengono presi in considerazione prima e poi segue l'ordine.

Tabella di analisi dell'impatto del rischio:

Seguendo questi passaggi, la tabella di analisi dell'impatto del rischio per i rischi sopra elencati sarebbe simile a questa (tutti i valori sono ipotetici e solo a scopo di comprensione):

# 3) Mitigazione del rischio

Il passaggio finale in questo processo di test basato sul rischio (RBT) è trovare soluzioni per pianificare come gestire ciascuna di queste situazioni. Questi piani possono variare da azienda ad azienda, da progetto a progetto e persino da persona a persona.

Tecniche di mitigazione del rischio:

Ecco un esempio di ciò in cui si trasforma la tabella dei rischi quando questa fase è completa:

Alcuni punti da notare:

1. Prima la gestione del rischio inizia in una fase di pianificazione del progetto QA, meglio è.
2. Di tutti e 3 i passaggi, L'identificazione del rischio è la più importante . Se qualcosa non è elencato e considerato per ulteriori passaggi, il rischio non viene gestito.
3. Cerca di trovare un periodo di tempo ideale per questa attività. Ricorda, troppa pianificazione lascia troppo poco tempo per fare.
4. Inoltre, dopo il processo di gestione del rischio, se si presenta una nuova situazione, il piano di gestione del rischio può essere modificato o aggiornato per riflettere la condizione più attuale.
5. Dati storici può essere molto utile per il successo di questo processo.

Conclusione

Questo ci porta alla fine della gestione del rischio nella fase di pianificazione del test. Anche se i passaggi ei principi sottostanti sono simili, il processo di gestione del rischio è più concentrato verso l'AUT quando avviene nella fase di progettazione / esecuzione del test.

Nella nostra prossima sezione, tratteremo: Gestione del rischio nella fase di esecuzione del test.

Gestione del rischio nella fase di esecuzione del test (con esempio)

Nel nostro viaggio alla comprensione del processo di gestione del rischio, abbiamo parlato di come va esclusivamente in Fase di pianificazione del test di test basato sul rischio . Abbiamo anche compreso il processo generico che coinvolge: identificazione del rischio, valutazione del rischio e piano di mitigazione del rischio.

Come gestire il rischio nella fase di progettazione o esecuzione del test:

C'è un'altra forma di Gestione del rischio (a volte indicato anche come, Test basati sul rischio ) che si verifica durante la fase di progettazione del test o di esecuzione del test a seconda della situazione. Ora, di che situazione stiamo parlando? Cerchiamo prima di capirlo.

Sappiamo tutti che il nostro lavoro di test è reattivo. Nessun requisito (o ambito definito), non possiamo eseguire un'analisi di fattibilità e scrivere scenari di test o pianificare attività di test.

Allo stesso modo, quando il codice non è pronto non abbiamo nulla da testare, non importa quanto lavoro di preparazione avremmo potuto essere pronti in termini di casi di test, dati di test, ecc. Inoltre, il test è l'unico passo rimasto prima che il prodotto vada a buon fine vivere.

Gestione del rischio - Con un focus sull'AUT

Cerchiamo di capirlo meglio con un esempio:

Se il test dovesse iniziare in tale data, il 1 ° gennaio^ste doveva andare avanti fino al 14 gennaio^th- al termine del test, la data di go-live del prodotto viene solitamente fissata immediatamente. Diciamo - 15 gennaio^thper semplicità. Ora, nel mondo perfetto le cose andrebbero esattamente come previsto. Ma sappiamo tutti la realtà.

In questo caso, supponiamo che per qualche motivo il test non sia iniziato fino al 7 gennaio^th, il che significa che abbiamo perso metà del nostro tempo di test. Ma abbiamo bisogno di 14 giorni per testare a fondo il prodotto. Tuttavia, è possibile spostare ulteriormente la data di attivazione di 7 giorni; di solito non è un'opzione. Perché si promette che il prodotto arriverà sul mercato in una certa data e gli eventuali ritardi non vanno bene per l'azienda.

Quindi, di solito, noi team di test dobbiamo assorbire i ritardi, compensare in qualche modo, lavorare con il tempo disponibile e assicurarci che il prodotto sia testato bene. Un lavoro duro, non è vero?

È qui che viene nuovamente impiegato il processo di gestione del rischio.

• Ora se i ritardi sono previsti in anticipo prima ancora che inizi il test, il processo si svolge nella fase di progettazione del test.
• Se i ritardi si verificano durante un Fase di esecuzione del test avviato normalmente: il processo viene seguito durante la fase di esecuzione del test.
• I passaggi e il metodo sono gli stessi indipendentemente dalla fase in cui si verifica.

Qual è il processo?

La gestione del rischio viene eseguita per determinare quali aree dell'AUT (Application Under Test) richiedono la massima attenzione. Queste sono tipicamente le aree funzionali (moduli o componenti) che sono fondamentali per il successo del prodotto finale e sono più soggette a guasti.

Leggi anche=> La modalità di guasto e l'analisi degli effetti (FMEA) è una tecnica di gestione del rischio

Chi lo esegue?

Dal momento che riguarda l'AUT, la conoscenza al riguardo non è solo con il QA ma con tutti gli altri team - Dev, BA, Client, team di gestione del progetto, ecc. Quindi è uno sforzo collettivo, guidato dal team di test.

Come si svolgono i test sulle basi di rischio?

Passo 1) Identificazione del rischio

Individuare tutte le aree funzionali dell'AUT. Ciò includerà semplicemente la creazione di un elenco.

Passo 2) Valutazione del rischio

Tutti i rischi vengono quantificati e classificati in ordine di priorità in questa fase. Quantificare è semplicemente, assegnare un numero a ciascun rischio nell'elenco che darà un'indicazione della priorità con cui deve essere affrontato.

La probabilità di ogni rischio (la possibilità che si verifichi) e l'impatto (quantità di perdita che causerebbe quando questo rischio si materializza) vengono decisi.

Il metodo tipico è assegnare le valutazioni. Per esempio, La probabilità può assumere valori da 1 a 5. 1 indica che la probabilità che si verifichi sia bassa (è improbabile che accada affatto) e 5 sia alta (accadrà sicuramente).

Allo stesso modo, a Impact può anche essere assegnato un punteggio da 1 a 5. 1 è a basso impatto (anche se questo rischio si concretizza, la perdita è minima) e 5 è ad alto impatto (enormi perdite quando si verificano).

Passaggio 3)

Crea un formato tabella e fallo circolare a tutti i rappresentanti del team: Dev, BA, Cliente, PM, QA e chiunque altro rilevante.

Passaggio 4)

Chiedere a ogni squadra di inserire i valori in base alla loro valutazione di probabilità e impatto.

Poiché i valori di probabilità e impatto sono numerici, faciliterà il calcolo del valore del 'Fattore di rischio'.

Fattore di rischio = Probabilità X Impatto. Più alto è il fattore di rischio, più grave è il problema.

Un esempio:

Tieni presente che a questo punto questo è semplicemente il risultato della valutazione di una squadra. Per un progetto in cui sono coinvolti 5 diversi team, il team QA finirebbe con 5 diversi tavoli.

Passaggio 5)

Prendi una media dei valori del fattore di rischio. Per esempio, se ci sono 5 squadre, per ogni modulo, sommare tutti i valori dei fattori di rischio e dividerli per 5. Questi sono i valori finali di cui ci occuperemo. Diciamo, questi sono i fattori di rischio medi:

Maggiore è il fattore di rischio, più quel modulo deve essere testato.

Quindi, i moduli 5 e 2 sono fondamentali per il successo dell'azienda. Condividi i risultati con tutte le squadre.

Passaggio n. 6)

Piano di mitigazione del rischio : Ora, questo è il passaggio che cambia da progetto a progetto. Abbiamo identificato che i moduli 5 e 2 sono quelli su cui è necessario concentrarsi maggiormente.

Esempidel piano potrebbe essere:

1. I moduli 5 e 2 verranno testati a fondo assicurandosi che tutti i casi di test ad essi correlati siano testati. Gli altri moduli saranno testati su base esplorativa.
2. I moduli 5 e 2 verranno prima testati e poi, a seconda del tempo a disposizione, si occuperanno degli altri.

Una volta fatto un piano, tutti i team raggiungono un accordo e lo seguono per testare il prodotto tenendo conto del fattore di rischio.

Questo è tutto!

Alcuni punti importanti da notare:

• Poiché questa è un'attività collettiva che richiede l'opinione di tutti in considerazione ; le possibilità che sia accurato ed efficace sono maggiori.
• Questo è non un metodo formale e non deve far parte di ogni progetto di QA.
• A volte, anche se la squadra sceglie di non disegnare tabelle e assegnare valori: a semplice sessione di brainstorming con tutti i presenti può dare al team di controllo qualità una buona direzione su come procedere.
• Il input del team di sviluppo è molto importante perché sono loro che creano il prodotto, quindi sapranno cosa potrebbe funzionare e cosa potrebbe richiedere un controllo aggiuntivo. Assicurati di essere alla ricerca di questo.
• Anche se ci sono più passaggi nel processo, non ci vuole molto tempo per eseguirli . Soprattutto se tutte le squadre possono sedersi insieme e lavorare contemporaneamente.
• Ricorda questo processo e il suo risultato è solo l'alternativa . Ottenere tutto il tempo pianificato per i test è il modo migliore per eseguire l'attività di QA.

Conclusione

L'approccio del test basato sul rischio indica chiaramente che l'obiettivo del tester non è solo continuare a esplorare i difetti, indipendentemente dalla gravità e dalla priorità. Ora le cose sono cambiate ei tester devono lavorare in modo intelligente e devono comprendere la chiara 'esigenza del cliente e desideri dell'utente'.

Devono studiare a fondo il prodotto e capire qual è la caratteristica più frequentemente utilizzata nella produzione, quale è il percorso più critico per la generazione di ricavi e come proteggere e salvaguardare i clienti dai problemi di produzione e dalle minacce aziendali.

Quindi, l'approccio RBT educa chiaramente i tester3 che solo testare tutto o testare ampiamente non significa che il test sia completo o che non ci siano difetti nel prodotto. Testare efficacemente in un tempo stabilito e garantire che gli impatti aziendali importanti e critici siano annullati, il che è molto importante per il tester.

Pertanto, il test basato sul rischio è lo strumento più efficiente per il team QA per guidare gli stakeholder del progetto in base ai rischi del progetto. L'approccio RBT aiuta il team QA nella continua identificazione del rischio e nella sua risoluzione che potrebbe mettere in pericolo il raggiungimento degli obiettivi e degli obiettivi generali del progetto e aiuta a raggiungere l'obiettivo finale del gruppo QA.

P.S. Le parole QA e Test sono state usate in modo intercambiabile in tutto il documento.

Circa l'autore: Questo articolo è stato scritto da più membri del team STH: Gayathri Subrahmanyam e Swati S.

Gayathri è una PMI di test del software con oltre 2 decenni di esperienza nel test del software e ha ampiamente adottato l'approccio 'Test basato sul rischio' come parte dell'industrializzazione dei test in diversi incarichi e ha realizzato il vantaggio dell'ottimizzazione delle risorse di test e dei test di qualità.

Il test basato sul rischio è stato impegnativo per te? Hai qualche fatto interessante da aggiungere al nostro tutorial? Sentiti libero di esprimere i tuoi pensieri nella sezione commenti qui sotto !!

=> Visita qui per una serie completa di tutorial sul piano di test

Lettura consigliata

• Processo di integrazione continua: come migliorare la qualità del software e ridurre i rischi
• Modalità di errore e analisi degli effetti (FMEA) - Come analizzare i rischi per una migliore qualità del software e clienti soddisfatti!
• La guida definitiva al test basato sul rischio: gestione del rischio nel test del software
• Top 10 strumenti e tecniche di valutazione e gestione del rischio
• Tipi di rischi nei progetti software
• Alcune interessanti domande di intervista sul test del software
• Scegliere il test del software come carriera
• Feedback e recensioni sul corso di test del software