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.

Jak je důležité umět prezentovat své nápady

Před dvěma týdny jsem se účastnila konference CzechTest a byla to úžasná zkušenost, jelikož mezi přednášejícími byla řada zahraničních odborníků s 10 a často i 20 lety zkušeností v oblasti testování softwaru. Takových lidí je u nás žalostný nedostatek, nemám pravdu? Největší dojem na mě ale udělal Lloyd Roden, konzultant z Velké Británie, který mimo jiné přednáší taky na konferencích, jako jsou STARWest, STAREast, AsiaSTAR and EuroSTAR.

Čím se tento muž lišil od ostatních řečníků, nebyly jeho myšlenky a obsah jeho prezentací, jelikož jsem potkala řadu chytrých a zkušených lidí, ale jeho komunikační a prezentační dovednosti. Po jeho příspěvku, nejen opravdu přemýšlíte nad tématem, ale hlavně se cítíte nabytí energií a těšíte se, až tyto myšlenky vyzkoušíte v praxi. To, že Lloyd umí lidi kolem sebe přesvědčit a nadchnout je pravděpodobně i jedna z věcí, které ho dělají výborným test manažerem. Protože testování a zejména test management je především o komunikaci.

Rik Marselis, jeden z dalších řečníků, nám položil otázku, zda je testování technický obor nebo spíše humanitní. Já zastávám názor, že je to obojí, jelikož technické znalosti se zde snoubí s komunikačními dovednostmi, asertivitou a diplomacií.

Existují dobří testeři, kteří si rozumí více s počítači než s lidmi, a to je v pořádku, ale pouze do té doby, pokud jsou v týmu s testery, kteří mají velmi dobré komunikační schopnosti a rozumí potřebám stakeholdrů (= uživatelům a ostatním osobám na projektu).
Schopnost efektivní komunikace je nejdůležitější vlastností manažerů a všech osob, které si přejí být vyslyšeny. A já ještě nepotkala testera, který by si nepřál být vyslyšen a nesnažil se prosazovat kvalitu ve své organizaci.

Tester je nejlepší přítel programátora. 

Já učím svoje studenty, že tester je nejlepší přítel programátora. Skeptici jistě nesouhlasí: jak může být někdo, kdo neustále nachází chyby v něčí práci jeho nejlepší přítel?
Jedině díky taktu, respektu k programátorovi a poskytování informací, které programátorovi ulehčují jeho práci.
Ale moment! Tohle je přesně to, co znamená být dobrým testerem. Tester poskytuje informace. Není to skvělé?!

Programátor je pouze další osobou, které pomáháme poskytováním potřebných informací. Pokud se dobře staráme o programátory a pomáháme jim rychle nacházet a opravovat problémy poskytováním relevantních informací, často se stáváme dobrými přáteli.
Programátoři nám neposkytují službu opravování chyb, my jim poskytujeme službu dodávání potřebných informací. Samozřejmě nejsou jediní, komu tuto služby poskytujeme, ale jsou skupinou, kterou často zanedbáváme. Pokud někomu nevěnujeme pozornost, kterou si zaslouží, nebo i hůř na něj nadáváme, není se co divit, že pak vztahy nejsou ideální. Špatný vztah mezi testery a programátory je pak znakem špatných testerů a managementu, který problém ignoruje.

Tester poskytuje informace. Dobrý tester poskytuje ty správné informace.

Z tohoto důvodu bych Vás všechny chtěla vyzvat: Běžte za programátory. Seznamte se. Zjistěte, jak by jste jim mohli pomoct. Zeptejte se jich, jaké informace by chtěli mít v reportu chyby, co jim na reportech vadí. Zeptejte se na jejich další problémy s kvalitou a žádejte je o zpětnou vazbu pravidelně.
Toto je dovednost, kterou musíme neustále pilovat: jak poskytovat ty správné informace a jak je správně komunikovat.

A pokud byste chtěli se hned do toho pustit, zde je pár tipů, jak začít.

Tipy:

• Zlepšete své reporty chyb: crash course on reporting bugs
• Zlepšete svoje přesvědčovací schopnosti: coaching testera how to email and influance stakeholders
• Zlepšete své prezentační schopnosti: Pokud můžete, zaplaťte si soukromé lekce a pokud ne, přečtěte si pár základních tipů pro dobrou prezentaci (Presentation Magazine) a podívejte se na pár tutoriálů na Youtube (Effective Presentation Skills)
• Cvičte své schopnosti, kdykoli máte příležitost: uTest bug battle

Murphyho zákony. Proč jsou pravdivé?

Program je dobrý, když je bezchybný – což je nemožné.

Jsou lidé, kteří nevěří v existenci bezchybného softwaru a lidé, kteří si myslí, že testování bezchybnost zaručí. (Jsou i jiné skupiny lidí, z nichž nejhorší jsou ti, které kvalita nezajímá. Ale ty teď ponechme stranou.)
Bezchybné programy existují, ale pouze ty triviální. Například pokud jediné, co daný program má umět, je vypsat na obrazovku "Ahoj světe!" a skončit.
Čím je program složitější, tím těžší je i zkontrolovat jeho bezchybnost.
Nakonec i jednoduchý program o pár řádcích může mít tolik různých cest kódem, že bychom je všechny neotestovali ani za deset let.
Proto u jakéhokoli netriviálního programu, tím spíš složitých aplikací a systémů, je nutné počítat s tím, že ať na testování věnujeme sebevíc času, vždy bude obsahovat chyby.

Neviditelných chyb je nekonečné množství, oproti viditelným chybám, kterých je už z definice konečné množství.

Tento zákon je pouhým důsledkem Dijkstrova axiomu, že testování je vhodné k dokázání přítomnosti chyb, ale nevhodné k prokázání jejich nepřítomnosti.

Každý program obsahuje jeden chybný řádek.
Každý program jde zkrátit o jeden řádek.
Z toho plyne, že každý program jde zkrátit na jeden řádek, který je chybný.

K tomu téměř není co dodat. Snad jen, že je to jako sebenaplňující se proroctví. Čím více do kódu člověk zasahuje, tím je větší pravděpodobnost, že do něj zanese chybu.

Fungující program má pouze neobjevené chyby.

Tento zákon by ve skutečnosti měl znít, že software, na který si nikdo nestěžuje, má pouze neobjevené chyby a to proto, že ho nikdo nepoužívá.
Tak to funguje ve skutečnosti. Cílem testování je dosáhnout určitého (nejlépe vysokého) stupně kvality, ne dosáhnout toho, aby zákazník nenahlásil jedinou chybu.

Stačí, když zákazník bude mít z produktu dobrý pocit, protože nebude narážet na chyby často a ty nebudou mít žádné vážné důsledky. A ty chyby, na které narazí, budou rychle vyřešeny

Počet chyb vždy překročí počet řádek v programu.

Toto je spíše zobecněné pozorování. Často je tento zákon pravdivý, protože během životního cyklu vývoje dojde k tolika změnám v programu, že i když konečný program má x řádek, programátoři jich napsali mnohonásobně více.

Šance, že program dělá to, co má, je nepřímo úměrná počtu řádek v programu.

To je snadné pochopit. Čím je program složitější, tím je těžší se v něm vyznat, na něco nezapomenout a neudělat chybu.

Nehledě na to, kolik zdrojů máš, nikdy to není dost.

Netriviální program nemůžeme nikdy kompletně otestovat a nemůžeme zjistit, kolik dosud neobjevených chyb obsahuje. Je tedy možné testovat do nekonečna.
Důležité je dokázat s přidělenými zdroji co největšího efektu. Což je pravé umění nejschopnějších manažerů. Pokud objevení chyby a její oprava stojí více než kdyby jí objevil až zákazník, pak je na čase testování ukončit.

Patch je kus softwaru, který nahrazuje starou chybu novou.

I když je patch relativně malý kus softwaru, je nutné ho otestovat. Spoléhat na to, že vše poběží, jak má, aniž by to někdo opravdu vyzkoušel, je spolehlivým receptem na katastrofu.

Chyby se objeví v jedné části fungujícího softwaru, pokud další zdánlivě nesouvisející část je modifikována.

Jsou dva důvody, proč i když je změna pouze v jedné části programu, se mohou najednou objevit chyby tam, kde předtím žádné nebyly.
První důvod je, že tyto části spolu nějakým způsobem souvisí, ale nikdo si to neuvědomil.
Například jedna část volá funkci, ve které se nachází nadbytečné volání jiné funkce, která byla touto změnou zrušena.
Druhý důvod je, že přestože obě části softwaru spolu nesouvisejí, používají stejné zdroje. Může se tak projevit chyba, která v softwaru byla už nějakou dobu. Například špatně ošetřené sdílení paměti nebo ukazatel, který ukazuje na náhodné data.

Ty nejpřehlédnutelnější chyby způsobí ty největší problémy.

Malé a nenápadné chyby mají buď malé nebo žádné dopady (například logo je pixel posunuté mimo určenou pozici) nebo velmi závažné důsledky (V jednom ze sta případů dojde ke špatnému zaokrouhlení částky, což může mít za následek ztráty několikanásobně větší, než byla cena softwaru). Pokud chyba je nápadná, uživatel si jí hned všimne a pokud její dopady jsou závažné, tak je možné hned situaci napravit, aby se už neopakovala. Pokud ale chyba uniká pozornosti, její důsledky se hromadí, až se lavina protrhne a může dojít k velmi vážným problémům.

Softwarové chyby je nemožné detekovat kýmkoli kromě koncového uživatele.

Přestože testeři při testování odhalí velké množství různých chyb, některé chyby je těžké odhalit pro kohokoli než koncového uživatele. To proto, že i když se tester snaží na software dívat z pohledu uživatele, tak běžným uživatelem není, a chybí mu znalost chování uživatele.
Jediný způsob, jak zjistit reakce uživatelů na software, je vidět je s ním pracovat.

Jakoukoli chybu nehledě na její složitost, lze objevit pouhým pohledem.
Důsledek: Otravující kolemjdoucí s nevítanými radami ji spatří okamžitě.

Pokud už tester vyčerpal všechny nápady a objevil svým trénovaným okem všechny chyby, je potřeba k nalezení dalších chyb změnit přístup nebo i třeba zkusit větší odstup.

Chození po vodě a vývoj softwaru podle specifikace je snadné pouze pokud je obojí zamrzlé.

Každá změna specifikace přináší do vývoje rizika:
• O změně se nedozvědí všichni, kdo o ní potřebují vědět
• Změna bude nejasná a špatně pochopena
• Je třeba zahodit už otestovanou část a napsat novou, která je potenciálně plná chyb
• Složitost toho, co si vývojář musí pamatovat, se zvyšuje a je lehčí udělat chybu
• ...

Nejlepší způsob, jak obejít bezpečnostní prvek, je posadit za počítač třináctiletého.

Ve snaze zabezpečit software před nevítanými vetřelci mají lidé občas tendenci se soustředit na nejčastější a nejznámější způsoby průniku a budování sofistikované obrany proti nim. Přitom mohou přehlédnout nepřímou ale jednoduchou cestu dovnitř. Dalo by se říct, že tento zákon je důsledkem toho, když někdo přes samé stromy nevidí les.

Murphyho zákony byly převzaty z Murphy's computers laws, přeloženy a popřípadě mírně upraveny.

Základy testování

Protože literatury ohledně testování je v češtine velmi málo, rozhodla jsem se zveřejnit část svojí příručky o testování, která vznikla v rámci diplomové práce a která se zabývá základy testování.
Doufám, že se Vám bude líbit.

Tuto příručku a další materiály naleznete v sekci ke stažení. 

Zamyšlení nad testovací misí

Manažer by měl ...

... být vůdčí osobností

... jasně vysvětlit ostatním členům týmu projektovou misi a cíle

... umět nadchnout pro úkol

... podpořit přijetí projektových cílů zaměstnanci za své

... podporovat spolupráci a aktivitu

... motivovat ke zlepšování

S takovýmto přístupem jsem se setkala v přednáškách o managementu škole, v moudrých knihách jako je např. Měření v systémech managementu jakosti od Jaroslava Nenadála a bohužel poněkud méně často v praxi.

Atmosféra spolupráce, nadšení a odpovědnosti za dosažení cílů je jistě v mnoha oblastech plus, ale v testování softwaru je přímo magickou ingrediencí.

Definice cílů a snaha o jejich dosažení je oním počátkem cesty, jak se stát z průměrného testera, který jen sleduje scénáře a návody opravdovým expertem na testování.

Test manager nebo projektový manager definicí testovacích misí a nadchnutím testerů pro jejich dosažení vytváří prostředí, které testery inspiruje ke zlepšování a řada z nich pak začne růst ve vynikající odborníky.

Je to ale cesta, kterou neujdete po pár hodinách nebo dnech. Je to cesta, po které můžete jít tak dlouho, dokud vám vydrží motivace.

Protože dokud budete mít důvod se chtít zlepšovat, prostor ke zlepšení vždy najdete.

Mise testování určuje, co je momentálním cílem testerovy práce, a definuje kritéria, která hodnotí, zda a nakolik misi splnil. Je tak možné lépe řídit práci testera, je-li mu řečeno, jakých cílů má testování dosáhnout, s jakým záměrem má testovat.

Cíle testovací mise mohou být různé: odhadnout chybovost jednotlivých modulů aplikace, připravit reprodukovatelné testy, odhalit co nejvíce chyb, nebo třeba jen rychle odhalit závažné chyby, bránící nasazení aplikace.

Často testování sleduje více záměrů zároveň a mise tak má více cílů.

Smyslem definice misí, je uvědomit si záměr testování a schopnost posuzovat jejich výsledky.

Splnili jsme svou misi? Nakolik? Proč jsme selhali? Existuje prostor pro zlepšení? Co jsme se naučili? Je možné dosáhnout jiným přístupem lepších výsledků?

Definice konkrétních cílů dané iterace testování je mocným nástrojem. Manažerům umožňuje efektivní řízení zdrojů, testery vede pak k tomu, jak dělat svou práci co nejlépe.

Nejužitečnější cíle jsou definované tak, aby byly měřitelné.

Dvě skupiny otestují stejný produkt, jak rozhodnout, která je lepší?

Pokud nevíme, nakolik jsme dobří a nakolik splňujeme naše cíle, chybí prostor pro zlepšování. Chybí dostatek motivace a firma místo odborníků a efektivního testování bude mít jen samé průměrné klikače a ne moc dobré ale za to drahé testy.