failure mode effects analysis how analyze risks
Modalità di guasto e analisi degli effetti (FMEA) è una tecnica di gestione del rischio.
Se implementato correttamente, può essere un'ottima aggiunta al meglio Processi di garanzia della qualità essere seguito. In questo articolo, il nostro obiettivo è farvi conoscere questa tecnica di Analisi dei Rischi che alla fine è molto utile per migliorare la qualità del software.
Cosa imparerai:
- Modalità di guasto e analisi degli effetti
- Cos'è l'analisi del rischio?
- Esempio di analisi dell'effetto della modalità di guasto
- FMEA e grado di test
- Conclusione
- Lettura consigliata
Modalità di guasto e analisi degli effetti
FMEA è utilizzato principalmente dai dirigenti o dalle parti interessate. In pratica, i tester ottengono poche informazioni su questa tecnica. Ma ora la tendenza sta cambiando e sento che se i tester capiscono bene questo concetto, possono guidare il loro processo di pensiero di scrivere casi di test a un livello superiore utilizzando questa tecnica per:
- Comprendere gli obiettivi delle parti interessate di testare l'applicazione.
- Comprendi l'attività.
- Deriva gli scenari di test di alto livello in base agli interessi aziendali e del management.
- Realizza casi di test efficaci che forniscano una migliore copertura alle aree a rischio.
- Dai la priorità ai casi di test.
- Decidi cosa testare e cosa rimandare in qualsiasi fase.
sfondo
L'ANALISI DEL RISCHIO è un aspetto cruciale di Gestione dei test . Sorge quindi la domanda: Cos'è l'analisi del rischio? E perché è importante? Per capirlo, è fondamentale capire: cos'è il RISCHIO?
Vedi anche => Tipi di rischi nei progetti software.
RISCHIO come significato letterale è una possibilità di un risultato o evento negativo o indesiderabile. I rischi se non gestiti o gestiti correttamente possono portare a clienti di scarsa qualità, insoddisfatti e, talvolta, a perdite di affari.
Il rischio ha 2 attributi:
- Probabilità
- Impatto
Probabilità indica le possibilità che si verifichi un particolare rischio e impatto indica l'entità dell'effetto del rischio.
Cos'è l'analisi del rischio?
L'analisi dei rischi è un meccanismo mediante il quale i potenziali rischi identificati vengono analizzati e studiati a fondo per trovare la probabilità e l'impatto. Si consiglia di misurare i due attributi e in base al risultato si identifica:
- Cosa testare prima?
- Cosa provare di più?
- Cosa non testare (questa volta)?
Esistono molti metodi per eseguire l'analisi dei rischi e sono generalmente classificati in due tipi:
- Tecniche informali : Si basano su esperienza, giudizio e intuizione.
- Tecniche formali : Identificazione e valutazione degli attributi di rischio.
F ailure M ode e E ffetti PER nalysis (FMEA): questo è un metodo formale per eseguire un'analisi dei rischi. Nelle sezioni seguenti parlerò di più su FMEA e prova ad elaborarlo con l'esempio.
domande e risposte dell'intervista html per esperti
FMEA è una tecnica formale per eseguire l'analisi dei rischi. È uno strumento sistematico e quantitativo sotto forma di un foglio di calcolo che aiuta i membri ad analizzare cosa potrebbe andare storto. Per fare l'FMEA abbiamo bisogno delle persone giuste sul tavolo. Richiede un rappresentante di tutti i settori, compresi i clienti.
Descrizione
FMEA inizia e continua con le sessioni di Brainstorming. I partecipanti devono identificare tutti i componenti, i moduli, le dipendenze, le limitazioni che potrebbero non funzionare in un ambiente di produzione e alla fine portare a scarsa qualità, affidabilità e potrebbero causare la perdita di affari.
Durante FMEA non solo identifichiamo l'entità della perdita, ma cerchiamo anche di identificare la causa di tali guasti. Per misurare FMEA, abbiamo bisogno di 3 attributi:
- Gravità del fallimento (S)
- Priorità del fallimento (P)
- Probabilità del fallimento (L)
Mettiamo ciascuno di questi attributi in una scala mostrata di seguito:
Scala di gravità:
Descrizione | Classe | Scala |
Perdita di dati, hardware o problemi di sicurezza | Urgente | 1 |
Perdita di funzionalità senza soluzione alternativa | Alto | Due |
Perdita di funzionalità con una soluzione alternativa | medio | 3 |
Perdita parziale di funzionalità | Basso | 4 |
Cosmetico o banale | Nessuna | 5 |
Scala di priorità:
Descrizione | Classe | Scala |
Perdita completa del valore di sistema | Urgente | 1 |
Perdita inaccettabile del valore di sistema | Alto | Due |
Possibile riduzione del valore di sistema | medio | 3 |
Accettabile riduzione del valore di sistema | Basso | 4 |
Una riduzione trascurabile del valore di sistema | Nessuna | 5 |
Scala di probabilità:
Descrizione | Classe | Scala |
Certo per tutti gli utenti | Urgente | 1 |
Probabile impatto su alcuni utenti | Molto alto | Due |
Possibile impatto su alcuni utenti | Alto | 3 |
Impatto limitato a pochi utenti | Basso | 4 |
Inimmaginabile nell'uso effettivo | Nessuna | 5 |
Tutti questi tre attributi (gravità, priorità e probabilità) vengono misurati individualmente in scala e quindi moltiplicati per ottenere un Numero di priorità del rischio (RPN).
cioè Numero di priorità del rischio ( RPN) = S * P * L
Sulla base di questo valore RPN, determiniamo l'entità del test. Minore è l'RPN, maggiore è il rischio.
Proviamo a capirlo con un esempio:
Esempio di analisi dell'effetto della modalità di guasto
(Questo è un esempio ipotetico solo a scopo di comprensione. L'implementazione effettiva e le funzionalità possono variare)
Consideriamo un semplice esempio di un'applicazione bancaria che ha 4 funzionalità.
- Caratteristica 1: Ritira
- Caratteristica 2: Depositare
- Caratteristica 3: Mutuo per la casa
- Caratteristica 4: Depositi fissi.
Viene formato un team di analisi dei rischi composto dal direttore della banca, UAT Responsabile del test (che rappresenta l'utente finale), Architetto tecnico, Architetto del test, Amministratore di rete, DBA e Project Manager.
Dopo una serie di sessioni di brainstorming, il team ha ideato il file seguenti rischi:
- Logica aziendale complessa in caso di calcolo del tasso di interesse del mutuo per la casa.
- Il sistema non riesce a 200 utenti simultanei.
- Il sistema non riesce a gestire i documenti che sono più di 6 MB.
Ora proviamo a calcolare la gravità, la priorità e la probabilità di questi rischi identificati.
Gravità:
Caratteristica | Classe | Scala |
Logica aziendale complessa in caso di calcolo del tasso di interesse del mutuo per la casa | Molto alto | Due |
Il sistema non riesce a 200 utenti simultanei | Alto | 3 |
Il sistema non riesce a gestire i documenti che sono più di 6 MB | Molto alto | Due |
Priorità:
Caratteristica | Classe | Scala |
Logica aziendale complessa in caso di calcolo del tasso di interesse del mutuo per la casa | Molto alto | Due |
Il sistema non riesce a 200 utenti simultanei | Alto | 3 |
Il sistema non riesce a gestire i documenti che sono più di 6 MB | Alto | 3 |
Probabilità:
Caratteristica | Classe | Scala |
Logica aziendale complessa in caso di calcolo del tasso di interesse del mutuo per la casa | Alto | 3 |
Il sistema non riesce a 200 utenti simultanei | Alto | 3 |
Il sistema non riesce a gestire i documenti che sono più di 6 MB | Basso | 4 |
Ora mettiamo insieme tutti questi attributi:
Caratteristica | Gravità | Priorità c vs c ++ sintassi | Probabilità |
Logica aziendale complessa in caso di calcolo del tasso di interesse del mutuo per la casa | Due | Due | 3 |
Il sistema non riesce a 200 utenti simultanei | 3 | 3 | 3 |
Il sistema non riesce a gestire i documenti che sono più di 6 MB | Due | 3 | 4 |
Ora calcoliamo il numero di priorità del rischio (RPN = Gravità * Priorità * Probabilità)
Caratteristica | Gravità | Priorità | Probabilità | RPN |
Logica aziendale complessa in caso di calcolo del tasso di interesse del mutuo per la casa | Due | Due | 3 | 12 |
Il sistema non riesce a 200 utenti simultanei | 3 | 3 | 3 | 27 |
Il sistema non riesce a gestire i documenti che sono più di 6 MB | Due | 3 | 4 | 24 |
Ora la chiave è: Più basso è l'RPN - Più alto è il rischio.
Quindi, qui per questo particolare esempio, la funzione 1 (logica aziendale complessa in caso di calcolo del tasso di interesse del mutuo per la casa) ha il rischio più elevato e la funzione 2 (il sistema non riesce a 200 utenti simultanei) ha il rischio più basso.
Come utilizzarlo per derivare casi di test?
Da Caratteristica 1 è il caratteristica più rischiosa , i casi di test dovrebbero essere rigorosi e più approfonditi. Scrivere i casi di test per coprire la funzionalità completa e i moduli che interessano la funzionalità. Utilizza tutti i tipi di tecniche di scrittura di casi di test ( Partizionamento di equivalenza e BVA , Causa ed effetto grafico , Diagramma di transizione di stato ) per derivare i casi di test.
I casi di test non dovrebbero essere solo funzionali ma anche non funzionali ( Test di carico , Stress e Volume test, ecc.). Fondamentalmente, dobbiamo eseguire test esaustivi di questa particolare funzionalità, quindi basare i tuoi casi di test di conseguenza. Inoltre, considera tutti i moduli dipendenti da questa importante funzione.
Caratteristica 2 è il Caratteristica MENO RISCHIOSA , quindi basa i tuoi casi di test sulle funzionalità principali. Dovrebbero essere sufficienti solo casi di test di alto livello per convalidare che la funzionalità funzioni come previsto.
Caratteristica 3 è un Caratteristica RISCHIO MODERATO , quindi basare i test case per coprire tutte le funzionalità principali e dipendenti. Scrivi alcuni casi di test BVA per convalidare anche alcuni scenari negativi. L'estensione dei casi di test dovrebbe essere compresa tra il fattore di rischio elevato e il fattore di rischio basso. Se necessario, includere anche alcuni casi di test non funzionali.
FMEA e grado di test
In base al valore RPN, determiniamo l'entità o il grado di test da eseguire.
Normalmente se:
- RPN è compreso tra 1 e 10, eseguiamo test approfonditi (coprendo dentro e fuori la funzione / modulo)
- RPN è compreso tra 11 e 30, eseguiamo test bilanciati (coprendo tutte le principali funzionalità della funzionalità / modulo)
- RPN è compreso tra 31 e 70, eseguiamo test di opportunità (coprendo le funzionalità di base della funzionalità / modulo)
- RPN è superiore a 70 - Nessun test o quando il tempo lo consente, solo segnalazione di anomalie.
Questi intervalli o numeri non sono limitati a quelli che ho menzionato sopra. Possono variare in base alla natura del progetto.
Risorse: Scarica Software FMEA e Modello FMEA .
Conclusione
L'analisi dei rischi utilizzando FMEA richiede tempo ed esperienza. I risultati desiderati possono essere raggiunti solo con la partecipazione paritaria di tutti i membri del team responsabili. Sebbene questa tecnica sia formale, richiede una serie di sessioni di brainstorming ed è altrettanto importante documentare tutti i rischi identificati.
domande di intervista pl sql per 5 anni di esperienza
Poiché la maggior parte delle applicazioni sono esclusive, la scala per misurare i parametri di FMEA (ovvero Priorità, Gravità e Probabilità) dipende anche dall'applicazione. Se eseguita in modo appropriato, ci sono molti vantaggi nella tecnica FMEA. Può essere utilizzato per identificare potenziali rischi e sulla base di questo team può pianificare un'efficace strategia di mitigazione.
Circa l'autore: Questo è un articolo ospite di Shilpa Chatterjee Roy. Ha lavorato nel campo del test del software negli ultimi 8,5 anni in vari domini.
Se hai utilizzato questa tecnica, non esitare a commentare la tua esperienza di seguito.
Lettura consigliata
- Tipi di rischi nei progetti software
- Quali sono gli attributi di qualità?
- Metti alla prova le tue capacità di analisi e capacità di pensiero - Esercizi di test del software (Parte 2)
- Comprensione reciproca nei test: una chiave per fornire un software di qualità
- Che cos'è Software Quality Assurance (SQA): una guida per principianti
- Processo di integrazione continua: come migliorare la qualità del software e ridurre i rischi
- Differenza tra garanzia di qualità e controllo di qualità (QA vs QC)
- I migliori 8 migliori software di gestione dei registri | Revisione dello strumento di analisi dei registri 2021