Proč bychom měli testovat?

Tento příspěvek je určen nejen testerům, ale i managerům, které zajímá, co by jim testování softwaru mohlo přinést a možná nepřináší. Proto začnu definicí dvou pojmů, které dále často používám:

Zajišťování kvality (Quality Assurance) – plánované a systematické procesy jejichž cílem je zajištění vhodnosti produktu k jeho zamýšlenému účelu.

Testování - proces sběru a třídění informací získaných skrze zkoumání produktu, součást obecněji pojatého zajištění kvality.

Pokud máme pocit, že testování a zajišťování kvality není věnován dostatek pozornosti a společnosti tuto stránku vývoje softwaru podceňují, možná za to do jisté míry může i to, že se nám nedaří přesvědčit ostatní o důležitosti testování a jeho odborného řízení.

Jaké jsou tedy přínosy testování softwaru a zajišťování kvality? Které body bychom měli zmínit při prezentaci přínosů?

Proces zajišťování kvality ovlivňuje tři manažersky významné oblasti:
- Marketing
- Risk management
- Snižování nákladů

Marketing

To, že kvalitní produkt dodaný zákazníkovi má pozitivní vliv na pověst firmy, zatímco vysoce chybový nespolehlivý software pověst ničí, je jednoduchý logický závěr. Těžší je už odhadnout nebo si jen uvědomit míru tohoto vlivu. Vliv nekvalitního produktu na pověst firmy totiž přichází ve vlnách. Některé z nich jsou okamžité a rychle mizí, některé negativně ovlivňují firmu i po několik let.

První vlnou odezvy je reakce bezprostředního zákazníka, který na základě spokojenosti rozhoduje o následné spolupráci.

Druhou vlnou je reakce konečných zákazníků. Ti v případě nepříznivého přijetí produktu mohou způsobit řadu nepříjemností. Jejich neustálé stížnosti a reportování chyb může způsobit neočekávané prodražení projektu, takže z původně ziskového projektu se stane projekt prodělečný. Dále jejich nepříznivé přijetí produktu může změnit názor managementu zákazníka na dodavatele, nebo se dostat mezi širokou veřejnost prostřednictvím novinového a televizního zpravodajství.

Třetí vlnou je reakce současných zaměstnanců a dalších lidí z oboru výroby IT. Kvůli neustálé fluktuaci zaměstnanců se pověst softwarové firmy šíří dále a po mnoho let přetrvává. Schopní zaměstnanci firmu, která nedokáže dodat kvalitní software, opouštějí, protože nechtějí být spojováni s dalším neúspěchem nebo protože je jednoduše nemotivuje se zlepšovat. Tam, kde chybí objektivní měřítka kvality, tam je vždy nedostatek snahy o zlepšení. Ze stejných důvodů se firmě vyhýbají potencionální schopní zaměstnanci. Slyšeli o ní negativní věci ze strany bývalých či současných zaměstnanců.

Čtvrtou vlnou, která ovlivňuje softwarovou firmu s největším zpožděním, je neochota dalších zákazníků nebo jiných softwarových firem s ní spolupracovat. Před zaměstnanci firmy nelze zatajit nedostatek snahy o zajištění kvality a špatné nastavení procesů. Pokud tito zaměstnanci jsou přesvědčeni o tom, že by si sami svojí firmě nikdy nedali zakázku na vývoj softwaru, pak této firmě nebudou ochotni dát zakázku ani za několik let, kdy budou takováto rozhodnutí dělat z pozice manažerů a ředitelů. Stejně se zachovají i všichni, kteří se o špatně nastavených procesech dověděli od svých nových kolegů či kamarádů.

V těchto čtyřech vlnách působí každý projekt dle své kvality a dopadů v pozitivním či negativním směru na marketing.

Risk management

Testování je nástrojem k získání objektivních informací o stavu vyvíjeného softwaru. Tyto informace jsou pak nejdůležitějším vstupem pro řízení rizik spojených s vývojem softwaru. Testování se prolíná celým procesem vývoje. Už od samého počátku tedy kontroluje soulad vývoje s představami zákazníka, srozumitelnost, jednoznačnost a logiku výstupů. Včasným informováním o nedostatcích a chybách zabraňuje nedorozuměním a zbytečnému plýtvání zdrojů na špatné verze. Řízení kvality pak navíc definuje a hlídá postupy vývoje z hlediska zajištění jednoduchosti, srozumitelnosti, správnosti, přesnosti, rychlosti a dalších kvalitativních měřítek. Díky tomu dochází jak k výraznému snížení pravděpodobnosti vzniku problémů s kvalitou během i po vývoji, tak k omezení dopadů při vzniku problémů.

Testování výrazně předchází problémům s zákeřnými chybami. U softwaru z finančního, lékařského nebo jinak kritického sektoru, mohou ztráty způsobené dopadem jedné jediné zákeřné chyby několikanásobně převyšovat celý rozpočet na vývoj tohoto softwaru.

Bez testování zůstávají firmě jen dvě nepříjemné možnosti, jak s omezit riziko spojené s vývojem softwaru:
- zajistit si subdodavatele, který riziko do jisté míry převezme za ně
- pokud to jde, pojistit se proti některým typům problémů

Snižování nákladů

Přestože jednou z nejčastějších manažerských chyb je při snižování nákladů obětování kvality, právě efektivně nastavené zajišťování kvality přináší největší úspory. Z ekonomického hlediska by testování mělo trvat tak dlouho, dokud předpokládaná průměrná cena nalezení a opravy chyby objevené v příštím cyklu testů je menší než průměrné náklady na chybu objevenou zákazníkem vynásobené pravděpodobností objevu chyby. Zjednodušeně, testovat by se mělo tak dlouho, dokud je to finančně výhodnější než netestovat. Zajišťování kvality se navíc snaží nastavit procesy tak, aby docházelo k co nejmenšímu počtu chyb a ty byly co nejlevněji odstranitelné. Zajištění kvality je investice a je tedy vhodné sledovat její návratnost.

Problém je v tom, že je velmi obtížné zvládat řízení kvality tak, aby bylo maximálně efektivní a aby minimalizovalo náklady. Takový úkol vyžaduje zkušenosti, cit a výborné znalosti zkušeného odborníka. Proto, když už testujeme, je třeba to dělat dobře.

Jak začít?

Nastavit efektivně proces testování není jednorázová věc, ale vzniká neustálým dolaďováním na základě různých rozumně zvolených měřítek, které varují, pokud není vše v pořádku a na kterých lze sledovat zhoršení či zlepšení efektivity.

Pochopení klíčové role řízení kvality při vývoji softwaru, stanovení měřítek, procesu řízení kvality a vyhledání vynikajících odborníků s praxí přímo v testování dává dohromady dobrý základ pro každé oddělení řízení kvality softwaru.

Problémy s pokrytím kódu

Jednou z důležitých technik je sledování nakolik je aplikace pokryta testy. Můžeme sledovat kolik případů užití máme porytých, kolik zákazníkových požadavků, ale nejpřesnější alespoň co se týče pokrytí funkčnosti je pokrytí kódu.
Při zjišťování pokrytí kódu se zaznamenává, jaký kód byl při testování spuštěn a jaký naopak otestován ještě nebyl.

Nejjednodušší ale zároveň nedostačující a zavádějící je pokrytí příkazů - řádků.

To pouze kontroluje, zda daný příkaz, řádek, byl proveden v průběhu testování, pro pokrytí podmínky tak může stačit její libovolné vyhodnocení.

Formálně: T splňuje kritérium pokrytí příkazů pro daný kód K, jestliže pro každý příkaz p náležící kódu K existuje test t z množiny T, že při provedení t bude spuštěn příkaz p.

Pro testera nebo programátora není problém dosáhnout velmi vysokého (i 100 %) pokrytí příkazů programu plného chyb aniž by jediný test selhal, aniž by byla objevena jediná chyba. Přesto, že tato metrika je takto zavádějící, pro svou jednoduchost je i tak oblíbená.

O stupeň pokročilejší je pokrytí hran – rozhodnutí.

Formálně: Představme si graf, kdy příkazy tvoří uzly a možné přechody mezi nimi hrany. Pak za sebou provedené příkazy tvoří hranu a podmínka uzel, ze kterého vedou dvě hrany, jedna pro true a jedna pro false hodnotu. Pak množina testů T splňuje kritérium pokrytí hran pro daný kód K, jestliže pro každou hranu h výše popsaného grafu existuje test t z množiny T, že při provedení t projde výpočet hranou h.

Jednoduše řečeno u pokrytí hran je každá podmínka uzlem, ze kterého vedou dvě hrany.

Například:

Máme kód se třemi podmínkami, z nichž jedna je vnořená.



Graf pokrytí hran pak vypadá následovně:



Přitom modré kolečka představují podmínky, zelená ostatní příkazy.

Při jakýchkoli složitějších podmínkách je ale i toto pokrytí nedostatečné.

Další stupeň představuje pokrytí podmínek.

Formálně: Množina testů T splňuje kritérium pokrytí podmínek pro daný kód K, jestliže splňuje kritérium pokrytí hran a pro každou složenou podmínku platí, že pro každou její část p existují testy t, u z množiny T, že při provedení t se p vyhodnotí kladně a při provedení u záporně.

Pokud se vynechá část, že pokrytí podmínek musí splňovat pokrytí hran, tak k nepokrytí hran a pokrytí podmínek dochází v případě, že pro všechny možné vstupy je vždy celá podmínka vyhodnocena jako pravdivá nebo nepravdivá.

Vylepšení pokrytí podmínek spočívá v tom, že se berou v úvahu všechny možná vyhodnocení podmínky, nejen to, zda je pravdivá, či nikoli.

Například:

Mějme složenou podmínku if (a>0 || b>0).
K pokrytí hran by stačili tyto testy: {a = 5; b = -2}, {a = 0; b = 0}
K pokrytí podmínek by tyto testy nestačili, protože část b > 0 je v obou případech nepravdivá. Pokrytí podmínek lze však dosáhnout jinými dvěma testy: {a = 5; b = 2}, {a = 0; b = 0}

U této verze je už těžší najít chybu, kterou bychom plným pokrytím podmínek neodhalili, i když jisté typy chyb stále budou i v plně pokrytém kódu zůstávat.

Nejvyšší stupeň pokrytí je pokrytí cest, které sleduje všechny možné průchody kódem a proto představuje opravdu podrobné otestování.

Formálně: Množina testů T splňuje kritérium pokrytí cest pro daný kód K, jestliže splňuje kritérium pokrytí podmínek a pro každou cestu C v grafu kódu spojující vstupní a výstupní uzel grafu a obsahující nejvýše n cyklů existuje test t z množiny T, že při provedení t projde výpočet cestou C.

I když ne všechny chyby jdou odhalit pouze z kódu, pokrytí cest poskytuje jistotu, že byly otestovány všechny možnosti běhu. Problémem je praktická nepoužitelnost tohoto pokrytí, jelikož jeho složitost způsobuje exponenciální růst počtu testů.

Otázka 1: Kolik testů (průchodů kódem) je potřeba, aby měla metoda code_coverage pokryty příkazy; hrany; podmínky; cesty?



Otázka 2: Kolik testů (průchodů kódem) je potřeba, aby měla metoda code_coverage2 pokryty příkazy; hrany; podmínky; cesty?

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.