Menu

Rizika v testování pohledem z výšky

V každém projektu, a nemusí to být jen vývoj softwaru, na nás také číhá řada rizik, které mohou způsobit zpoždění projektových aktivit (nebo v extrémním případě jeho nedodání), navýšení nákladů nebo dodání neúplného či nekvalitního díla. V tomto seriálu Vás seznámím se systematickým přístupem k řízení rizik. V každém tématu si řekneme něco málo nutné „podkladové“ teorie a na praktické ukázce si ukážeme jednu z cest, která se osvědčila v praxi.

Začněme pro pořádek definicí pojmu riziko. Glosář ISTQB definuje riziko jako: „Faktor, který by mohl v budoucnu vést k negativním následkům.“ Definice podle projektové metodiky PRINCE 2 říká: „Riziko je nejistá událost nebo soubor událostí, které pokud nastanou, budou mít dopad na dosažení cílů projektu.

V principu existují dvě základní kategorie rizik:

  • Projektová rizika jsou rizika, která mohou mít dopad na dodávku výstupů projektu v plánovaném čase, za plánovanou cenu či v plánovaném rozsahu. Proto se těmto rizikům také mnohdy říká plánovací. Projektovým rizikem může být onemocnění důležitého člena týmu, zpoždění významné subdodávky či neshoda s klientem na očekávané funkčnosti produktu.
  • Produktová rizika jsou rizika, která ovlivňují některou z požadovaných či očekávaných vlastností vytvářeného produktu. Tato rizika jsou někdy nazývána kvalitativní, protože mohou mít dopad na očekávanou kvalitu produktu. Kvalitativních rizik je celá řada, počínaje nesprávnou funkčností systému přes nedostatečnou rychlost odezvy až po například nesrozumitelnou nápovědu. Právě testování je jednou z aktivit, která může napomoci tato rizika významně snížit pod akceptovatelnou mez (anglicky risk tolerance line).

Následující obrázek přehledně shrnuje tyto dvě kategorie rizik se základním odlišením.

Oblasti dopadu obou kategorií rizik jsou zobrazeny v následujícím obrázku.

Hledisko kvalita je záměrně zahrnuto v obou typech rizik. Nekvalita v průběhu práce na projektu může ovlivnit nejen výsledný produkt projektu, ale může mít negativní vliv i na splnění základních projektových atributů – času a nákladů. Špatná specifikace požadavků může mít za následek nepochopení zadání klienta a nutnost přepracování již vyvinutých částí systému. Nevhodné programátorské praktiky za sebou mohou zanechat řadu defektů, které bude nutné odhalovat a opravovat ve více cyklech, než bylo plánováno. Chybně navržená architektura může znamenat nepoužitelnost systému při větší zátěži a nutnost významně přepracovat rozsáhlé porce kódu.

Rizik, ať už projektových či produktových, na každém projektu potkáte stovky. Ne všechna nás „stresují“ stejnou měrou. Kritériem, které definuje úroveň závažnosti rizika, je parametr úroveň rizika (synonymy používanými v různých metodikách jsou míra rizika, závažnost rizika, riziko, rizikové číslo). Tento ukazatel se v principu počítá jako součin míry dopadu a pravděpodobnosti, že riziko nastane.

V dalším díle seriálu se podíváme na praktické příklady projektových a produktových rizik.

Tento článek čerpá z knihy Efektivní testování software.

 

Comments

Dear user, this website uses cookies to ensure you get the best experience on our website. More about cookies
I give my consent to processing of my personal data. More info