Meniu

Analiza modului de eșec și a efectelor (FMEA) - Cum să analizăm riscurile pentru o calitate software mai bună și clienți satisfăcuți!

failure mode effects analysis how analyze risks

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Modul de eșec și analiza efectelor (FMEA) este o tehnică de gestionare a riscurilor.

diferența dintre testarea alfa și beta

Dacă este implementat în mod corespunzător, acesta poate fi un plus excelent pentru cei mai buni Procese de asigurare a calității de urmat. În acest articol, scopul nostru este să vă prezentăm această tehnică de analiză a riscurilor, care, în cele din urmă, este foarte utilă pentru îmbunătățirea calității software-ului.

Modul de eșec și analiza efectelor (FMEA)

Ce veți învăța:

Modul de eșec și analiza efectelor

FMEA este utilizat în principal de către conducerea superioară sau părțile interesate. În practică, testerii obțin puține informații despre această tehnică. Dar acum tendința se schimbă și simt că dacă testerii înțeleg acest concept în mod corespunzător, pot conduce procesul lor de gândire a scrierea cazurilor de testare la un nivel mai mare utilizând această tehnică pentru:

  • Înțelegeți obiectivele părții interesate de testare a aplicației.
  • Înțelegeți afacerea.
  • Derivați scenariile de testare la nivel înalt bazate pe interesul pentru afaceri și management.
  • Derivați cazuri de testare eficiente, care oferă o acoperire mai bună zonelor cu risc.
  • Prioritizează cazurile de testare.
  • Decideți ce să testați și ce să amâne în orice fază.

fundal

ANALIZA RISCURILOR este un aspect crucial al Managementul testelor . Apoi apare întrebarea - Ce este analiza riscurilor? Și de ce este important? Pentru a înțelege acest lucru, este vital să înțelegeți - ce este RISCUL?

analiza de risc

Vezi și => Tipuri de riscuri în proiectele software.

RISCUL ca sens literal al acestuia este posibilitatea unui rezultat sau eveniment negativ sau nedorit. Dacă nu sunt tratate sau gestionate corespunzător, riscurile pot duce la slabă calitate, clienți nesatisfăcuți și, uneori, pierderea afacerii.

Riscul are 2 atribute:

  • Probabilitate
  • Impact

Probabilitatea înseamnă șansele ca un anumit risc să apară și impactul înseamnă amploarea efectului riscului.

Ce este analiza riscurilor?

Analiza riscurilor este un mecanism prin care riscurile potențiale identificate sunt analizate și studiate în detaliu pentru a găsi probabilitatea și impactul. Este recomandabil să măsurăm cele două atribute și pe baza rezultatului pe care îl identificăm:

  • Ce să testăm mai întâi?
  • Ce să testăm mai mult?
  • Ce să nu testez (de data aceasta)?

Există multe metode de a face analiza riscurilor și sunt clasificate în două tipuri:

  • Tehnici informale : Acestea se bazează pe experiență, judecată și intuiție.
  • Tehnici formale : Identificarea și cântărirea atributelor de risc.

F ailure M oda Și ESTE efectele LA naliză (FMEA): Aceasta este o metodă formală de a face o analiză a riscurilor. În secțiunile următoare, voi discuta mai multe despre FMEA și încercați să o elaborați cu exemplul.

FMEA este o tehnică formală de analiză a riscurilor. Este un instrument sistematic și cantitativ sub forma unei foi de calcul care îi ajută pe membri să analizeze ce ar putea greși. Pentru a face FMEA avem nevoie de oamenii potriviți pe masă. Este nevoie de un reprezentant din toate domeniile industriei, inclusiv clienți.

Descriere

FMEA începe și continuă cu sesiuni de brainstorming. Participanții trebuie să identifice toate componentele, modulele, dependențele, limitările care ar putea eșua într-un mediu de producție și, în cele din urmă, ar duce la calitate slabă, fiabilitate și ar putea duce la pierderea afacerii.

În timpul FMEA, nu numai că identificăm gradul pierderii, dar încercăm să identificăm cauza acestor eșecuri. Pentru a măsura FMEA, avem nevoie de 3 atribute:

  • Severitate al eșecului (S)
  • Prioritate al eșecului (P)
  • Probabilitate al eșecului (L)

Am pus fiecare dintre aceste atribute într-o scară prezentată mai jos:

Scara de severitate:

Descriere Clasă Scară
Pierderea de date, hardware sau probleme de siguranță Urgent 1
Pierderea funcționalității fără o soluție Înalt Două
Pierderea funcționalității cu o soluție alternativă Mediu 3
Pierderea parțială a funcționalității Scăzut 4
Cosmetice sau banale Nici unul 5

Scala prioritară:

Descriere Clasă Scară
Pierderea completă a valorii sistemului Urgent 1
Pierderea inacceptabilă a valorii sistemului Înalt Două
Eventual reducerea valorii sistemului Mediu 3
Reducere acceptabilă a valorii sistemului Scăzut 4
O reducere neglijabilă a valorii sistemului Nici unul 5

Scala de probabilitate:

Descriere Clasă Scară
Sigur că va afecta toți utilizatorii Urgent 1
Este posibil să afecteze unii utilizatori Foarte inalt Două
Impact posibil asupra unor utilizatori Înalt 3
Impact limitat asupra câtorva utilizatori Scăzut 4
Inimaginabil în utilizarea reală Nici unul 5

Toate aceste trei atribute (severitate, prioritate și probabilitate) sunt măsurate individual în scară și apoi înmulțite pentru a obține un Numărul de prioritate de risc (RPN).

care este diferența dintre Linux și Unix

adică Numărul priorității de risc ( RPN) = S * P * L

Pe baza acestei valori RPN, determinăm gradul de testare. RPN este mai mic, riscul este mai mare.

Să încercăm să o înțelegem cu un exemplu:

Exemplu de analiză a efectului modului de eșec

(Acesta este un exemplu ipotetic numai pentru un scop de înțelegere. Implementarea și caracteristicile reale pot varia)

Să luăm în considerare un exemplu simplu de aplicație bancară care are 4 funcții.

  • Caracteristica 1: Retrage
  • Caracteristica 2: Depozit
  • Caracteristica 3: Împrumut pentru casă
  • Caracteristica 4: Depozite fixe.

Se formează o echipă de analiză a riscurilor care este formată din managerul băncii, UAT Manager de testare (reprezentând utilizatorul final), arhitect tehnic, arhitect de testare, administrator de rețea, DBA și un manager de proiect.

După o serie de sesiuni de brainstorming, echipa a venit cu următoarele riscuri:

  • Logică de afaceri complexă în cazul calculării ratei dobânzii împrumutului la domiciliu.
  • Sistemul eșuează la 200 de utilizatori simultani.
  • Sistemul nu reușește să gestioneze documente care depășesc 6 MB.

Acum, să încercăm să calculăm severitatea, prioritatea și probabilitatea acestor riscuri identificate.

Severitate:

Caracteristică Clasă Scară
Logică complexă a afacerii în cazul calculării ratei dobânzii la împrumutul pentru locuință Foarte inalt Două
Sistemul eșuează la 200 de utilizatori simultani Înalt 3
Sistemul nu reușește să gestioneze documente care depășesc 6 MB Foarte inalt Două

Prioritate:

Caracteristică Clasă Scară
Logică complexă a afacerii în cazul calculării ratei dobânzii la împrumutul pentru locuințe Foarte inalt Două
Sistemul eșuează la 200 de utilizatori simultani Înalt 3
Sistemul nu reușește să gestioneze documente care depășesc 6 MB Înalt 3

Probabilitate:

Caracteristică Clasă Scară
Logică complexă a afacerii în cazul calculării ratei dobânzii la împrumutul pentru locuințe Înalt 3
Sistemul eșuează la 200 de utilizatori simultani Înalt 3
Sistemul nu reușește să gestioneze documente care depășesc 6 MB Scăzut 4

Acum să combinăm toate aceste atribute:

Caracteristică

Severitate

Prioritate

Probabilitate

Logică complexă a afacerii în cazul calculării ratei dobânzii la împrumutul pentru locuințe Două Două 3
Sistemul eșuează la 200 de utilizatori simultani 3 3 3
Sistemul nu reușește să gestioneze documente care depășesc 6 MB Două 3 4

Acum, să calculăm numărul priorității de risc (RPN = Severitate * Prioritate * Probabilitate)

Caracteristică

Severitate

Prioritate

Probabilitate

RPN

Logică complexă a afacerii în cazul calculării ratei dobânzii la împrumutul pentru locuințe Două Două 3 12
Sistemul eșuează la 200 de utilizatori simultani 3 3 3 27
Sistemul nu reușește să gestioneze documente care depășesc 6 MB Două 3 4 24

Acum cheia este: RPN este mai mic - Riscul este mai mare.

Așadar, pentru acest exemplu particular, caracteristica 1 (logică complexă a afacerii în cazul calculării ratei dobânzii împrumutului la domiciliu) prezintă cel mai mare risc, iar caracteristica 2 (sistemul eșuează la 200 de utilizatori concurenți) prezintă cel mai mic risc.

Cum se folosește acest lucru pentru a obține cazuri de testare?

De cand Caracteristica 1 este cea mai riscantă caracteristică , cazurile de testare ar trebui să fie riguroase și mai aprofundate. Scrieți cazurile de testare pentru a acoperi funcționalitatea completă și modulele care afectează funcția. Folosiți tot felul de tehnici de scriere a cazurilor de test ( Partiționarea echivalenței și BVA , Graficul cauzei și efectului , Diagrama tranziției de stat ) pentru a deriva cazurile de testare.

Testele nu trebuie doar să fie funcționale, ci și nefuncționale ( Test de încărcare , Test de stres și volum etc.). Practic, trebuie să facem teste exhaustive ale acestei caracteristici particulare, deci bazați-vă cazurile de testare în consecință. De asemenea, luați în considerare toate modulele dependente de această caracteristică importantă.

Caracteristica 2 este Caracteristică LEAST RISKY , deci bazați-vă cazurile de testare pe funcționalitatea majoră. Doar cazuri de testare la nivel înalt pentru a confirma că funcția funcționează așa cum era de așteptat ar trebui să fie suficiente.

Caracteristica 3 este o Caracteristică RISC MODERAT , deci bazați-vă cazurile de testare pentru a acoperi toate funcționalitățile majore și dependente. Scrieți câteva cazuri de testare BVA pentru a valida și câteva scenarii negative. Extinderea cazurilor de testare ar trebui să fie între factorul de risc ridicat și factorul de risc scăzut. Dacă este necesar, includeți și câteva cazuri de testare nefuncționale.

FMEA și gradul de testare

Pe baza valorii RPN, determinăm gradul sau gradul de testare care trebuie efectuat.

În mod normal dacă:

  • RPN este între 1-10, facem teste extinse (acoperirea în și în afara caracteristicii / modulului)
  • RPN este între 11-30, facem teste echilibrate (acoperind toate funcționalitățile majore ale caracteristicii / modulului)
  • RPN este între 31-70, facem teste de oportunitate (acoperind funcționalitatea de bază a caracteristicii / modulului)
  • RPN este mai mare de 70 - Fără testare sau când timpul permite, doar raportarea anomaliilor.

Aceste intervale sau numere nu sunt limitate la cele menționate mai sus. Ele pot varia în funcție de natura proiectului.

Resurse: Descarca Software FMEA și Șablon FMEA .

Concluzie

Analiza riscurilor utilizând FMEA necesită timp și experiență. Rezultatele dorite pot fi obținute numai prin participarea egală a tuturor membrilor echipei responsabile. Deși această tehnică este formală, necesită o serie de sesiuni de brainstorming și este la fel de important să se documenteze toate riscurile identificate.

este o cheie de rețea la fel ca o parolă

Deoarece majoritatea aplicațiilor sunt exclusive, scala pentru măsurarea parametrilor FMEA (adică Prioritate, Severitate și Probabilitate) depinde și de aplicație. Dacă se face în mod corespunzător, există multe avantaje ale tehnicii FMEA. Poate fi folosit pentru identificarea riscurilor potențiale și pe baza acestei echipe poate planifica o strategie eficientă de atenuare.

Despre autor: Acesta este un articol invitat de Shilpa Chatterjee Roy. Lucrează în domeniul testării software în ultimii 8,5 ani în diferite domenii.

Dacă ați folosit această tehnică vă rugăm să nu ezitați să comentați experiența dvs. de mai jos.

Lectură recomandată

^