The Ultimate Guide to Risk Based Testing: Risk Management in Software Testing

ultimate guide risk based testing

Nejlepší průvodce testováním založeným na rizicích, řízením rizik a jeho přístupem s příklady:

Co je testování založené na riziku?

Testováním založeným na riziku je provést testování nebo navrhnout a provést scénáře tak, aby hlavní obchodní rizika, která budou mít nepříznivý dopad na podnikání identifikovaný zákazníkem, byla v jejich produktu nebo funkci objevena na začátku životního cyklu a jsou zmírněn zavedením zmírňujících opatření.

=> Klepnutím sem zobrazíte kompletní výukový program pro testovací plán

Negativní dopad může zahrnovat dopad na náklady, nespokojený zákazník, špatné uživatelské zkušenosti a dokonce do té míry, že o zákazníky přijde.

Jinými slovy, přístupem RBT je zajistit, aby se testování provádělo takovým způsobem, že i když jde o uživatele najde chybu ve výrobě mu to nebrání v používání softwaru nebo to nemá vážný dopad na podnikání.

RBT testuje na základě rizik produktu. RBT je zjistit s dostatečným předstihem, jaké je riziko selhání určité funkce nebo funkce ve výrobě a její dopad na podnikání, pokud jde o náklady a další škody, použitím techniky stanovení priorit pro testovací případy.

Proto testování založené na riziku používá princip stanovení priorit testů funkcí, modulů a funkcí produktu nebo softwaru. Stanovení priorit je založeno na riziku pravděpodobnosti selhání dané funkce nebo funkce ve výrobě a jejich dopadu na zákazníky.

Co se naučíte:

• Testování na základě rizik a jeho význam pro agilní a devOps
  • Přístup založený na posouzení rizik
    • Kdy použijeme přístup RBT?
    • Příklad přístupu RBT
  • Způsoby provedení analýzy rizik
  • Postup analýzy rizik
  • Metodika analýzy rizik
    • Krok 1) Použití mřížky 3X3
    • Krok 2) Pravděpodobnost a dopad selhání
    • Krok č. 3) Testování prioritní mřížky
    • Krok č. 4) Podrobnosti o testování
  • Jak je RBT relevantní pro agilní a DevOps?
  • Výhody přístupu založeného na testování rizik
• Řízení rizik během plánování testů
  • Proces řízení rizik
    • # 1) Identifikace rizika
    • # 2) Posouzení rizik / Analýza rizikových dopadů
    • # 3) Snižování rizik
  • Závěr
• Řízení rizik ve fázi provádění testu (s příkladem)
  • Řízení rizik - se zaměřením na AUT
  • Jak probíhá testování základen rizik?
  • Závěr
  • Doporučené čtení

Testování na základě rizik a jeho význam pro agilní a devOps

Tři sta hodin strávených vývojem softwaru může být zbytečných za pouhých 30 sekund s jedinou závadou zjištěnou ve výrobě.

To zase může zničit účel celého produktu bez jiné možnosti, než jen stáhnout jej z trhu. A to je význam a potřeba „testování kvality“.

Díky rychlému růstu technologie je software hostován v cloudu podporujícím více operačních systémů, více platforem, složité IT infrastruktury atd., Koncoví uživatelé jsou stále více a více rozrušení ohledně funkcí, možností a nikdy neohrožují spokojenost zákazníků .

V dnešní době se „kvalita“ stává klíčovým faktorem při poskytování softwaru, kde dochází k neustálému zlepšování, které zvyšuje kvalitu, aby zákazníci byli spokojení.

Často si všimneme, že je téměř běžným problémem, že téměř všichni testeři jsou pod obrovským tlakem, že jejich testovací okno je stlačeno a obvykle je sestavení předáno k testování na poslední chvíli. Není pro ně dostatek času a prostředků na provedení všech testů, které navrhli, a pokrytí automatizací není vždy stoprocentní a má své vlastní výzvy.

Nelze zmeškat časovou osu doručení a zároveň nelze ohrozit kvalitu. Ať už plán B, přidání dalších testovacích zdrojů vytažením z ostatních týmů, nepracuje, plán C, přestaňte dělat všechny ostatní aktivity a přesměrujte na to úsilí, ve skutečnosti nepomáhá. Nicméně mnoho přidání testovacích prostředků nakonec nefunguje.

Neexistuje jiná možnost, než jen spustit omezené a důležité testy v rámci dostupného času a zdrojů.

Jak tedy rozhodneme, který test je v této fázi důležitý? Cokoli tester považuje za důležité, nemusí být pro zákazníky opravdu důležité. Z čí perspektivy se rozhoduje o důležitosti prvku nebo funkčnosti? Kdo rozhodne, které jsou důležité testy? A stále vyvstává spousta dalších otázek.

Abychom mohli odpovědět na všechny tyto otázky a efektivně zvládnout výše uvedenou situaci, zavolal testovací přístup „Testování na základě rizik“ , krátce volal 'RBT' , kde tým jasně naplánoval a identifikoval testovací scénáře na základě kritérií „rizika projektu“.

Ačkoli má tým QA jasný obrázek o důležitých testech, RBT je osvědčenou metodou identifikace klíčových a důležitých testů z pohledu zákazníka a podnikání prostřednictvím 'Analýza rizik' postup .

Takže nyní, na rozdíl od tradičního způsobu jednoduché identifikace závad softwaru, se přístup a cíl QA časem změnily v důsledku změny technologie, zvýšení konkurence na trhu o vydání kvalitního softwaru, zavedení „Automatizovat vše“ a v úplném zavedení praxe Agile a DevOps dodávat software po dobu několika hodin.

Současný trend „principu testování“ tedy není jen „identifikace vad“, ale také,

# 1) Zaměřte se na oblast produktu, kde je vysoký dopad na podnikání v důsledku selhání nebo vysoké pravděpodobnosti selhání ve výrobě.

#dva) Se zaměřením na identifikace vad brzy a umožnit týmu to opravit co nejdříve, a tedy umožnit software / produkt nebo funkci „Rychlé selhání“.

# 3) Nejdůležitějším aspektem služby týmu QA je zaměřit se na zákazníka při zvyšování hodnoty pro zákazníka zvýšením zaměření na „Koncová zákaznická zkušenost“.

Přístup založený na posouzení rizik

Vždy je to jako připravovat se na zkoušku, že nelze říci, že testování je dostačující a že software již neobsahuje žádné vady, i když navrhují a provádějí dostatečný počet testů.

Existuje bod, ve kterém nebude stabilita softwaru dvojnásobně zajištěna zvýšením počtu samotných testovacích případů. V tuto chvíli nejde jen o to zaměřit se na počet testů, ale také na to, co zákazník od vydání vlastně očekává.

Proto je nezbytné najít rovnováhu v optimalizaci testování, abyste získali maximální užitek při přiměřeném úsilí testování. A to je důležitější, když jsou časové osy testování velmi omezené a není k dispozici dostatek zdrojů k provedení dostatečného testování.

V tomto případě tedy přístup RBT hraje klíčovou roli při optimalizaci úsilí QA a maximalizaci výhody testování s minimálním obchodním rizikem.

Pokud se tedy zaměříme na výše uvedený aspekt, pak se práci QA hodně ulevilo. Nemusí pálit víkendy v kanceláři, neustále testovat software a dělat si starosti s každou chybou S4 (závažnost 4) a P4 (priorita 4), které z testování vyplynou.

4 se považuje za nejnižší prioritu a závažnost vad při testování. Mohou lépe investovat svůj čas do dalších užitečných aspektů projektu.

Shrnutí klíčových faktorů přístupu „testování založeného na riziku“:

• Umožnit testování „toho, co zákazníci chtějí“ z obchodního hlediska.
• Splnit časový plán s očekávanou kvalitou.
• Optimalizovat úsilí QA.

Kdy použijeme přístup RBT?

Používá se v následujících scénářích:

• Přístup RBT lze použít, kdykoli existuje omezení nebo omezení času, nákladů a zdrojů projektu a kdykoli je potřeba optimalizovat zdroje.
• Přístup RBT se používá, když je program složitější a přizpůsobuje novou technologii, a proto zahrnuje spoustu výzev.
• Jedná-li se o projekt výzkumu a vývoje, jedná se o program prvního druhu a v projektu je řada neznámých a rizik.

Příklad přístupu RBT

V IT průmyslu se k překonání rizik, kterým čelí výroba a její dopady, používá několik přístupů k analýze založené na riziku.

Níže je uveden jeden takový přístup:

Tento přístup RBT zahrnuje identifikaci „životně důležitých funkcí nebo klíčových funkcí“ produktu a posouzení rizik, kterým je každá z těchto funkcí vystavena při výrobě, a zavedení vhodných opatření ke zmírnění rizika.

Přístup RBT proto zahrnuje testování funkcí, které mají pravděpodobnost selhání a největší dopad na podnikání. Typy poruch mohou být provozní nebo obchodní, technické, externí atd.

Způsoby provedení analýzy rizik

Neexistuje žádný standardní proces nebo šablona definovaná jako taková pro provádění analýzy rizik při testování softwaru pro každou vlastnost produktu. Různé organizace používají vlastní přístup k metodám analýzy rizik.

Analýzu rizik lze provést na různých položkách projektu za účelem identifikace rizik a implementace přístupu RBT pro analýzu. Mezi tyto položky patří,

• Funkce
• Funkce
• Uživatelské příběhy
• Požadavky
• Případy užití
• Testovací případy

V tomto případě se zaměřme pouze na testovací případy, abychom porozuměli implementaci přístupu založeného na testování rizik.

Postup analýzy rizik

Analýza rizik zahrnuje zapojení příslušných zúčastněných stran programu jak z „ Technický tým a obchodní tým “ , což zahrnuje vlastníka produktu, produktové manažery, obchodní analytiky, architekty, testery a zástupce zákazníků.

Byly by uspořádány brainstormingové schůzky zahrnující tyto zúčastněné strany, aby se provedla diskuse s cílem určit důležitost každé vlastnosti produktu a stanovit jejich prioritu na základě rizika selhání a jeho dopadu na koncové uživatele ve výrobě.

Vstupem do brainstormingové relace se stanou různé „projektové dokumenty“, například dokument s požadavky, dokumenty s technickými specifikacemi, dokumenty o architektuře a designu, dokument obchodního procesu, dokument o případu použití atd.

Znalost zúčastněných stran o produktu a stávajícím produktu na trhu bude rovněž vstupním faktorem pro diskusi.

Několik dalších zdrojů vstupů může také zahrnovat,

• Shromažďovat vstupy o nejpoužívanějších funkcích.
• Vstupy od konzultace s odborníkem na doménu.
• Data z předchozí verze produktu nebo podobného produktu na trhu.

Během brainstorming relace, jsou identifikována rizika týkající se každé z těchto funkcí. Druhy rizik mohou být provozní, technické nebo obchodní. Testy a scénáře, které se k nim vztahují, jsou váženy a hodnoty rizik jsou hodnoceny na základě pravděpodobnosti výskytu rizika a dopadu rizika.

„Pravděpodobnost výskytu rizika“ může být způsobena:

• Špatné pochopení funkce vývojovým týmem produktu.
• Nesprávná architektura a design.
• Nedostatečný čas na návrh.
• Neschopnost týmu.
• Nedostatečné zdroje - lidé, nástroje a technologie.

„Dopad rizika“ je účinek selhání na uživatele a podnik, pokud k němu dojde. Dopad by mohl být,

• Dopad nákladů, což vede ke ztrátě.
• Dopad na podnikání vedoucí ke ztrátě podnikání nebo ke ztrátě podílu na trhu, soudní řízení, ztráta licence.
• Dopad na kvalitu, což má za následek nestandardní nebo nekompetentní vydání produktu.
• Špatný uživatelský dojem, což vede k nespokojenosti a ztrátě zákazníka.

Oblast zaměřenou na posouzení rizika prvku nebo produktu může být,

• Oblast obchodní kritičnosti funkce.
• Nejpoužívanější funkce a důležité funkce.
• Poškozené oblasti
• Funkčnost s dopadem na bezpečnost a zabezpečení.
• Oblast komplexního designu a architektury.
• Změny provedené z předchozích verzí.

Metodika analýzy rizik

Pojďme nyní podrobně porozumět „metodice testování na základě rizik“.

Přístup založený na posouzení rizik používá jako kritérium RIZIKO ve všech testovacích fázích testovacího cyklu, tj. plánování testů , design testu, implementace testu, provedení testu a hlášení testů. V ideálním případě lze navrhnout řadu možných kombinací testovacích scénářů.

Přístup RBT proto zahrnuje hodnocení testů na základě závažnosti rizik za účelem zjištění nejvíce defektní nebo nejrizikovější oblasti selhání, která má velký dopad na podnikání.

Hlavním cílem analýzy rizik je rozlišit mezi 'Vysoká cena' položky jako vlastnosti produktu, funkce, požadavky, uživatelské příběhy a testovací případy a Nízká hodnota' ty, a proto se později více zaměřit na testovací případy „vysoké hodnoty“, tím méně se zaměřit na testovací případy „nízké hodnoty“. Toto je počáteční krok analýzy rizik před zahájením testování založeného na riziku.

Hlavní úkol kategorizace nebo seskupení testovacích případů do hodnot s vysokou a nízkou hodnotou a přiřazení hodnoty priority každému z těchto testovacích případů zahrnuje následující kroky:

Krok 1) Použití mřížky 3X3

Analýza rizik se provádí pomocí mřížky 3X3, kde každá funkčnost, nefunkčnost a související testovací případy jsou hodnoceny týmem zúčastněných stran pro jejíPravděpodobnostselhání “a„ Dopad selhání “.

K pravděpodobnosti selhání každé funkce ve výrobě obecně přistupuje skupina „technických odborníků“ a jsou kategorizovány jako „pravděpodobné selhání, docela pravděpodobné a nepravděpodobné“ podél svislé osy mřížky.

nejlepší programy pro sledování teploty procesoru

Obdobně „Dopad selhání“ těchto vlastností a funkcí na produkci zažívá koncový zákazník, pokud není testován, je hodnocen skupinou '' Business Specialists “a jsou rozděleny do kategorií„ Menší, viditelné a přerušení “podél vodorovné osy mřížky.

Krok 2) Pravděpodobnost a dopad selhání

Všechny testovací případy jsou umístěny v kvadrantech mřížky 3 X 3 na základě identifikovaných hodnot pravděpodobnosti selhání a dopadu selhání, které jsou na následujícím obrázku zobrazeny jako tečky.

Je zřejmé, že vysoká pravděpodobnost selhání a vysoký dopad selhání (přerušení) jsou seskupeny v pravém horním rohu mřížky, což je velmi důležité, a proto je zjištěno, že testy „vysoké hodnoty“ a „nízké hodnoty“ jsou seskupeny do levý dolní roh, který má pro zákazníka minimální nebo žádný význam, kde lze těmto funkcím nebo testovacím případům věnovat menší pozornost.

Krok č. 3) Testování prioritní mřížky

Na základě výše uvedeného umístění testovacích případů v mřížce jsou testy upřednostněny a označeny prioritami 1,2,3,4 a 5 a jsou označeny proti každému z nich. Nejdůležitější testy jsou umístěny v 1^Svatýmřížka, které jsou přiřazeny s prioritou 1 a podobně méně důležité jsou hodnoceny jako 2, 3, 4 a 5.

Nakonec jsou všechny testovací případy seřazeny podle jejich prioritních čísel a jsou vyzvednuty k provedení v pořadí podle priority. Ty s vysokou prioritou se nejprve vyzvednou k provedení a ty s nízkou prioritou se provedou později nebo se zruší rozsah.

Krok č. 4) Podrobnosti o testování

Dalším krokem je rozhodnutí o úrovni podrobností testování pro definovaný rozsah testování. O hloubce rozsahu testování lze rozhodnout na základě výše uvedeného hodnocení podle níže uvedené mřížky.

Testy s vysokou prioritou s hodnocením 1 jsou ‚důkladněji 'testovány a podle toho jsou nasazeni odborníci, kteří testují tyto vysoce kritické funkce a související testovací případy. Podobně lze testovat případy s prioritou 2, 3 a 4. Může být přijato rozhodnutí o odstranění rozsahu funkcí z priority 5 a testů na základě dostupného času a zdrojů.

Přístup Level of Detail of Testing k upřednostnění funkcí a jeho testovacích případů tedy testerům nejen pomáhá identifikovat „testy vysoké hodnoty“, ale také je vede k tomu, aby se rozhodli na základě těchto prioritních hodnocení a „úrovně podrobností testování“. pomáhá jim provádět lepší testování a snižuje náklady na testování optimalizačním procesem.

Jak je RBT relevantní pro agilní a DevOps?

Nyní, po pochopení přístupu založeného na testování rizik založeném na stanovení priorit testů v závislosti na „riziku selhání“ konkrétní funkce a jejím „dopadu na zákazníka“ v přímém přenosu, by zjevně nastolila otázku relevance přístupu založeného na testování rizik v agilních a devOps postupech.

Klíčovými koncepty těchto postupů jsou „Automatizovat vše“, „Testovat vše“, „Testovat průběžně“, „Testovat opakovaně“.

Pokaždé, když dojde ke změně kódu nebo k vydání, všechny navržené testy proběhnou automatizovaně Kontinuální integrace (CI) / Kontinuální dodávka (CD) potrubí rychle a opakovaně, bez ohledu na jejich stanovení priorit.

Jaký je potom vztah mezi RBT a DevOps? Kam by zapadl RBT a stal se relevantním v Agile a DevOps ???

# 1) Ano, jak jsem již řekl dříve, není to tak, že každý průmysl a každý produkt má 100% automatizované pokrytí pro jejich provádění testů. Pokud tedy tým vůbec musí zvolit prioritu provádění testu z výběru manuálních testovacích případů a chtěl by ušetřit energii a úsilí testovacích zdrojů na jiné činnosti, pak je RBT tou nejlepší volbou.

Přístup založený na riziku je také lepší sázkou pro spouštění automatizovaných testů s vysokou prioritou a testování nejdříve.

#dva) Tým QA může efektivněji přijmout přístup RBT během analýzy požadavků při analýze požadavků a poskytnutí předběžné zprávy o pravděpodobných rizicích produktů a funkcí, aby programový tým mohl proaktivně přijmout vhodná opatření ke zmírnění tohoto problému.

# 3) Přístup RBT lze efektivně použít při navrhování testovacích případů a scénářů založených na vysokém riziku, aby bylo možné věnovat větší pozornost vysoce rizikovým funkcím a funkcím.

# 4) Identifikace oblastí s „vysokým rizikem“ umožňuje týmu QA zaměřit své úsilí v oblasti testování na tyto oblasti a „důkladněji“ otestovat pomocí „vysoce kvalifikovaných testerů“.

# 5) „Fail Fast“, jak všichni víme, je koncept „Agile“ a „DevOps“, u nichž přístup RBT pomáhá identifikovat „vysoce rizikové“ oblasti v softwaru, včas identifikovat vady a umožnit jim rychlé selhání a selhání nejprve a nechte tým opravit.

# 6) Konečným cílem Agile / DevOps je „Zaměření na zákazníka“, a proto přístup RBT umožňuje QA zaměřit se na zákaznickou zkušenost než jen na hledání vad.

Výhody přístupu založeného na testování rizik

Již jsme pochopili účel a použití přístupu RBT spočívajícího v analýze požadavků, navrhování a provádění testovacích scénářů. RBT má několik výhod.

Můžeme konsolidovat a uvést výhody Testování na základě rizik jako:

• Pomáhá efektivnějšímu a optimalizovanějšímu využívání testovacích zdrojů.
• Pomáhá při usnadňování práce QA, testování, navrhování a vývoje testů a přípravy na testy prioritizací.
• Pomáhá lépe spravovat zdroje QA přidělením klíčových zdrojů do oblastí s vysokým zaměřením.
• Pomáhá efektivně využívat zdroje a odvádí jejich čas a energii na lepší věci v projektu.
• Pomáhá týmu QA při plánování testovacího úsilí na základě posouzení rizik a identifikace nestálých a vysoce rizikových oblastí.
• Pomáhá týmu optimalizovat testy, které mají být provedeny, v závislosti na důležitosti, a tudíž po dohodě se zúčastněnými stranami vyřadit testy s nízkou hodnotou z rozsahu.
• Celkově to pomáhá při snižování nákladů prostřednictvím optimalizovaných a omezených testovacích aktivit.
• Přístup RBT umožňuje týmu QA nejprve otestovat vysoce rizikové oblasti a umožňuje produktu „Rychlé selhání“ a rychlou opravu.
• Přístup RBT pomáhá při objasnění „ Pokrytí testu “ a „Rozsah zkoušek“ pro celou skupinu zúčastněných stran.
• Tým se může více soustředit na vysoce rizikové oblasti a méně se zaměřovat na nízkorizikové oblasti.
• RBT umožňuje týmu rozhodnout se s dostatečným předstihem o implementaci nejúčinnějšího způsobu zmírnění rizik produktu.
• RBT pomáhá předcházet účinkům nevhodného provádění zmírnění.
• Testování na základě rizik umožňuje týmu přijmout vhodná opatření ke zmírnění nebo plánování pohotovostních situací nebo k umístění jakéhokoli řešení k překonání selhání nebo snížení jeho dopadu, pokud k riziku dojde v přímém přenosu.
• RBT pomáhá minimalizovat zbytkové riziko při uvolnění.
• Pomáhá dosáhnout „vylepšené kvality“ prostřednictvím méně nákladných závad ve výrobě.
• Nakonec pomáhá v „Vylepšené zákaznické zkušenosti“ a „Spokojený zákazník“.

Dále se naučíme, jak řídit rizika ve fázích plánování testování a provádění testu životního cyklu testování softwaru.

Řízení rizik během plánování testů

Jak řídit rizika během fáze plánování testů:

Život je plný rizik, stejně jako softwarový projekt. Kdykoli se může pokazit cokoli. Jsme vždy v patách, abychom věci napravili - ale co tak zajistit, aby se nic nepokazilo a že když to bude přesně vědět, co máme dělat? Vstupte do řízení rizik - jedná se o část projektu testování softwaru, který nás připravuje na prevenci, porozumění, hledání a překonání rizik.

Riziko je prostě problém, který pravděpodobně nastane, a pokud k němu dojde, způsobí ztrátu.

Ztráta může být cokoli - peníze, čas, úsilí nebo kompromis v kvalitě. Ztráta není nikdy dobrá. Bez ohledu na to, kolik rotace to uděláme, není to pozitivní - a nikdy nebude. Proto Řízení rizik je nedílnou součástí softwarových projektů, abychom se ujistili, že zvládáme rizika a předcházíme / omezujeme ztráty.

Testování na základě rizik : Jelikož jsme komunitou QA, zůstaňme specifičtí pouze pro rizika a procesy s nimi související v našem světě QA. Rizika jsou hodnocena a řízena zhruba ve 2 našich fázích Životní cyklus testování softwaru . STLC lze rozdělit do 3 fází - plánování testů, návrh testů a provádění testů.

Proces řízení rizik probíhá dvakrát, během:

1. Plánování testů
2. Návrh testovacího případu (konec) nebo někdy ve fázi provádění testu

V případě 1 je to povinné, ale u případu 2 jde spíše o situaci „potřeby“.

Dvoudílná série článků:

I když je základní proces stejný, typy rizik řešené v obou těchto oblastech jsou zcela odlišné. Abychom jim dosáhli spravedlnosti jednotlivě, budeme je řešit odlišně jako dvoudílnou sérii.

Tato část bude o „Řízení rizik během plánování testů“.

Proces řízení rizik

Obecný proces pro řízení rizik zahrnuje 3 důležité etapy:

1. Identifikace rizika
2. Analýza rizikových dopadů
3. Snižování rizik

Příklady testování rizik a zmírnění:

# 1) Identifikace rizika

Jak se říká, prvním krokem k vyřešení problému je jeho identifikace. Tato fáze zahrnuje vytvoření seznamu všeho, co by mohlo potenciálně přijít a narušit normální tok událostí.

Hlavním výstupem tohoto kroku je seznam rizik.

Tento krok testování na základě rizika obvykle vede vedoucí / manažer / zástupce QA. Samotný vedoucí však nebude schopen přijít s celým seznamem - vstup celého týmu QA má obrovský dopad. Můžeme říci, že se jedná o kolektivní aktivitu vedenou vedením QA.

Rizika, která jsou identifikována během fáze plánování Testu, jsou více „manažerská“ v orientaci - to znamená, že se podíváme na cokoli, co by mohlo ovlivnit harmonogram, úsilí, rozpočet, změny infrastruktury atd. Projektu QA ne AUT, ale způsob, jakým bude fáze QA pokračovat.

Rizika během plánování testů: Příklady testování na základě rizik

Následuje ukázkový seznam rizik, která mohou být uvedena ve fázi plánování testování. Upozorňujeme, že zde není zaměřen AUT a jeho funkčnost.

1. Časový plán testování je těsný. Pokud je začátek testování zpožděn z důvodu konstrukčních úkolů, nelze test prodloužit za plánované datum zahájení UAT.
2. Nedostatek prostředků, prostředky se připojují příliš pozdě (proces trvá přibližně 15 dní.)
3. Poruchy jsou zjištěny v pozdní fázi cyklu nebo v pozdním cyklu; vady objevené pozdě jsou pravděpodobně způsobeny nejasnými specifikacemi a jejich řešení je časově náročné.
4. Rozsah není definován zcela definován
5. Přírodní katastrofy
6. Nedostupnost nezávislých Testovací prostředí a přístupnost
7. Zpožděné testování kvůli novým problémům

V tomto okamžiku se můžete rozhodnout, jak důkladně chcete, v závislosti na dostupném čase.

Jakmile jsou uvedena všechna rizika, postupujeme k posouzení rizik / analýze dopadů rizik.

# 2) Posouzení rizik / Analýza rizikových dopadů

Je vaše analýza rizik něco takového? :)

Analýza rizik při testování softwaru : Všechna rizika jsou v tomto kroku kvantifikována a upřednostněna. Pravděpodobnost každého rizika (pravděpodobnost jeho vzniku) a dopad (výše ztráty, kterou by způsobila, když by se toto riziko stalo) jsou stanoveny systematicky.

Vysoká - střední-nízká , jsou hodnoty přiřazeny jak pravděpodobnosti, tak dopadu každého rizika. Nejprve je postaráno o rizika s „vysokou“ pravděpodobností a „vysokým“ dopadem a poté následuje pořadí.

Tabulka analýzy rizikových dopadů:

V návaznosti na tyto kroky by tabulka analýzy dopadů rizik pro výše uvedená rizika vypadala nějak takto (všechny hodnoty jsou hypotetické a pouze pro účely porozumění):

# 3) Snižování rizik

Posledním krokem v tomto procesu testování na základě rizik (RBT) je nalezení řešení pro plánování, jak zvládnout každou z těchto situací. Tyto plány se mohou lišit od společnosti k společnosti, od projektu k projektu a dokonce i od člověka k člověku.

Techniky snižování rizik:

Zde je příklad toho, co se tabulka rizik transformuje, když je tato fáze dokončena:

Několik poznámek:

1. Čím dříve začne řízení rizik ve fázi plánování projektu QA, tím lépe.
2. Ze všech 3 kroků Identifikace rizika je nejdůležitější . Pokud něco není uvedeno a zváženo pro další kroky, riziko zůstane nezpracované.
3. Pokuste se najít ideální časový rámec pro tuto aktivitu. Pamatujte, že příliš mnoho plánování ponechává příliš málo času na to, abyste to udělali.
4. Také po procesu řízení rizik, pokud dojde k nové situaci, lze plán řízení rizik změnit nebo aktualizovat tak, aby odrážely nejaktuálnější podmínky.
5. Historická data může být velmi užitečné pro úspěch tohoto procesu.

Závěr

Tím se dostáváme ke konci řízení rizik ve fázi plánování testů. I když jsou základní kroky a zásady podobné, proces řízení rizik je koncentrovanější směrem k AUT, když k němu dojde ve fázi návrhu / provedení testu.

V naší další části se budeme zabývat - Řízení rizik ve fázi provádění testu.

Řízení rizik ve fázi provádění testu (s příkladem)

Na naší cestě k porozumění procesu řízení rizik jsme hovořili o tom, jak to probíhá výhradně v EU Fáze plánování testování testování založeného na riziku . Pochopili jsme také obecný proces, který zahrnuje - identifikaci rizik, hodnocení rizik a plán zmírnění rizik.

Jak řídit riziko ve fázi návrhu testu nebo provedení testu:

Existuje ještě jedna forma Řízení rizik (někdy také označované jako, Testování na základě rizika ), ke kterému dochází během fáze návrhu testu nebo provedení testu v závislosti na situaci. O jaké situaci teď mluvíme? Pokusme se to nejprve pochopit.

Všichni víme, že naše testovací práce jsou reaktivní. Žádné požadavky (nebo rozsah definovaný), nemůžeme provést analýzu proveditelnosti a napsat scénáře testu nebo plán testovacích aktivit.

Podobně, když kód není připraven, nemáme co testovat, bez ohledu na to, kolik přípravných prací jsme mohli být připraveni, pokud jde o testovací případy, testovací data atd. Testování je jediným krokem, který zbývá, než produkt přejde žít.

Řízení rizik - se zaměřením na AUT

Pochopme to lépe na příkladu:

Pokud by testování mělo začít v uvedený den, 1. ledna^Svatýa musel pokračovat až do 14. ledna^th- po dokončení testování je datum spuštění produktu obvykle opraveno okamžitě. Řekněme - 15. ledna^thpro jednoduchost. Nyní by v dokonalém světě šlo všechno přesně podle plánu. Ale všichni známe realitu.

V tomto případě předpokládejme, že z nějakého důvodu testování začalo až 7. ledna^th, což znamená, že jsme ztratili polovinu času na testování. Na důkladné otestování produktu však potřebujeme 14 dní. Mohli bychom posunout datum uvedení do provozu dále o 7 dní - nicméně; obvykle to není volba. Protože se slibuje, že se produkt dostane na trh k určitému datu a jakákoli zpoždění nejsou pro podnikání dobré.

Takže obvykle musíme testovací týmy absorbovat zpoždění, nějak kompenzovat, pracovat s dostupným časem a zajistit, aby byl produkt dobře testován. Tvrdá práce, že?

Zde se opět využívá proces řízení rizik.

• Teď když zpoždění se očekávají předem ještě předtím, než začne testování - proces probíhá ve fázi návrhu testu.
• Li ke zpožděním dochází během a Fáze provádění testu který začal normálně - proces je sledován během fáze provádění testu.
• Kroky a metoda jsou stejné bez ohledu na to, v jaké fázi se to stane.

Jaký je postup?

Probíhá řízení rizik, aby se určilo, které oblasti AUT (Testovaná aplikace) vyžadují maximální pozornost. Jedná se obvykle o funkční oblasti (moduly nebo komponenty), které jsou rozhodující pro úspěch konečného produktu a jsou nejvíce náchylné k selhání.

Přečtěte si také=> Analýza poruchových režimů a efektů (FMEA) je technika řízení rizik

Kdo to provádí?

Jelikož se jedná o AUT, znalosti o něm nejsou jen s QA, ale se všemi ostatními týmy - Dev, BA, klienty, týmy pro řízení projektů atd. Jedná se tedy o kolektivní úsilí poháněné testovacím týmem.

Jak probíhá testování základen rizik?

Krok 1) Identifikace rizika

Určete všechny funkční oblasti AUT. To bude jednoduše zahrnovat vytvoření seznamu.

Krok 2) Posouzení rizik

V tomto kroku jsou všechna rizika kvantifikována a upřednostněna. Vyčíslení je jednoduše přiřazení čísla ke každému riziku v seznamu, které udává prioritu, s níž je třeba jej řešit.

O pravděpodobnosti každého rizika (pravděpodobnosti jeho vzniku) a dopadu (míře ztráty, kterou by způsobila, když by se toto riziko stalo) se rozhoduje.

Typickou metodou je přiřazení hodnocení. Například, Pravděpodobnost může nabývat hodnot 1 až 5. 1 je pravděpodobnost výskytu nízká (není pravděpodobné, že se vůbec stane) a 5 vysoká (zcela jistě se stane).

Podobně lze Impactu přiřadit hodnocení 1–5. 1 s nízkým dopadem (i když se toto riziko skutečně projeví, ztráta je minimální) a 5 s velkým dopadem (obrovské ztráty, když k nim dojde).

Krok # 3)

Vytvořte formát tabulky a rozešlete ho všem zástupcům týmu - Dev, BA, Client, PM, QA a všem ostatním, kteří jsou relevantní.

Krok č. 4)

Řekněte každému týmu, aby vyplnil hodnoty na základě jejich hodnocení pravděpodobnosti a dopadu.

Jelikož jsou hodnoty pravděpodobnosti a dopadu číselné, bude výpočet hodnoty „rizikového faktoru“ snadný.

Rizikový faktor = Pravděpodobnost X Dopad. Čím vyšší je rizikový faktor, tím závažnější je problém.

Příklad:

Upozorňujeme, že v tomto okamžiku jde pouze o výsledek hodnocení jednoho týmu. U projektu, kde je zapojeno 5 různých týmů, by tým QA skončil s 5 různými tabulkami.

jaký je síťový klíč pro wifi

Krok # 5)

Vezměte průměr z hodnot rizikových faktorů. Například, pokud existuje 5 týmů, pro každý modul přidejte všechny hodnoty rizikových faktorů a vydělte je 5. Toto jsou konečné hodnoty, se kterými se budeme zabývat. Řekněme, že jde o průměrné rizikové faktory:

Čím více je rizikový faktor, tím více musí být tento modul testován.

Modul 5 a 2 jsou tedy nejdůležitější pro úspěch podnikání. Sdílejte výsledky se všemi týmy.

Krok # 6)

Plán zmírnění rizik : Nyní se jedná o krok, který se mění z Projectu na Project. Zjistili jsme, že na moduly 5 a 2 je třeba se nejvíce soustředit.

Příkladyplánu může být:

1. Moduly 5 a 2 budou důkladně testovány tím, že se ujistí, že jsou testovány všechny testovací případy, které s nimi souvisejí. Ostatní moduly budou testovány na průzkumné bázi.
2. Nejprve se otestují moduly 5 a 2 a poté se podle zbývajícího času postará o ostatní.

Jakmile je vytvořen plán, všechny týmy dosáhnou dohody a podle ní testují produkt, přičemž zohledňují rizikový faktor.

A je to!

Několik důležitých poznámek:

• Jelikož se jedná o kolektivní činnost, která trvá zohledněn názor každého ; šance, že bude přesný a efektivní, jsou vyšší.
• Tohle je není formální metoda a nemusí být součástí každého projektu QA.
• Někdy, i když se tým rozhodne nekreslit tabulky a přiřadit hodnoty - a jednoduchý brainstorming se všemi přítomnými může dát týmu QA dobrý směr, jak postupovat.
• The vstup vývojového týmu je velmi důležité, protože jsou to oni, kdo produkt vytvářejí, takže budou vědět, co by mohlo fungovat a co by mohlo vyžadovat další kontrolu. Nezapomeňte na to dávat pozor.
• I když v procesu probíhá několik kroků, jejich provedení nezabere značné množství času . Zvláště pokud všechny týmy mohou sedět společně a pracovat současně.
• Pamatujte na tento proces a jeho výsledek je pouze alternativa . Získání tolik času, kolik je plánováno na testování, je nejlepší způsob, jak provádět činnost QA.

Závěr

Přístup testování na základě rizika jasně naznačuje, že tester se nezaměřuje jen na neustálé zkoumání vad, bez ohledu na závažnost a prioritu. Nyní se věci změnily a testeři musí pracovat chytře a musí rozumět jasné „potřebě zákazníka a přání uživatele“.

Musí produkt důkladně prostudovat a pochopit, která je nejčastěji používanou funkcí ve výrobě, což je nejdůležitější cesta pro generování výnosů a jak chránit a chránit zákazníky před problémy s výrobou a obchodními hrozbami.

Přístup RBT proto jasně vychovává 3 testery, že pouhé testování všeho nebo rozsáhlé testování neznamená, že testování je kompletní nebo že produkt nemá žádné vady. Efektivní testování ve stanoveném čase a zajištění toho, aby byly zrušeny kritické a hlavní obchodní dopady, což je pro testera velmi důležité.

Testování založené na riziku je tedy nejúčinnějším nástrojem týmu QA k vedení zúčastněných stran projektu na základě rizik projektu. Přístup RBT pomáhá týmu QA při nepřetržité identifikaci rizika a jeho řešení, které by mohlo ohrozit dosažení celkových cílů a záměrů projektu, a pomáhá dosáhnout konečného cíle skupiny QA.

P.S. Slova QA a Testing jsou v dokumentu zaměnitelně používána.

O autorovi: Tento článek je napsán několika členy týmu STH - Gayathri Subrahmanyam a Swati S.

Gayathri je softwarový testovací SME s více než 2 desetiletími zkušeností v testování softwaru a v několika zakázkách široce přijal přístup „Testování na základě rizik“ jako součást Testovací industrializace a uvědomil si výhodu optimalizace testovacích zdrojů a testování kvality.

Bylo pro vás testování založené na riziku náročné? Máte k našemu tutoriálu nějaké zajímavé fakty? Neváhejte vyjádřit své myšlenky v sekci komentáře níže !!

=> Navštivte zde kompletní výukový program pro testovací plán

Doporučené čtení

• Průběžný proces integrace: Jak zlepšit kvalitu softwaru a snížit riziko
• Analýza poruchových režimů a efektů (FMEA) - Jak analyzovat rizika pro lepší kvalitu softwaru a spokojené zákazníky!
• The Ultimate Guide to Risk Based Testing: Risk Management in Software Testing
• Top 10 nástrojů a technik pro hodnocení a správu rizik
• Druhy rizik v softwarových projektech
• Některé zajímavé otázky týkající se testování softwaru
• Výběr testování softwaru jako vaší kariéry
• Zpětná vazba a recenze kurzu testování softwaru