Analýza poruchových režimov a efektov (FMEA) - Ako analyzovať riziká pre lepšiu kvalitu softvéru a spokojných zákazníkov!

failure mode effects analysis how analyze risks

Analýza poruchových režimov a účinkov (FMEA) je technika riadenia rizík.

Ak je implementovaná správne, môže to byť vynikajúci doplnok k najlepším Procesy zabezpečovania kvality treba nasledovať. V tomto článku je našim cieľom predstaviť vám túto techniku ​​analýzy rizika, ktorá je nakoniec veľmi užitočná na zlepšenie kvality softvéru.

Čo sa dozviete:

• Analýza poruchových režimov a účinkov
• Čo je analýza rizík?
• Príklad analýzy vplyvu režimu zlyhania
• FMEA a stupeň testovania
• Záver
• Odporúčané čítanie

Analýza poruchových režimov a účinkov

FMEA väčšinou využívajú vrcholový manažment alebo zainteresované strany. V praxi majú testéri malý prehľad o tejto technike. Teraz sa však trend mení a mám pocit, že ak testéri tomuto konceptu rozumejú správne, môžu to urobiť riadiť ich myšlienkový proces písanie testovacích prípadov o jednu úroveň vyššie pomocou tejto techniky na:

• Pochopte ciele zúčastnenej strany pri testovaní aplikácie.
• Pochopte podnikanie.
• Odvodiť testovacie scenáre na vysokej úrovni na základe obchodných a manažérskych záujmov.
• Odvodzujte účinné testovacie prípady, ktoré poskytujú lepšie pokrytie rizikovým oblastiam.
• Uprednostnite testovacie prípady.
• Rozhodnite sa, čo otestovať a čo odložiť v ktorejkoľvek fáze.
  

Pozadie

ako inicializovať prepojený zoznam v

ANALÝZA RIZÍK je zásadným aspektom systému Správa testov . Potom sa naskytá otázka - Čo je analýza rizík? A prečo je to dôležité? Aby sme tomu porozumeli, je nevyhnutné pochopiť - čo je RIZIKO?

Pozri tiež => Typy rizík v softvérových projektoch.

RIZIKO ako jeho doslovný význam predstavuje možnosť negatívneho alebo nežiaduceho výsledku alebo udalosti. Riziká, pokiaľ nebudú správne zachádzané alebo riadené, môžu viesť k nekvalitným, nespokojným zákazníkom a niekedy k strate podnikania.

Riziko má dva atribúty:

• Pravdepodobnosť
• Dopad

Pravdepodobnosť znamená pravdepodobnosť vzniku konkrétneho rizika a vplyv znamená rozsah účinku rizika.

Čo je analýza rizík?

Analýza rizík je mechanizmus, pomocou ktorého sa identifikované potenciálne riziká podrobne analyzujú a študujú s cieľom zistiť pravdepodobnosť a vplyv. Je vhodné zmerať tieto dva atribúty a na základe výsledku ich identifikujeme:

• Čo otestovať ako prvé?
• Čo viac testovať?
• Čo netestovať (tentokrát)?

Existuje mnoho metód na vykonávanie analýzy rizík a sú zhruba rozdelené do dvoch typov:

• Neformálne techniky : Sú založené na skúsenostiach, úsudku a intuícii.
• Formálne techniky : Identifikácia a zváženie atribútov rizika.

F ochorenie M óda A JE účinky TO nalýza (FMEA): Toto je formálna metóda analýzy rizika. V nasledujúcich častiach budem ďalej diskutovať o FMEA a skús to rozpracovať s príkladom.

FMEA je formálna technika vykonávania analýzy rizík. Jedná sa o systematický a kvantitatívny nástroj vo forme tabuľky, ktorá pomáha členom analyzovať, čo by sa mohlo pokaziť. Aby sme mohli robiť FMEA, potrebujeme tých správnych ľudí na stole. Vyžaduje si zástupcu zo všetkých oblastí priemyslu vrátane zákazníkov.

Popis

FMEA začína a pokračuje v brainstormingu. Účastníci musia identifikovať všetky komponenty, moduly, závislosti, obmedzenia, ktoré by mohli zlyhať v produkčnom prostredí a nakoniec viesť k nízkej kvalite, spoľahlivosti a môžu viesť k strate podnikania.

Počas FMEA nielen identifikujeme rozsah straty, ale tiež sa pokúsime zistiť príčinu týchto zlyhaní. Na meranie FMEA potrebujeme 3 atribúty:

• Závažnosť poruchy (S)
• Priorita poruchy (P)
• Pravdepodobnosť poruchy (L)

Každý z týchto atribútov sme umiestnili do mierky zobrazenej nižšie:

Stupnica závažnosti:

Stupnica priority:

Stupnica pravdepodobnosti:

Všetky tieto tri atribúty (závažnosť, priorita a pravdepodobnosť) sa merajú jednotlivo v mierke a potom sa vynásobia, aby sa získalo Číslo priority rizika (RPN).

t.j. Číslo priority rizika ( RPN) = S * P * L

Na základe tejto hodnoty RPN určíme rozsah testovania. Menšie je RPN, vyššie je riziko.

Pokúsme sa to pochopiť na príklade:

Príklad analýzy vplyvu režimu zlyhania

(Toto je hypotetický príklad iba na účely porozumenia. Skutočná implementácia a funkcie sa môžu líšiť.)

Zoberme si jednoduchý príklad bankovej aplikácie, ktorá má 4 funkcie.

• Funkcia 1: Vyberte
• Funkcia 2: Záloha
• Funkcia 3: Pôžička na bývanie
• Funkcia 4: Fixné vklady.

Vytvára sa tím pre analýzu rizík, ktorý sa skladá z manažéra banky, UAT Správca testov (zastupujúci koncového používateľa), technický architekt, testovací architekt, správca siete, DBA a projektový manažér.

šablóna správy o vykonaní testu v programe Excel

Po sérii brainstormingov tím prišiel s nasledujúce riziká:

• Komplexná obchodná logika v prípade výpočtu úrokovej sadzby úveru na bývanie.
• Systém zlyhá pri 200 súbežných používateľoch.
• Systém nedokáže spracovať dokumenty, ktoré majú viac ako 6 MB.

Teraz sa pokúsime vypočítať závažnosť, prioritu a pravdepodobnosť týchto identifikovaných rizík.

Závažnosť:

Priorita:

Pravdepodobnosť:

Teraz poďme spojiť všetky tieto atribúty:

Teraz si vypočítajme číslo priority rizika (RPN = závažnosť * priorita * pravdepodobnosť)

Kľúč je teraz: Nižšie je RPN - vyššie je riziko.

Takže tu pre tento konkrétny príklad predstavuje funkcia 1 (Komplexná obchodná logika v prípade výpočtu úrokovej sadzby úveru na bývanie) najvyššie riziko a funkcia 2 (Systém zlyháva pri 200 súbežných používateľoch) má najnižšie riziko.

Ako to použiť na odvodenie testovacích prípadov?

Odkedy Funkcia 1 je najrizikovejšia vlastnosť , testovacie prípady by mali byť prísne a podrobnejšie. Napíšte testovacie prípady tak, aby pokrývali úplnú funkčnosť a ovplyvňovali moduly touto funkciou. Používajte všetky druhy techník písania testovacích prípadov ( Rozdelenie ekvivalencie a BVA , Graf príčin a následkov , Schéma prechodu stavu ) na odvodenie testovacích prípadov.

Testovacie prípady by mali byť nielen funkčné, ale aj nefunkčné ( Zaťažovací test , Stresový a objemový test atď.). V zásade musíme vykonať dôkladné testovanie tejto konkrétnej funkcie, takže podľa toho založte svoje testovacie prípady. Zvážte tiež všetky závislé moduly od tejto dôležitej funkcie.

Funkcia 2 je Funkcia LEAST RISKY , takže založte svoje testovacie prípady na hlavnej funkčnosti. Stačiť by mali iba testovacie prípady na vysokej úrovni, ktoré overia, či funkcia funguje podľa očakávania.

Funkcia 3 je a Funkcia MERNÉ RIZIKO , takže založte svoje testovacie prípady na pokrytí všetkých hlavných a závislých funkcií. Napíš niekoľko testovacích prípadov BVA, aby si overil aj niekoľko negatívnych scenárov. Rozsah testovacích prípadov by sa mal pohybovať medzi vysoko rizikovým a nízkorizikovým faktorom. V prípade potreby zahrňte aj niekoľko nefunkčných testovacích prípadov.

FMEA a stupeň testovania

Na základe hodnoty RPN určujeme rozsah alebo stupeň testovania, ktoré je potrebné vykonať.

Normálne, ak:

• RPN je medzi 1 - 10, robíme rozsiahle testovanie (zakrytie funkcie / modulu)
• RPN je medzi 11-30, robíme vyvážené testovanie (pokrývajúce všetky hlavné funkcie prvku / modulu)
• RPN je medzi 31-70, robíme testovanie príležitostí (pokrývajúce základnú funkčnosť funkcie / modulu)
• RPN je viac ako 70 - žiadne testovanie alebo keď to čas dovoľuje, iba anomálie.

Tieto rozsahy alebo čísla nie sú obmedzené na tie, ktoré som spomenul vyššie. Môžu sa líšiť podľa povahy projektu.

Zdroje: Stiahnuť ▼ Softvér FMEA a Šablóna FMEA .

Záver

Analýza rizík pomocou FMEA vyžaduje čas a skúsenosti. Požadované výsledky možno dosiahnuť iba rovnakou účasťou všetkých zodpovedných členov tímu. Aj keď je táto technika formálna, vyžaduje sériu brainstormingov a je rovnako dôležité zdokumentovať všetky identifikované riziká.

môžete pridať do poľa v jave?

Pretože väčšina aplikácií je exkluzívna, stupnica na meranie parametrov FMEA (t. J. Priorita, závažnosť a pravdepodobnosť) tiež závisí od aplikácie. Ak sa to urobí vhodným spôsobom, technika FMEA má veľa výhod. Môže byť použitý na identifikáciu potenciálnych rizík a na základe tohto tímu môže naplánovať efektívnu stratégiu zmierňovania.

O autorovi: Toto je hosťovský článok od Shilpy Chatterjee Royovej. Posledných 8,5 rokov pracuje v oblasti testovania softvéru v rôznych doménach.

Ak ste použili túto techniku, neváhajte komentovať svoje skúsenosti nižšie.

Odporúčané čítanie

• Typy rizík v softvérových projektoch
• Čo sú atribúty kvality?
• Vyskúšajte svoje schopnosti analýzy a myslenia - Cvičenia na testovanie softvéru (2. časť)
• Vzájomné porozumenie v testovaní: Kľúč pre dodávku kvalitného softvéru
• Čo je zabezpečenie kvality softvéru (SQA): Sprievodca pre začiatočníkov
• Proces nepretržitej integrácie: Ako zlepšiť kvalitu softvéru a znížiť riziko
• Rozdiel medzi zabezpečením kvality a kontrolou kvality (QA vs. QC)
• Najlepšie 8 NAJLEPŠÍ softvér na správu protokolov Recenzia nástroja na analýzu protokolov 2021