Analiza načina neuspjeha i efekata (FMEA) - Kako analizirati rizike za bolju kvalitetu softvera i zadovoljne kupce!

failure mode effects analysis how analyze risks

Analiza načina kvarova i učinaka (FMEA) je tehnika upravljanja rizikom.

Ako se pravilno primijeni, ovo može biti izvrstan dodatak najboljima Procesi osiguranja kvalitete koje treba slijediti. U ovom članku naš je cilj upoznati vas s ovom tehnikom analize rizika koja je na kraju vrlo korisna za poboljšanje kvalitete softvera.

Što ćete naučiti:

• Analiza načina neuspjeha i učinaka
• Što je analiza rizika?
• Primjer analize učinka neuspjeha
• FMEA i stupanj ispitivanja
• Zaključak
• Preporučena literatura

Analiza načina neuspjeha i učinaka

FMEA se uglavnom koristi od strane višeg menadžmenta ili dionika. U praksi testeri dobivaju malo uvida u ovu tehniku. Ali sada se trend mijenja i osjećam ako testeri pravilno razumiju ovaj koncept, mogu pokrenuti njihov misaoni proces pisanje test slučajeva na jedan nivo više pomoću ove tehnike za:

• Razumijevanje ciljeva dionika testiranja aplikacije.
• Shvatite posao.
• Izvedite scenarije ispitivanja na visokoj razini na temelju poslovnog i upravljačkog interesa.
• Izvedite učinkovite test slučajeve koji pružaju bolju pokrivenost rizičnim područjima.
• Dajte prioritet testnim slučajevima.
• Odlučite što ćete testirati i što odgoditi u bilo kojoj fazi.
  

Pozadina

ANALIZA RIZIKA je presudan aspekt Upravljanje testom . Tada se postavlja pitanje - Što je analiza rizika? I zašto je to važno? Da bismo to razumjeli, vitalno je razumjeti - što je RIZIK?

Također pogledajte => Vrste rizika u softverskim projektima.

RIZIK je kao njegovo doslovno značenje mogućnost negativnog ili neželjenog ishoda ili događaja. Rizici ako se njima ne rukuje ili se njima pravilno ne upravlja može dovesti do loše kvalitete, nezadovoljnih kupaca i ponekad do gubitka posla.

Rizik ima 2 atributa:

• Vjerojatnost
• Udarac

Vjerojatnost znači šanse da se dogodi određeni rizik, a utjecaj znači opseg učinka rizika.

Što je analiza rizika?

Analiza rizika je mehanizam kojim se identificirani potencijalni rizici detaljno analiziraju i proučavaju kako bi se pronašla vjerojatnost i utjecaj. Preporučljivo je izmjeriti dva atributa i na temelju rezultata koji identificiramo:

• Što prvo testirati?
• Što više testirati?
• Što ne testirati (ovaj put)?

Postoje mnoge metode izrade Analize rizika i one se široko klasificiraju u dvije vrste:

• Neformalne tehnike : Oni se temelje na iskustvu, prosuđivanju i intuiciji.
• Formalne tehnike : Identificiranje i vaganje svojstava rizika.

F tegoba M oda I. JE ffekti DO naliza (FMEA): Ovo je formalna metoda izrade Analize rizika. U sljedećim odjeljcima raspravljat ću više o FMEA i pokušajte to razraditi na primjeru.

FMEA je formalna tehnika provođenja Analize rizika. To je sustavni i kvantitativni alat u obliku Spread Sheet-a koji pomaže članovima da analiziraju što bi moglo pogriješiti. Da bismo obavili FMEA, potrebni su nam pravi ljudi. Potreban je predstavnik iz svih grana industrije, uključujući kupce.

Opis

FMEA započinje i nastavlja sesijama 'Mozgalice'. Sudionici trebaju identificirati sve komponente, module, ovisnosti, ograničenja koja mogu propasti u proizvodnom okruženju i na kraju dovesti do loše kvalitete, pouzdanosti i dovesti do gubitka posla.

Tijekom FMEA-e ne samo da utvrđujemo opseg gubitka, već također pokušavamo utvrditi uzrok tih kvarova. Za mjerenje FMEA potrebna su nam 3 atributa:

• Ozbiljnost neuspjeha (S)
• Prioritet neuspjeha (P)
• Vjerojatnost neuspjeha (L)

Svaki od ovih atributa stavljamo u dolje prikazanu ljestvicu:

Ljestvica ozbiljnosti:

Ljestvica prioriteta:

Ljestvica vjerojatnosti:

Sva ova tri atributa (ozbiljnost, prioritet i vjerojatnost) mjere se pojedinačno u mjerilu, a zatim množe da bi se dobio Broj s prioritetom rizika (RPN).

tj. Broj s prioritetom rizika ( RPN) = S * P * L

Na temelju ove RPN vrijednosti određujemo opseg testiranja. Manji je RPN, veći je rizik.

Pokušajmo to razumjeti na primjeru:

Primjer analize učinka neuspjeha

(Ovo je hipotetički primjer samo u svrhu razumijevanja. Stvarna primjena i značajke mogu se razlikovati)

Razmotrimo jednostavan primjer bankarske aplikacije koja ima 4 značajke.

• Značajka 1: Povući
• Značajka 2: Depozit
• Značajka 3: Zajam za dom
• Značajka 4: Fiksni depoziti.

Formiran je tim za analizu rizika koji se sastoji od upravitelja banke, UAT Voditelj testa (predstavlja krajnjeg korisnika), tehnički arhitekt, arhitekt testa, mrežni administrator, DBA i voditelj projekta.

Nakon niza brainstorminga tim je smislio sljedeći rizici:

• Složena poslovna logika u slučaju izračuna kamatne stope stambenog zajma.
• Sustav ne uspijeva kod 200 istovremenih korisnika.
• Sustav ne obrađuje dokumente veće od 6 MB.

Pokušajmo sada izračunati ozbiljnost, prioritet i vjerojatnost ovih identificiranih rizika.

Ozbiljnost:

Prioritet:

Vjerojatnost:

Sad spojimo sve ove atribute:

Sada izračunajmo broj prioriteta rizika (RPN = ozbiljnost * prioritet * vjerojatnost)

Sada je ključ: Niži je RPN - veći je rizik.

Dakle, ovdje za ovaj određeni primjer, značajka 1 (složena poslovna logika u slučaju izračunavanja kamatne stope stambenog zajma) ima najveći rizik, a značajka 2 (sustav ne uspijeva kod 200 istovremenih korisnika) ima najmanji rizik.

Kako to koristiti za izvođenje test slučajeva?

Od Značajka 1 je najrizičnija značajka , testovi trebaju biti rigorozni i detaljniji. Napišite slučajeve kako biste pokrili kompletnu funkcionalnost i značajke koje utječu na module. Koristite sve vrste tehnika pisanja testnih slučajeva ( Ekvivalentna particija i BVA , Graf uzroka i posljedica , Dijagram prijelaza države ) za izvođenje test slučajeva.

Test slučajevi ne bi trebali biti samo funkcionalni već i nefunkcionalni ( Ispitivanje opterećenja , Test naprezanja i glasnoće itd.). U osnovi, moramo izvršiti iscrpno testiranje ove značajke, pa prema tome temeljite svoje test slučajeve. Također, uzmite u obzir sve ovisne module o ovoj važnoj značajci.

Značajka 2 je Značajka NAJMANJI RIZIK , tako da svoje testove temeljite na glavnoj funkcionalnosti. Dovoljni bi bili samo testovi na visokoj razini da bi se potvrdilo da značajka radi kako se očekivalo.

Značajka 3 je UMJERENI RIZIK značajka , zato temeljite svoje test slučajeve kako biste pokrili sve glavne i ovisne funkcije. Napišite nekoliko slučajeva BVA testa kako biste potvrdili i nekoliko negativnih scenarija. Opseg ispitnih slučajeva trebao bi biti između faktora visokog i niskog rizika. Ako je potrebno, uključite i nekoliko nefunkcionalnih testnih slučajeva.

FMEA i stupanj ispitivanja

Na temelju vrijednosti RPN određujemo opseg ili stupanj testiranja koje treba obaviti.

Obično ako:

• RPN je između 1 i 10, radimo opsežno testiranje (pokrivanje i isključivanje značajke / modula)
• RPN je između 11-30, radimo uravnoteženo testiranje (pokriva sve glavne funkcionalnosti značajke / modula)
• RPN je između 31-70, radimo testiranje prilika (pokrivajući osnovnu funkcionalnost značajke / modula)
• RPN je veći od 70 - Nema ispitivanja ili kada to vrijeme dopušta, samo izvještavanje o anomaliji.

Ovi rasponi ili brojevi nisu ograničeni na one koje sam gore spomenuo. Mogu se razlikovati ovisno o prirodi projekta.

Resursi: preuzimanje datoteka FMEA softver i Predložak FMEA .

Zaključak

Analiza rizika korištenjem FMEA zahtijeva vrijeme i iskustvo. Željeni rezultati mogu se postići samo jednakim sudjelovanjem svih odgovornih članova tima. Iako je ova tehnika formalna, ona zahtijeva niz sesija mozga i jednako je važno dokumentirati sve identificirane rizike.

Budući da je većina aplikacija isključiva, ljestvica za mjerenje parametara FMEA (tj. Prioritet, ozbiljnost i vjerojatnost) također ovisi o aplikaciji. Ako se to učini na odgovarajući način, FMEA tehnika ima mnogo prednosti. Može se koristiti za identificiranje potencijalnih rizika i na temelju ovog tima može planirati učinkovitu strategiju ublažavanja.

O autoru: Ovo je gostujući članak Shilpe Chatterjee Roy. Posljednjih 8,5 godina radi na polju testiranja softvera u raznim domenama.

Ako ste koristili ovu tehniku, slobodno komentirajte svoje iskustvo u nastavku.

Preporučena literatura

• Vrste rizika u softverskim projektima
• Koji su atributi kvalitete?
• Testirajte svoje mogućnosti analize i snage razmišljanja - Vježbe testiranja softvera (2. dio)
• Međusobno razumijevanje u testiranju: ključ za isporuku kvalitetnog softvera
• Što je osiguranje kvalitete softvera (SQA): Vodič za početnike
• Kontinuirani proces integracije: kako poboljšati kvalitetu softvera i smanjiti rizik
• Razlika između osiguranja kvalitete i kontrole kvalitete (QA vs QC)
• 8 najboljih NAJBOLJIH programa za upravljanje zapisima | Pregled alata za analizu dnevnika 2021