pondělí 18. dubna 2011

Ekonomické principy testování – proč testovat, co a jak dlouho

Tento týden mi přišel email, ve kterém dotyčný položil následující otázky:
  1. Jak se vlastně přesně určuje kritičnost a nekritičnost funkčností? Na základě vazby na nějaké obchodní obraty?
  2. Vezměme situaci cca. 40 systémů, cca. 800 rozhraní, a násobky x1000 funkčností.
    Jak lze v takovémto množství efektivně řešit kritičnost jednotlivých funkčností a jejich vazeb? Existují na to nějaké závislostní algoritmy?
  3. Lze definovat ukončení testů na základě kritérií, že pokud klesne počet chyb za den pod nějaký práh, tak lze přejít do produkce, nebo se do produkce musí přejít až s počtem chyb 0 na všechny komponenty?
Jelikož všechny tyto otázky se točí okolo ekonomického pochopení testování, uvědomila jsem si, že jsem se zde ještě nevěnovala vysvětlení základních principů.

Testujeme, dokud se nám to finančně vyplatí

V byznysu každý krok, který děláme, děláme s vidinou budoucího zisku. Pokud nabízíme zaměstnancům různé výhody, děláme to proto, abychom nalákali kvalitnější zaměstnance a snížili náklady způsobené jejich fluktuací. Pokud investujeme do kvalitnějších výrobků, děláme to proto, že navýšení kvality je pro nás finančně výhodné. Ať už díky tomu, že nebudeme muset vynakládat vysoké částky na nápravu chyb objevených zákazníky, nebo proto, že nám to přinese více spokojených zákazníků.

To souvisí i s tím, že testujeme tak dlouho, dokud se nám to finančně vyplatí. Pokud jsou náklady na objevení a opravu chyby v dané fázi větší, než jaké jsou předpokládané náklady plynoucí z neopravení chyb, nemá smysl pokračovat. Rovněž se může manažer dostat do situace, kdy je aplikace vysoce chybová, testování je velmi efektivní a bylo by dobré ještě dva tři měsíce v něm pokračovat a opravovat chyby, ale z jistých, například právních důvodů, je přesto finančně výhodnější nasadit aplikaci do provozu.

Za znalost celkové situace a rozhodnutí o nasazení je zodpovědný zákazník, typicky manažer té části podniku, která aplikaci požadovala a bude ji využívat. Test manažer je zodpovědný za to, aby mu poskytl dostatek informací pro toto rozhodování, zejména ho seznámil s riziky, která ještě nebyly odstraněny. Pokud spolehlivě funguje pouze 20 % funkcí, 10 % je natolik chybových, že je není možné využívat, a zbytek aplikace není ještě otestovaný, jaké jsou konkrétně rizika nasazení?

Tester tedy nestanovuje kritéria a nerozhoduje o tom, kdy může aplikace přejít do produkce. O tom rozhoduje vždy zákazník a je na něm, jaké množství chyb a jaké závažnosti bude tolerovat, nebo zda rozhodujícím kritériem pro něj nebude naopak vnější vliv, například situace na trhu.

Sledujeme efektivitu testování, co se týče počtu objevených chyb

Jak již výše uvádím, testujeme tak dlouho, dokud se nám to finančně vyplatí. Co to znamená? Že je potřeba s testováním přestat v okamžiku, kdy by nalezení a oprava chyb objevených dalším testováním byla už dražší, než netestovat a riskovat jejich objevení a opravu v budoucnu. Určení takového okamžiku ale není triviální. Nehledě na to, že je třeba pracovat s pravděpodobností, je také nutné mít dostatečně podrobné informace o nákladech, které většina firem na této úrovni nesleduje a nemá je tedy ani k dispozici.

Méně přesnou, ale zato jednoduchou a rozumnou alternativou je sledování počtu nalezených chyb v čase. Následující obrázek ukazuje typický příklad počtu objevených chyb za určitou dobu testování.


Zpočátku testovací tým nachází velké množství chyb. Postupem času je objevováno stále méně chyb a zdá se, že další testování už nemůže přinést žádná překvapení. V tomto bodě nezkušený test manažer ukončí testování s tím, že produkt je již připraven. Zkušený test manažer pokračuje, protože ví, že testování běžně popadne druhý dech a počet objevených chyb opět začne růst. Zda se jedná o růst skokový nebo postupný, jak ukazuje křivka trendu, ovlivňuje zejména to, zda test manažer podpoří růst počtu chyb obměnou testů. Nicméně i bez této obměny se navýšení dá očekávat. Ukončení testování je pak vhodné až v druhé nebo třetí prohlubni (lokálním minimu).

Testování je investice. Peníze je třeba dát tam, kde to bude mít největší efekt

Vhodné zaměření úsilí je důvodem pro určování kritičnosti nebo priorit při testování. Co je jak důležité pro byznys určuje opět zákazník. Většinou bývá v rámci složitých systémů kritičnost aplikací a byznys procesů dobře známa a pro její zjištění se stačí obrátit na manažera spravujícího rizika a krizové plány. Pokud takovéto rozdělení v podniku ještě není provedeno, je možné při určení důležitosti aplikace vycházet z toho, jaké dopady by měla její nedostupnost či špatné fungování. Například se odhadnou ztráty z jednodenní nedostupnosti aplikace, vytvoří se rozmezí ztrát a ty se přiřadí jednotlivým označením důležitosti.

Co se týká přidělení důležitosti jednotlivým testům, zde se čerpá zejména z důležitosti uživatelských případů (use-casů). Zákazník určuje své priority již ve fázi sběru požadavků a specifikaci. Při určení priorit je možné vycházet z toho, kolik lidí danou funkci využívá, zda pracuje s kritickými zdroji (penězi, osobními údaji, atd.) nebo jak podstatné jsou byznys procesy, které funkce zpracovává.

Často však zákazník zejména u menších projektů určuje důležitost spíše pocitově a na přání dodavatele určí např. 20% nejdůležitějších funkčností. Oblíbené a pro zákazníka dobře pochopitelné je přiřazení tří stupňů důležitosti:

Critical to quality (Kritické pro kvalitu produktu) – Bez funkcí, kterým je přiděleno toto označení, by produkt nebyl použitelný a nesplnil by ani ty nejzákladnější potřeby zákazníka.

Good enough quality (Dostatečná kvalita) – Funkce s tímto označením zaručují potřebné, ale ne nezbytné činnosti.

Nice to have (Bylo by hezké toto mít) – Funkce, které jsou třešničkou na dortu, mohou usnadňovat práci uživatelům nebo být další možností, kterou by někdo mohl v budoucnu potřebovat.

Odpovědí na všechny tyto tři otázky je: „zeptejte se zákazníka, co by si on přál“. Protože on je ten, kdo investuje a on je ten, kdo bude hodnotit návratnost své investice.


Oblíbené příspěvky