Sprievodca testovaním na základe rizika: Riadenie rizika pri testovaní softvéru

ultimate guide risk based testing

Sprievodca testovaním na základe rizík, riadením rizika a jeho prístupom s príkladmi:

Čo je testovanie založené na riziku?

Testovanie na základe rizika je vykonať testovanie alebo navrhnúť a vykonať scenáre tak, aby sa v ich produkte alebo funkcii objavili začiatkom obchodného cyklu hlavné obchodné riziká, ktoré budú mať negatívny vplyv na podnikanie, ako ich identifikuje zákazník. zmierniť vykonaním zmierňovacích opatrení.

=> Kliknutím sem zobrazíte kompletnú sériu návodov na kompletný testovací plán

Negatívny vplyv môže zahŕňať vplyv na náklady, nespokojný zákazník, zlá používateľská skúsenosť a dokonca do tej miery, že stratí zákazníkov.

Inými slovami, prístupom RBT je zabezpečiť, aby sa testovanie uskutočňovalo takým spôsobom, že aj keď ide o používateľa nájde chybu vo výrobe, ktorá mu nebráni v používaní softvéru alebo nemá závažný dopad na podnikanie.

RBT sa testuje na základe rizík produktu. RBT má zistiť v dostatočnom časovom predstihu, aké je riziko zlyhania konkrétnej vlastnosti alebo funkčnosti vo výrobe a ich dopad na podnikanie z hľadiska nákladov a iných škôd použitím techniky stanovenia priorít pre testovacie prípady.

Preto testovanie založené na riziku využíva princíp uprednostnenie testov funkcií, modulov a funkcií produktu alebo softvéru. Stanovenie priorít je založené na riziku pravdepodobnosti zlyhania tejto funkcie alebo funkčnosti vo výrobe a jej vplyve na zákazníkov.

Čo sa dozviete:

• Testovanie na základe rizika a jeho význam pre agilné a devOps
  • Prístup založený na hodnotení rizika
    • Kedy použijeme prístup RBT?
    • Príklad prístupu RBT
  • Spôsoby vykonania analýzy rizík
  • Postup analýzy rizika
  • Metodika analýzy rizika
    • Krok 1) Použitie mriežky 3X3
    • Krok 2) Pravdepodobnosť a vplyv zlyhania
    • Krok č. 3) Testovanie prioritnej mriežky
    • Krok č. 4) Podrobnosti o testovaní
  • Ako je RBT relevantný pre agilný a devOps?
  • Výhody prístupu založeného na testovaní na riziku
• Riadenie rizika počas plánovania testov
  • Proces riadenia rizík
    • # 1) Identifikácia rizika
    • # 2) Posúdenie rizika / Analýza rizikových vplyvov
    • # 3) Zmiernenie rizika
  • Záver
• Riadenie rizika vo fáze vykonania testu (s príkladom)
  • Riadenie rizík - so zameraním na AUT
  • Ako prebieha testovanie základov rizík?
  • Záver
  • Odporúčané čítanie

Testovanie na základe rizika a jeho význam pre agilné a devOps

Tristo hodín strávených vývojom softvéru môže byť zbytočných za pouhých 30 sekúnd s jedinou chybou zistenou pri výrobe.

To zase môže zničiť účel celého produktu bez inej možnosti, ako len stiahnuť ho z trhu. A to je význam a potreba „testovania kvality“.

Vďaka rýchlemu rozvoju technológií je softvér hostený v cloude, ktorý podporuje viac operačných systémov, viaceré platformy, komplexné IT infraštruktúry atď., Sú koncoví používatelia čoraz viac znepokojení nad funkciami, možnosťami a nikdy neohrozujú spokojnosť zákazníka. .

V dnešnej dobe sa „kvalita“ stáva rozhodujúcim faktorom pri dodávaní softvéru, kde sa neustále zlepšujú, aby sa zvýšila kvalita, aby zákazníci boli spokojní.

Často si všimneme, že takmer všetkým testerom býva častým problémom byť pod obrovským tlakom, že ich testovacie okno je stlačené a obvykle im je zostava odovzdaná na testovanie na poslednú chvíľu. Nie je pre nich dostatok času a zdrojov na vykonanie všetkých testov, ktoré navrhli, a pokrytie automatizáciou nie je vždy stopercentné a má svoje vlastné výzvy.

Nemožno premeškať časovú os dodania a zároveň nemožno znížiť kvalitu. Čokoľvek plán B, pridať ďalšie testovacie zdroje vytiahnutím z ostatných tímov, nefunguje, plán C, prestať robiť všetky ostatné činnosti a presmerovať na to úsilie, v skutočnosti nepomáha. Avšak veľa pridania testovacích zdrojov nakoniec nefunguje.

Nie je iná možnosť, ako len spustiť obmedzené a dôležité testy v rámci dostupného času a zdrojov.

Ako teda rozhodneme, ktorý test je v tejto fáze dôležitý? Čokoľvek považuje Tester za dôležité, nemusí byť pre zákazníkov skutočne dôležité. Z koho pohľadu sa rozhoduje o dôležitosti vlastnosti alebo funkcií? Kto rozhodne, ktoré sú dôležité testy? A vynára sa stále veľa ďalších otázok.

Za účelom zodpovedania všetkých týchto otázok a efektívneho zvládnutia vyššie uvedenej situácie sa volal testovací prístup „Testovanie na základe rizika“ , krátko zavolal „RBT“ , kde tím jasne naplánoval a identifikoval testovacie scenáre na základe kritérií „Riziko projektu“.

Aj keď má tím QA jasný obraz o dôležitých testoch, RBT je osvedčenou metódou identifikácie rozhodujúcich a dôležitých testov z hľadiska zákazníka a obchodu prostredníctvom 'Analýza rizík' postup .

Takže oproti tradičnému spôsobu jednoduchej identifikácie chýb softvéru sa prístup a cieľ QA časom zmenili v dôsledku zmeny technológie, zvýšenia konkurencie na trhu s vydaním kvalitného softvéru, zavedenia „Automatizovať všetko“ a v úplnom zavedení praxe Agile a DevOps dodania softvéru v priebehu niekoľkých hodín.

Súčasný trend „princípu testovania“ teda neznamená iba „identifikáciu chýb“, ale tiež

# 1) Zamerajte sa na oblasť produktu, kde je vysoký vplyv na podnikanie z dôvodu zlyhania alebo vysokej pravdepodobnosti zlyhania výroby.

#dva) Zameranie na identifikácia vád skoro a umožňuje tímu opraviť ho čo najskôr, a teda umožňuje softvéru / produktu alebo funkcii „Fail Fast“.

# 3) Najdôležitejším aspektom Služby tímu QA je zamerať sa na zákazníka pri prinášaní hodnoty pre zákazníka zvýšením zamerania na „Komplexná zákaznícka skúsenosť“.

Prístup založený na hodnotení rizika

Vždy je to ako pripraviť sa na vyšetrenie, že človek nemôže povedať, že testovanie je dostatočné a že softvér už neobsahuje chyby, a to ani vtedy, ak navrhujú a vykonávajú veľké množstvo testov.

Existuje bod, v ktorom nebude stabilita softvéru zaistená dvojnásobne zvýšením počtu samotných testovacích prípadov. V tomto okamihu nejde len o to zamerať sa na počet testov, ale aj na to, čo zákazník v skutočnosti od uvedenia očakáva.

Preto je nevyhnutné nájsť rovnováhu v optimalizácii testovania, aby ste dosiahli maximálny úžitok pri vynaložení primeraného úsilia pri testovaní. A to je dôležitejšie, keď sú harmonogramy testovania veľmi krátke a nie je k dispozícii dostatok zdrojov na vykonanie dostatočného testovania.

V tomto prípade teda prístup RBT hrá kľúčovú úlohu pri optimalizácii úsilia o zabezpečenie kvality a maximalizácii úžitku z testovania s minimálnym obchodným rizikom.

Ak sa teda zameriame na vyššie uvedený aspekt, potom sa práci QA veľmi uľaví. Nemusia spáliť víkendy v kancelárii, neustále testovať softvér a obávať sa všetkých chýb S4 (závažnosť 4) a P4 (priorita 4), ktoré z testovania vychádzajú.

4 sa považuje za najnižšiu prioritu a závažnosť chýb pri testovaní. Môžu tak lepšie investovať svoj čas do ďalších užitočných aspektov projektu.

Ak zhrnieme kľúčové hnacie sily prístupu „Testovanie na základe rizika“:

• Umožniť testovanie „toho, čo zákazníci chcú“ z obchodného hľadiska.
• Splniť časový harmonogram s očakávanou kvalitou.
• Optimalizovať úsilie QA.

Kedy použijeme prístup RBT?

Používa sa v nasledujúcich scenároch:

• Prístup RBT je možné použiť vždy, keď existuje obmedzenie alebo obmedzenie času, nákladov a zdrojov projektu a kedykoľvek je potrebné optimalizovať zdroje.
• Prístup RBT sa používa, keď je program zložitejší a prispôsobuje novú technológiu, a preto zahŕňa veľa výziev.
• Ak je program výskumným a vývojovým projektom a je prvého typu, obsahuje veľa neznámych a rizík.

Príklad prístupu RBT

V IT priemysle sa na prekonanie rizík, ktorým čelí výroba a jej dopady, používa niekoľko prístupov založených na analýze rizika.

Ďalej je uvedený jeden takýto prístup:

Tento prístup RBT zahŕňa identifikáciu „životne dôležitých funkcií alebo kľúčových vlastností“ produktu a hodnotenie rizík, ktorým je každá z týchto funkcií vystavená pri výrobe, a implementácia vhodných zmierňovacích opatrení na zníženie alebo zmiernenie rizika.

Prístup RBT preto zahŕňa testovanie funkcionalít, ktoré majú pravdepodobnosť zlyhania a najväčší dopad na podnikanie. Typy porúch môžu byť prevádzkové alebo obchodné, technické, externé atď.

Spôsoby vykonania analýzy rizík

Neexistuje žiadny štandardný proces alebo šablóna, ktoré by boli definované ako také na vykonávanie analýzy rizík pri testovaní softvéru pre každú vlastnosť produktu. Rôzne organizácie používajú vlastný prístup k metódam analýzy rizika.

Analýzu rizík je možné vykonať na rôznych položkách projektu s cieľom identifikovať riziká a implementovať prístup RBT pre analýzu. Medzi tieto položky patrí,

• Vlastnosti
• Funkčnosti
• Príbehy používateľov
• Požiadavky
• Prípady použitia
• Testovacie prípady

V takom prípade sa zamerajme iba na Testovacie prípady, aby sme pochopili implementáciu prístupu založeného na testovaní na základe rizika.

Postup analýzy rizika

Analýza rizika zahŕňa zapojenie príslušných zainteresovaných strán programu z „Programu Technický tím a obchodný tím “ , ktorá zahŕňa vlastníka produktu, produktových manažérov, obchodných analytikov, architektov, testerov a zástupcov zákazníkov.

Zorganizovali by sa brainstormingové stretnutia s účasťou týchto zainteresovaných strán, aby sa uskutočnila diskusia s cieľom zistiť dôležitosť každej vlastnosti produktu a určiť ich prioritu na základe rizika zlyhania a jeho dopadu na koncových používateľov vo výrobe.

Vstupom do brainstormingu sa stanú rôzne „projektové dokumenty“, ako napríklad dokument s požiadavkami, dokumenty s technickými špecifikáciami, dokumenty o architektúre a dizajne, dokument obchodného procesu, dokument prípadu použitia atď.

Vstupným faktorom pre diskusiu budú aj znalosti zúčastnených strán o produkte a existujúcom produkte na trhu.

Niekoľko ďalších zdrojov vstupov môže tiež obsahovať,

• Zhromažďovať vstupy o najpoužívanejších funkciách.
• Príspevky od konzultácie s odborníkom na doménu.
• Údaje z predchádzajúcej verzie produktu alebo podobného produktu na trhu.

Počas brainstorming sú spojené riziká spojené s každou z týchto funkcií. Typy rizík môžu byť prevádzkové, technické alebo súvisiace s podnikaním. Testy a scenáre, ktoré sa ich týkajú, sú vážené a hodnoty rizika sa hodnotia na základe pravdepodobnosti výskytu rizika a dopadu rizika.

„Pravdepodobnosť výskytu rizika“ môže byť spôsobená:

• Zlé pochopenie funkcie tímom pre vývoj produktov.
• Nesprávna architektúra a dizajn.
• Nedostatočný čas na návrh.
• Nekompetentnosť tímu.
• Nedostatočné zdroje - ľudia, nástroje a technológie.

„Vplyv rizika“ je účinok zlyhania na používateľov a podnik, ak k nemu dôjde. Dopad by mohol byť,

• Vplyv na náklady, ktorý vedie k strate.
• Dopad na podnikanie vedúci k strate podnikania alebo strate podielu na trhu, Súdne konania, Strata licencie.
• Vplyv na kvalitu, ktorý vedie k neštandardnému alebo nekompetentnému uvoľneniu produktu.
• Zlá používateľská skúsenosť, ktorá vedie k nespokojnosti a strate zákazníka.

Oblasť zamerania na hodnotenie rizika funkcie alebo produktu môže byť,

• Oblasť obchodnej kritiky funkčnosti.
• Najpoužívanejšie funkcie a najdôležitejšie funkcie.
• Oblasti náchylné na chyby
• Funkčnosť, ktorá má vplyv na bezpečnosť a zabezpečenie.
• Oblasť komplexného dizajnu a architektúry.
• Zmeny vykonané v predchádzajúcich verziách.

Metodika analýzy rizika

Poďme teraz podrobne pochopiť „metodiku testovania na základe rizík“.

Prístup k testovaniu založenému na riziku používa RIZIKO ako kritérium vo všetkých testovacích fázach testovacieho cyklu, t. J. plánovanie testov , návrh testu, implementácia testu, vykonanie skúšky a testovacie správy. V ideálnom prípade je možné navrhnúť veľké množstvo možných kombinácií testovacích scenárov.

Prístup RBT preto zahŕňa poradie testov na základe závažnosti rizík s cieľom zistiť najporuchovejšiu alebo najrizikovejšiu oblasť zlyhania, ktorá má vysoký dopad na podnikanie.

Hlavným cieľom analýzy rizík je rozlíšiť medzi 'Vysoká hodnota' položky ako vlastnosti produktu, funkcie, požiadavky, príbehy používateľov a testovacie prípady a „ Nízka hodnota “ a neskôr sa viac zamerať na testovacie prípady „vysokej hodnoty“, tým menej sa zamerať na testovacie prípady „nízkej hodnoty“. Toto je počiatočný krok analýzy rizika pred začatím testovania na základe rizika.

Hlavná úloha Kategorizácia alebo zoskupenie testovacích prípadov do sekcie Vysoká hodnota a Nízka hodnota a priradenie hodnoty priority každému z týchto testovacích prípadov zahŕňa nasledujúce kroky:

Krok 1) Použitie mriežky 3X3

Analýza rizík sa vykonáva pomocou mriežky 3X3, kde každá funkčnosť, nefunkčnosť a súvisiace testovacie prípady sú posudzované tímom zainteresovaných strán pre jej „Pravdepodobnosťzlyhania “a„ Dopad zlyhania “.

K pravdepodobnosti zlyhania každej funkcionality vo výrobe pristupuje skupina „technických expertov“ a sú kategorizované ako „pravdepodobné zlyhanie, dosť pravdepodobné a nepravdepodobné“ pozdĺž zvislej osi mriežky.

ako obrátiť poradie poľa v jave -

Podobne „dopady zlyhania“ týchto funkcií a funkcií na výrobu zažíva koncový zákazník, ak nie je testovaný, hodnotí ho skupina „ Obchodní špecialisti “a sú zaradené do kategórií„ Menšie, viditeľné a prerušenie “pozdĺž vodorovnej osi mriežky.

Krok 2) Pravdepodobnosť a vplyv zlyhania

Všetky testovacie prípady sú umiestnené v kvadrantoch mriežky 3 x 3 na základe identifikovaných hodnôt pravdepodobnosti poruchy a dopadu poruchy, ktoré sú na nasledujúcom obrázku zobrazené ako bodky.

Je zrejmé, že vysoká pravdepodobnosť poruchy a vysoký dopad poruchy (prerušenia) sú zoskupené v pravom hornom rohu mriežky, čo je veľmi dôležité, a preto sa zistilo, že testy „vysokej hodnoty“ a „nízkej hodnoty“ sú zoskupené ľavý dolný roh, ktorý má pre zákazníka najmenší alebo žiadny význam, pričom sa týmto funkciám alebo testovacím prípadom môže venovať menšia pozornosť.

Krok č. 3) Testovanie prioritnej mriežky

Na základe vyššie uvedeného umiestnenia testovacích prípadov v mriežke sú testy prioritizované a označené prioritami 1,2,3,4 a 5 a sú označené proti každému z nich. Najdôležitejšie testy sú umiestnené v 1^svmriežka, ktorej je priradená priorita 1 a podobne menej dôležité, sú klasifikované ako 2, 3, 4 a 5.

Nakoniec sú všetky testovacie prípady zoradené podľa ich počtu priorít a sú vybrané na vykonanie v poradí podľa priority. Tie s vysokou prioritou sa vyberú na vykonanie ako prvé a tie s nízkou prioritou sa vykonajú neskôr alebo sa odstránia z rozsahu.

Krok č. 4) Podrobnosti o testovaní

Ďalším krokom je rozhodnutie o úrovni podrobností testovania pre definovaný rozsah testovania. O hĺbke rozsahu testovania možno rozhodnúť na základe vyššie uvedeného poradia podľa tabuľky nižšie.

Testy s vysokou prioritou s hodnotením 1 sa testujú „dôkladnejšie“ a podľa toho sa nasadia odborníci na testovanie týchto funkcií s vysokou kritickosťou a súvisiacich testovacích prípadov. Podobne je možné prijať testovacie prípady s prioritou 2, 3 a 4. Na základe dostupného času a zdrojov je možné prijať rozhodnutie o odstránení rozsahu funkcií priority 5 a testov.

Prístup úrovne podrobností testovania pri určovaní priorít funkcií a ich testovacích prípadov teda testerom pomáha nielen pri identifikácii „testov vysokej hodnoty“, ale vedie ich aj pri rozhodovaní o ich „podrobnej úrovni testovania“ na základe týchto prioritných hodnotení a pomáha im pri lepšom testovaní a optimalizačným procesom znižuje náklady na testovanie.

Ako je RBT relevantný pre agilný a devOps?

Teraz, po pochopení prístupu pri testovaní založenom na riziku, ktorý spočíva v uskutočňovaní testovania na základe stanovenia priorít testov v závislosti od „rizika zlyhania“ konkrétnej vlastnosti a jej „dopadu na zákazníka“ v priamom prenose, by bolo zjavné položiť si otázku relevantnosť prístupu založeného na hodnotení rizík v agilných postupoch a postupoch DevOps.

Kľúčové koncepty týchto postupov sú „Automatizovať všetko“, „Testovať všetko“, „Testovať nepretržite“, „Testovať opakovane“.

Zakaždým, keď dôjde k zmene kódu alebo k jeho vydaniu, všetky navrhnuté testy sa spustia automatizovane Kontinuálna integrácia (CI) / Nepretržité doručovanie (CD) rýchlo a opakovane, bez ohľadu na ich stanovenie priorít.

Aký je potom vzťah medzi RBT a DevOps? Kam by zapadol RBT a stal by sa relevantným v Agile a DevOps ???

# 1) Áno, ako som už uviedol skôr, nie je to tak, že každý priemysel a každý produkt má 100% automatizované pokrytie pre svoje testovacie vykonania. Ak teda tím musí vôbec zvoliť uprednostňovanie vykonania testu z výberu manuálnych testovacích prípadov a chcel by ušetriť energiu a úsilie testovacích zdrojov na ďalšie činnosti, potom je RBT najlepšou voľbou.

Prístup založený na riziku je tiež lepšou stávkou na spustenie automatizovaných testov s vysokou prioritou a na testovanie najskôr.

#dva) Tím QA môže efektívnejšie prijať prístup RBT počas analýzy požiadaviek pri analýze požiadaviek a poskytovaní predbežných správ o pravdepodobných rizikách výrobkov a funkcií, aby mohol programový tím proaktívne prijímať príslušné opatrenia na ich zmiernenie.

# 3) Prístup RBT možno efektívne využiť pri navrhovaní testovacích prípadov a scenárov založených na vysokom riziku, aby bolo možné venovať viac pozornosti vysoko rizikovým vlastnostiam a funkciám.

# 4) Identifikácia oblastí s „vysokým rizikom“ umožňuje tímu QA zamerať úsilie v oblasti testovania na tieto oblasti, aby mohli „dôkladnejšie“ testovať pomocou „vysoko kvalifikovaných testerov“.

# 5) „Fail Fast“, ako všetci vieme, je koncept „agilných“ a „DevOps“, pre ktoré prístup RBT pomáha identifikovať „vysoko rizikové“ oblasti v softvéri, včas identifikovať chyby a umožniť im rýchle zlyhanie a zlyhanie najskôr a nechajte tím opraviť.

# 6) Konečným cieľom Agile / DevOps je „Zameranie na zákazníka“, a preto prístup RBT umožňuje QA zamerať sa na zákaznícku skúsenosť, nielen na hľadanie chýb.

Výhody prístupu založeného na testovaní na riziku

Už sme pochopili účel a použitie prístupu RBT pri analýze požiadaviek, navrhovaní a vykonávaní testovacích scenárov. Existuje niekoľko výhod RBT.

Môžeme konsolidovať a vymenovať výhody testovania na základe rizika ako:

• Pomáha efektívnejšie a optimalizovanejšie využívať testovacie zdroje.
• Pomáha pri uľahčovaní práce QA, testovania, navrhovania a vývoja testov a prípravy testov stanovením priorít.
• Pomáha pri lepšom riadení zdrojov zabezpečovania kvality alokovaním kľúčových zdrojov do oblastí s veľkým zameraním.
• Pomáha pri efektívnom využívaní zdrojov a odvádza ich čas a energiu na lepšie veci v projekte.
• Pomáha tímu QA pri plánovaní testovacích snáh založených na hodnotení rizika a identifikácii nestálych a vysoko rizikových oblastí.
• Pomáha tímu optimalizovať testy, ktoré sa majú vykonať, v závislosti od dôležitosti, a teda po dohode so zainteresovanými stranami vyraďujú testy nízkej hodnoty z rozsahu.
• Celkovo pomáha pri znižovaní nákladov prostredníctvom optimalizovaných a obmedzených testovacích aktivít.
• Prístup RBT umožňuje tímu QA najskôr otestovať vysoko rizikové oblasti a umožňuje produktu „Rýchle zlyhanie“ a rýchlu opravu.
• Prístup RBT pomáha pri objasňovaní „ Pokrytie testu “ a „Rozsah pôsobnosti“ pre celú skupinu zainteresovaných strán.
• Tím sa môže viac sústrediť na oblasti s vysokým rizikom a menej sa sústrediť na oblasť s nízkym rizikom.
• RBT umožňuje tímu rozhodnúť sa s dostatočným predstihom o implementácii najefektívnejšieho spôsobu zmierňovania rizík produktu.
• RBT pomáha predchádzať následkom neprimeraného vykonávania zmierňovacích opatrení.
• Testovanie na základe rizika umožňuje tímu prijať príslušné opatrenia na zmiernenie alebo plánovanie nepredvídaných udalostí alebo umiestniť akékoľvek riešenie s cieľom prekonať zlyhanie alebo znížiť jeho vplyv, ak k riziku dôjde naživo.
• RBT pomáha minimalizovať zvyškové riziko pri uvoľňovaní.
• Pomáha dosiahnuť „vylepšenú kvalitu“ prostredníctvom menej nákladných chýb vo výrobe.
• V konečnom dôsledku pomáha pri vylepšených zákazníckych skúsenostiach a spokojných zákazníkoch.

Ďalej sa naučíme, ako riadiť riziká vo fázach plánovania testov a vykonávania testov životného cyklu testovania softvéru.

Riadenie rizika počas plánovania testov

Ako riadiť riziká počas fázy plánovania testu:

Život je plný rizík, rovnako ako softvérový projekt. Kedykoľvek sa môže pokaziť čokoľvek. Sme stále v strehu, aby sme všetko napravili - ale čo tak zaistiť, aby sa nič nepokazilo a že keď to bude vedieť, presne vieme, čo máme robiť? Vstúpte do riadenia rizík - toto je časť projektu testovania softvéru, ktorá nás pripravuje na prevenciu, porozumenie, nájdenie a prekonanie rizík.

Riziko je jednoducho problém, ktorý pravdepodobne nastane, a keď sa vyskytne, spôsobí stratu.

Stratou môže byť čokoľvek - peniaze, čas, úsilie alebo kompromis v kvalite. Strata nie je nikdy dobrá. Bez ohľadu na to, ako veľmi točíme, nie je to pozitívne - ani nikdy nebude. Preto Riadenie rizík je neoddeliteľnou súčasťou softvérových projektov na zaistenie toho, aby sme zvládli riziká a zabránili / znížili straty.

Testovanie založené na riziku : Pretože sme komunitou QA, zostaňme špecifickí iba pre riziká a procesy s nimi spojené v našom svete QA. Riziká sa posudzujú a riadia zhruba v 2 fázach Životný cyklus softvéru . STLC možno rozdeliť do troch fáz - plánovanie testov, navrhovanie testov a vykonávanie testov.

Proces riadenia rizík sa vyskytuje dvakrát počas:

1. Plánovanie testov
2. Návrh testovacieho prípadu (koniec) alebo niekedy vo fáze vykonania testu

V prípade 1 je to povinné, ale v prípade 2 ide skôr o situáciu „nevyhnutnosti“.

Dvojdielne série článkov:

Aj keď je základný proces rovnaký, typy rizík obidve tieto oblasti sú úplne odlišné. Aby sme im dosiahli spravodlivosť individuálne, budeme ich ako dvojdielnu sériu riešiť inak.

Táto časť bude o „Riadenie rizika počas plánovania testov“.

Proces riadenia rizík

Všeobecný proces riadenia rizík zahŕňa 3 dôležité etapy:

1. Identifikácia rizika
2. Analýza dopadov rizika
3. Zmiernenie rizika

Príklady testovania rizík a zmiernenia:

# 1) Identifikácia rizika

Ako sa hovorí, prvým krokom k vyriešeniu problému je jeho identifikácia. Táto fáza spočíva v zostavení zoznamu všetkého, čo by mohlo potenciálne prísť a narušiť normálny tok udalostí.

Hlavným výsledkom tohto kroku je zoznam rizík.

Tento krok testovania na základe rizika obvykle vedie vedúci / manažér / zástupca QA. Samotný vedúci však nebude schopný prísť s celým zoznamom - vstup celého tímu QA má obrovský vplyv. Môžeme povedať, že ide o kolektívnu činnosť vedenú vedením QA.

Aj riziká, ktoré sú identifikované vo fáze plánovania testu, sú viac „manažérske“ v orientácii - čo znamená, že sa zameriame na všetko, čo by mohlo mať vplyv na harmonogram, úsilie, rozpočet, zmeny infraštruktúry atď. Projektu QA. nie AUT, ale to, ako bude prebiehať fáza QA.

Riziká počas plánovania testov: Príklady testovania na základe rizika

Nasleduje ukážka zoznamu rizík, ktoré môžu byť uvedené vo fáze plánovania testu. Upozorňujeme, že tu nie je zameraný AUT a jeho funkčnosť.

1. Časový plán testovania je prísny. Ak sa začiatok testovania oneskorí z dôvodu projektových úloh, test nie je možné predĺžiť nad plánovaný dátum začiatku UAT.
2. Nedostatok zdrojov, zdroje nastupujú príliš neskoro (proces trvá asi 15 dní.)
3. Poruchy sa nachádzajú v neskorom štádiu cyklu alebo v neskorom cykle; chyby objavené neskoro sú s najväčšou pravdepodobnosťou spôsobené nejasnými špecifikáciami a ich riešenie je časovo náročné.
4. Rozsah nie je definovaný úplne definovaný
5. Prírodné katastrofy
6. Nedostupnosť nezávislých Testovacie prostredie a prístupnosť
7. Oneskorené testovanie kvôli novým problémom

V tomto okamihu sa môžete rozhodnúť, či budete tak dôkladní, ako by ste chceli, v závislosti od množstva dostupného času.

Keď sú uvedené všetky riziká, postupujeme k posúdeniu rizika / analýze dopadu rizika.

# 2) Posúdenie rizika / Analýza rizikových vplyvov

Je vaša analýza rizík niečo také? :)

Analýza rizík pri testovaní softvéru : Všetky riziká sú v tomto kroku vyčíslené a uprednostnené. Pravdepodobnosť každého rizika (pravdepodobnosť jeho vzniku) a dopad (výška straty, ktorú by spôsobilo, keď sa toto riziko vyskytne), sa stanovujú systematicky.

Vysoký - stredne nízky , sa hodnotám priraďuje pravdepodobnosť a dopad každého rizika. Najprv sa postará o riziká s „vysokou“ pravdepodobnosťou a „veľkým“ dopadom a potom nasleduje poradie.

Tabuľka analýzy rizík:

Po vykonaní týchto krokov by tabuľka analýzy rizík pre vyššie uvedené riziká vyzerala asi takto (všetky hodnoty sú hypotetické a slúžia iba na pochopenie):

# 3) Zmiernenie rizika

Posledným krokom v tomto procese testovania na základe rizika (RBT) je nájdenie riešení, ako naplánovať, ako zvládnuť každú z týchto situácií. Tieto plány sa môžu líšiť od spoločnosti k spoločnosti, projektu k projektu a dokonca aj od človeka k človeku.

Techniky zmierňovania rizika:

Tu je príklad toho, čo sa tabuľka rizík transformuje po dokončení tejto fázy:

Niekoľko poznámok:

1. Čím skôr začne riadenie rizík vo fáze plánovania projektu QA, tým lepšie.
2. Zo všetkých 3 krokov Identifikácia rizika je najdôležitejšia . Ak niečo nie je uvedené a neuvažuje sa s ním o ďalších krokoch, riziko bude nedotknuté.
3. Pokúste sa nájsť ideálny časový rámec pre túto činnosť. Pamätajte, že príliš veľa plánovania ponecháva príliš málo času na to, aby ste to zvládli.
4. Taktiež po procese riadenia rizík, ak dôjde k novej situácii, je možné plán riadenia rizík zmeniť alebo aktualizovať tak, aby odrážal najaktuálnejší stav.
5. Historické dáta môže byť veľmi užitočné pre úspech tohto procesu.

Záver

Týmto sa dostávame ku koncu riadenia rizík vo fáze plánovania testu. Aj keď sú základné kroky a princípy podobné, proces riadenia rizika je koncentrovanejší smerom k AUT, keď k nemu dôjde vo fáze navrhovania / vykonávania testu.

V našej ďalšej časti sa budeme zaoberať - Riadenie rizika vo fáze vykonávania testu.

Riadenie rizika vo fáze vykonania testu (s príkladom)

Na našej ceste k pochopeniu procesu riadenia rizík sme hovorili o tom, ako to prebieha výlučne v EÚ Fáza plánovania testovania testovania na základe rizika . Pochopili sme aj všeobecný proces, ktorý zahŕňa - identifikáciu rizika, hodnotenie rizika a plán zmierňovania rizika.

Ako riadiť riziko vo fáze navrhovania testu alebo vykonania testu:

Existuje ešte jedna forma Riadenie rizík (tiež niekedy označované ako, Testovanie založené na riziku ), ku ktorému dôjde počas fázy navrhovania testu alebo vykonania testu v závislosti od situácie. Teraz, o akej situácii hovoríme? Skúsme to najskôr pochopiť.

Všetci vieme, že naše testovacie práce sú reaktívne. Žiadne požiadavky (alebo rozsah definovaný), nemôžeme vykonať analýzu uskutočniteľnosti a napísať testovacie scenáre alebo naplánovať testovacie činnosti.

Podobne, keď kód nie je pripravený, nemáme čo testovať, bez ohľadu na to, koľko prípravných prác sme mohli byť pripravení, pokiaľ ide o testovacie prípady, testovacie údaje atď. Testovanie je jediný krok, ktorý zostáva do spustenia produktu žiť.

Riadenie rizík - so zameraním na AUT

Pochopme to lepšie na príklade:

Ak sa testovanie malo začať v uvedený deň, 1. januára^sva musel pokračovať až do 14. januára^th- keď je testovanie hotové, dátum spustenia produktu je zvyčajne okamžite opravený. Povedzme - 15. januára^thpre jednoduchosť. Teraz by v perfektnom svete išlo všetko presne podľa plánu. Ale všetci vieme realitu.

V takom prípade predpokladajme, že z nejakého dôvodu sa testovanie začalo až 7. januára^th, čo znamená, že sme stratili polovicu času na testovanie. Na dôkladné otestovanie produktu však potrebujeme 14 dní. Dátum spustenia by sme mohli posunúť ďalej o 7 dní - však; zvyčajne to nie je možné. Pretože sa sľubuje, že produkt sa dostane na trh v určitý deň, prípadné oneskorenia nie sú pre podnik dobré.

Takže zvyčajne musíme testovacie tímy absorbovať oneskorenia, nejako to kompenzovať, pracovať s dostupným časom a zabezpečiť, aby bol produkt dobre otestovaný. Ťažká práca, nie?

Tu sa opäť využíva proces riadenia rizík.

• Teraz, ak oneskorenia sa predpokladajú vopred ešte predtým, ako začne testovanie, proces sa uskutoční vo fáze navrhovania testu.
• Ak oneskorenia sa stávajú počas a Fáza vykonania testu ktorý sa začal normálne - proces sa sleduje počas fázy vykonávania testu.
• Kroky a metóda sú rovnaké bez ohľadu na to, v ktorej fáze sa to stane.

Aký je postup?

Prebieha riadenie rizika s cieľom určiť, ktoré oblasti AUT (testovaná aplikácia) je potrebné maximálne zamerať. Obvykle sú to funkčné oblasti (moduly alebo komponenty), ktoré sú rozhodujúce pre úspech konečného produktu a sú najviac náchylné na zlyhanie.

Prečítajte si tiež=> Analýza zlyhania a účinkov (FMEA) je technika riadenia rizík

Kto to vykonáva?

Pokiaľ ide o AUT, vedomosti o ňom nie sú len s QA, ale so všetkými ostatnými tímami - vývojovými, BA, klientskými, projektovými tímami atď. Ide teda o kolektívne úsilie vedené testovacím tímom.

Ako prebieha testovanie základov rizík?

Krok 1) Identifikácia rizika

Identifikujte všetky funkčné oblasti AUT. Bude to obsahovať iba vytvorenie zoznamu.

Krok 2) Posúdenie rizík

Všetky riziká sú v tomto kroku vyčíslené a uprednostnené. Vyčíslenie je jednoduché, priradenie čísla ku každému riziku v zozname, ktoré poskytne údaj o priorite, s ktorou je potrebné ho riešiť.

O pravdepodobnosti každého rizika (pravdepodobnosti jeho vzniku) a dopade (výške straty, ktorú by spôsobilo, keď sa toto riziko vyskytne) sa rozhoduje.

Typickou metódou je prideľovanie hodnotení. Napríklad, Pravdepodobnosť môže nadobúdať hodnoty od 1 do 5. 1 je pravdepodobnosť, že nízka bude (pravdepodobne sa vôbec nestane) a 5 (bude sa s najväčšou pravdepodobnosťou vyskytovať).

Podobne možno Impactu priradiť hodnotenie 1-5. 1 je malý dopad (aj keď sa toto riziko skutočne naplní, strata je minimálna) a 5 vysoký dopad (obrovské straty, keď k nim dôjde).

najlepší bezplatný softvér na optimalizáciu výkonu počítača

Krok č)

Vytvorte formát tabuľky a rozošlite ho všetkým zástupcom tímu - vývojárom, BA, klientom, PM, QA a všetkým ostatným relevantným.

Krok č)

Poraďte každému tímu, aby vyplnil hodnoty na základe ich pravdepodobnosti a dopadu.

Pretože hodnoty pravdepodobnosti a vplyvu sú číselné, bude výpočet hodnoty „rizikového faktora“ ľahký.

Rizikový faktor = pravdepodobnosť X vplyv. Čím vyšší je rizikový faktor, tým závažnejší je problém.

Príklad:

Upozorňujeme, že v tomto okamihu je to iba výsledok hodnotenia jedného tímu. Pre projekt, do ktorého je zapojených 5 rôznych tímov, by tím QA skončil s 5 rôznymi stolmi.

Krok č)

Zoberte priemer hodnôt rizikových faktorov. Napríklad, ak existuje 5 tímov, pre každý modul pridajte všetky hodnoty rizikových faktorov a vydelte ich 5. Toto sú konečné hodnoty, s ktorými sa budeme zaoberať. Povedzme, toto sú priemerné rizikové faktory:

Čím viac je rizikový faktor, tým viac musí byť daný modul testovaný.

Modul 5 a 2 sú teda najdôležitejšie pre úspech podnikania. Podeľte sa o výsledky so všetkými tímami.

Krok č. 6)

Plán na zníženie rizika : Toto je krok, ktorý sa mení z projektu na projekt. Zistili sme, že na moduly 5 a 2 sa treba najviac sústrediť.

Príkladyplánu by mohlo byť:

1. Moduly 5 a 2 budú dôkladne testované, aby sa zabezpečilo, že budú otestované všetky testovacie prípady, ktoré sa ich týkajú. Ostatné moduly budú testované na prieskumnej báze.
2. Najskôr sa otestujú moduly 5 a 2 a potom sa podľa času, ktorý bude k dispozícii, postarajú o ostatné.

Po vytvorení plánu sa všetky tímy dohodnú a podľa neho otestujú produkt s prihliadnutím na rizikový faktor.

To je všetko!

Niekoľko dôležitých vecí, ktoré si treba uvedomiť:

• Pretože toto je kolektívna činnosť, ktorá vyžaduje do úvahy každý názor ; šanca, že bude presný a efektívny, je vyššia.
• Toto je nie formálna metóda a nemusí byť súčasťou každého projektu zabezpečovania kvality.
• Niekedy, aj keď sa tím rozhodne, že nebude kresliť tabuľky a prideľovať hodnoty - a jednoduché brainstormingové sedenie s každým prítomným môže dať tímu QA dobrý smer, ako postupovať.
• The vstup vývojového tímu je veľmi dôležitá, pretože práve oni vytvárajú produkt, takže budú vedieť, čo môže fungovať a čo si bude možno vyžadovať ďalšiu kontrolu. Určite to dávajte pozor.
• Aj keď v procese prebieha viac krokov, ich vykonanie netrvá značné množstvo času . Najmä ak môžu všetky tímy sedieť spolu a pracovať súčasne.
• Pamätajte na tento proces a jeho výsledok je iba alternatíva . Získanie čo najviac času podľa plánu na testovanie je najlepší spôsob vykonávania aktivity QA.

Záver

Prístup testovania na základe rizika jasne naznačuje, že tester sa nezameriava len na neustále skúmanie chýb, bez ohľadu na ich závažnosť a prioritu. Teraz sa veci zmenili a testéri musia pracovať inteligentne a musia pochopiť jasnú „potrebu zákazníka a želania používateľa“.

Musí si produkt dôkladne preštudovať a pochopiť, ktorá je vo výrobe najbežnejšie používanou funkciou, ktorá je najdôležitejšou cestou pre generovanie výnosov a ako chrániť a chrániť zákazníkov pred výrobnými problémami a obchodnými hrozbami.

Prístup RBT preto jasne vychováva testerov, že iba testovanie všetkého alebo rozsiahle testovanie neznamená, že testovanie je úplné alebo že výrobok nemá chyby. Účinné testovanie v stanovenom čase a zabezpečenie toho, aby sa eliminovali kritické a hlavné obchodné dopady, čo je pre testera dosť dôležité.

Testovanie založené na riziku je teda najefektívnejším nástrojom tímu QA na usmernenie zainteresovaných strán na základe rizík projektu. Prístup RBT pomáha tímu QA pri nepretržitej identifikácii rizika a jeho riešení, ktoré by mohli ohroziť dosiahnutie celkových cieľov a zámerov projektu, a pomáha pri dosahovaní konečného cieľa skupiny QA.

P.S. Slová QA a Testovanie boli v dokumente vzájomne zameniteľné.

O autorovi: Tento článok je napísaný viacerými členmi tímu STH - Gayathri Subrahmanyam a Swati S.

Gayathri je softvérový testovací SME s viac ako 2 desaťročiami skúseností v testovaní softvéru a vo viacerých angažovanostiach vo veľkej miere prijala prístup „testovania na základe rizík“ ako súčasť testovacej industrializácie a uvedomila si výhody optimalizácie testovacích zdrojov a testovania kvality.

Bolo pre vás testovanie na základe rizika náročné? Máte nejaké zaujímavé fakty, ktoré chcete pridať do nášho tutoriálu? Neváhajte a vyjadrite svoje myšlienky v sekcii komentárov nižšie !!

=> Celý seminár s kompletným plánom testovacieho plánu nájdete tu

Odporúčané čítanie

• Proces nepretržitej integrácie: Ako zlepšiť kvalitu softvéru a znížiť riziko
• Analýza poruchových režimov a efektov (FMEA) - Ako analyzovať riziká pre lepšiu kvalitu softvéru a spokojných zákazníkov!
• Sprievodca testovaním na základe rizika: Riadenie rizika pri testovaní softvéru
• Top 10 nástrojov a techník na hodnotenie a riadenie rizík
• Typy rizík v softvérových projektoch
• Niektoré zaujímavé otázky týkajúce sa testovania softvéru
• Ako svoju kariéru si zvolíte testovanie softvéru
• Spätná väzba a recenzie na kurz testovania softvéru