6.1.1 Testování obsahu dokumentů Cílem každého dokumentu je předat informaci čtenáři. Tomuto účelu je třeba primárně přizpůsobit obsah dokumentu. Dále musí být dokument v souladu s cíli projektu a se svým účelem (tzn. dokument „Definice architektury“ se věnuje architektuře systému). Hlavní kritéria, která by měl obsah dokumentu splnit, jsou vodítkem jak při psaní dokumentu, tak při jeho testování. Těmito kritérii jsou: ▞▞
▞▞ ▞▞
▞▞ ▞▞
Úplnost – v dokumentu jsou obsaženy veškeré informace odpovídající charakteru dokumentu, případně jsou uvedeny odkazy na zdroje, kde lze získat potřebné znalosti. Čtenář si při čtení dokumentu nemusí nic domýšlet. Správnost – veškeré informace v dokumentu musí být správně, resp. musí být pravdivé. Čtenář musí dostat správné informace, aby se případně mohl na základě dokumentu správně rozhodnout. Relevantnost – informace v dokumentu se musí týkat cíle projektu a účelu dokumentu. Zbytečné informace otupí čtenářovu pozornost a může se stát, že přehlédne ty důležité. S relevantností informací v dokumentu nám může pomoci vhodná forma (šablona) dokumentu a její dodržování. Jednoznačnost – formulace musí být voleny tak, aby nebylo možné text interpretovat více způsoby. Chybou je také, pokud informace v dokumentu zamlžují čtenáři cíl projektu. Konzistence – text musí být konzistentní napříč celým dokumentem, ale i napříč celým projektem – nelze v úvodní studii projektu deklarovat záměr, který je pak v dokumentaci návrhu softwaru popřen nebo změněn.
Z těchto kritérií je často nejtěžší soustředit se na úplnost a konzistenci, a to nejen v projektech s rozsáhlou dokumentací, ale i tam, kde vzniká jen několik málo základních dokumentů. Požadavek na úplnost bývá porušen tam, kde autoři dokumentů zapomínají, že čtenáři nemusí mít stejné informace (např. ze schůzek) jako mají oni. Pokud dokument není úplný, pak i sám autor může mít po nějaké době problémy s jeho interpretací. Je třeba brát v potaz tzv. trvání dokumentu (tedy že se dokument může používat i za několik měsíců či let). V případě konzistence bývají problémy spojené buď s množstvím dokumentů, nebo s množstvím změn, které vznikají v rámci projektu. Dalším problémem spojeným s konzistencí bývá velikost týmu autorů. Zde můžeme narazit i na problém jednoznačnosti, kdy různí lidé interpretují jeden výraz nebo formulaci různě. Dobrým opatřením pro zvýšení konzistentnosti dokumentů je příprava terminologického slovníčku pojmů, které budou v dokumentech využívány.
6.1.2 Testování formální stránky dokumentu To, že je dokument správně po formální stránce, se týká struktury jeho obsahu, gramatické správnosti a vzhledu. Dokument správný po formální stránce usnadňuje čtenáři orientaci v textu, a tím pádem umožňuje i snadnější pochopení informace. Na druhou stranu: pokud je dokument správně po stránce formální, ale neobsahuje pravdivé nebo kompletní informace, pak nemá pro realizaci projektu velkou cenu. Ačkoliv se formální stránka dokumentu tedy může zdát oproti obsahové podřadná, není dobré ji zanedbávat. Její zanedbání může mít i fatální následky v případě, že je dokumentace hlavním výstupem projektu, nebo pokud je dokumentace určena (externím) spolupracovníkům či zákazníkům. Dobrá struktura dokumentu může pomoci naplnit pravidla pro obsahovou správnost (relevantnost) dokumentu. Proto je dobré si pro dokumenty vytvořit šablony, které budou v rámci projektů naplněny informacemi. Šablony nejen umožňují soustředit se primárně na obsah a ne na formu, ale slouží i jako kontrolní seznam, který vám pomůže nezapomenout na důležité informace.
6.1.3 Metody testování dokumentace Prvním krokem statického testování dokumentů by mělo být ověření dodržení určených projektových šablon. Druhým krokem je pak kontrola samotným autorem, kde by mělo dojít k opravě všech zásadních a hrubých chyb – např. by měly být v textu opraveny překlepy, gramatické chyby apod. V ostatních oblastech ale může dojít k jisté slepotě k chybám. Ta je dána tím, že autor po nějakém čase již není schopen chyby vnímat, protože se stanou součástí dokumentu, nebo některé informace považuje za samozřejmé
98
Efektivní testování softwaru
Ukázka elektronické knihy, UID: KOS227969
a nemá potřebu je se čtenáři sdílet. Proto je vhodné využít jako třetí krok alespoň jednu z následujících metod [2]: ▞▞
▞▞
▞▞
▞▞
Neformální revize (metoda čtyř očí) znamená kontrolu jedním kolegou nebo několika málo kolegy autora dokumentu. Není nutné, aby vybraní kolegové byli v tvorbě podobného dokumentu zkušenější než autor. Výhodou je nízká formálnost kontroly a malé náklady na provedení kontroly. Nevýhodou je, že pokud nejsou kolegové dostatečně obeznámeni s projektem, pak není dostatečně otestována konzistence mezi dokumenty. Problém může nastat i tehdy, pokud je autor přítomen inspekci a poskytuje kolegovi vysvětlení a doplňující informace. Dokument by měl obstát sám o sobě. Walktrough je setkání více účastníků, iniciované a vedené autorem dokumentu, které může být na různé úrovni formálnosti. Může se jednat o skupinovou kontrolu výstupů, kdy autor představuje dokument ostatním, nebo o zkoušku prezentace či nácvik možných scénářů nanečisto. Výhodou je, že více kontrolorů má šanci najít více chyb. Nevýhodou je nutnost koordinovat skupinu kolegů. Technická revize na rozdíl od předchozích metod vyžaduje určitou míru formálnosti. Na úrovni organizace by mělo být nastaveno, jak revize probíhá, jaké jsou její cíle (co se kontroluje) a jaké jsou její výstupy. Výstupem by vždy měl být minimálně výstupní report, hodnotící kvalitu revidovaných dokumentů. Inspekce je formální postup, kde dokument kontroluje celá skupina kontrolorů. Mělo by se jednat o kolegy, kteří mají dostatečné zkušenosti. Měli by být přítomni i lidé zodpovědní za jednotlivé oblasti projektu, kterých se dokument může týkat. Každý účastník inspekce by měl dostat dokument k posouzení předem. Na setkání věnovaném inspekci dokumentu jsou pak probírány již jen připomínky a otázky k dokumentu. Výhodou tohoto způsobu je, že nalezne velké množství chyb, na druhou stranu se ale jedná o velmi náročnou techniku z hlediska přípravy, organizace a časové náročnosti. Celý proces má na starosti moderátor, který není autorem posuzovaného dokumentu.
Při statickém testování dokumentace je vhodné pracovat s kontrolním seznamem otázek, resp. kritérií, které budeme ověřovat. Základní obecné otázky prezentované níže můžete vždy rozšířit podle konkrétního typu revidovaného dokumentu: ▞▞
▞▞ ▞▞ ▞▞ ▞▞ ▞▞ ▞▞
Je dodržena šablona pro daný typ dokumentu? Pokud nepoužíváte šablony, pak byste se měli ptát: „Obsahuje dokument všechny informace, které má čtenář právo očekávat od tohoto typu dokumentu?“ a „Neobsahuje dokument informace zbytečné pro zamýšlený účel dokumentu?“ Byla použita kontrola pravopisu (ať už automatická nebo manuální) a všechny chyby byly opraveny? Jsou informace sdělované v dokumentu jednoznačně formulované a napomáhají realizaci cílů projektu? Jsou informace sdělované v dokumentu v souladu s účelem dokumentu? Je dokument konzistentní s ostatními výstupy projektu? Jsou informace v dokumentu sdělovány cílovému čtenáři dostatečně srozumitelně? Rozumí všichni zúčastnění dokumentu stejně? Neodnesl si každý jinou informaci?
Statické testování dokumentace je vhodné všude tam, kde je dokumentace zásadní pro úspěch projektu. Testování by mělo probíhat na obou úrovních – na úrovni obsahu i na úrovni formy. Pro jednotlivé dokumenty doporučuji nejdříve chyby identifikovat a až následně (po projití celého dokumentu) je řešit. Tento postup ušetří mnoho času autorovi i posuzovateli dokumentu.
6.2 Statické testování kódu Pro statické testování zdrojového kódu platí podobné principy jako pro jakýkoliv dokument vzniklý během projektu. Na rozdíl od statického testování obecných dokumentů existuje při statickém testování kódu více pravidel a metrik, které můžeme považovat za obecně platné a často je můžeme automaticky měřit a vyhodnocovat. Kromě okamžitého přínosu v podobě odstraněných chyb má statické testování kódu i další přímý přínos pro následné dynamické testování. Díky statickému testová-
Statické testování
99 Ukázka elektronické knihy, UID: KOS227969
ní kódu (a následným opravám) je totiž možné vytvořit snáze udržovatelný a testovatelný zdrojový kód aplikace. Snazší udržovatelnost a testovatelnost vychází z dobrého návrhu architektury softwaru a z čitelného kódu, který je srozumitelný jak programátorovi, tak testerovi. V této kapitole budeme používat termín „kvalita zdrojového kódu“ v kontextu statického testování, nikoliv z pohledu správnosti kódu vzhledem ke specifikaci požadavků. Dobrý kód musí být pochopitelně správný z pohledu obou těchto kvalitativních kategorií. Kvalitní kód vývojář ocení zejména v situacích, kdy je třeba rychle opravit chybu v kódu, přidat novou funkcionalitu, nebo když došlo ke změně v programátorském týmu a na změnách kódu má začít pracovat někdo nový. V těchto situacích je nekvalitní kód překážkou, která může zásadně znesnadnit (a tím pádem i prodražit) další rozvoj aplikace. Testování kódu také probíhá na úrovni obsahu a formy. V rámci kontroly obsahu se zaměřujeme na programátorské umění (angl. craftmanship): jak robustní, odolný a efektivní kód programátoři dodávají. V rámci kontroly formy se zaměřujeme na přehlednost a čistotu kódu. V případě zdrojových kódů platí, že kvalita obsahu a formy jsou spolu velmi provázané. V mnoha současných vývojářských nástrojích (IDE) jsou přítomna rozšíření, které napomáhají psát dobrý kód, ale to nás nezbavuje nutnosti kód testovat. Základním prvkem statického testování kódu je analýza kódu. Aby měla tato analýza smysl, musí být jasně definováno, čeho má být při psaní kódu dosaženo: jaké formální náležitosti a postupy mají být splněny (tzv. coding standards) a jaké charakteristiky obsahu jsou pro aktuální projekt prioritní a jaké ne. Může se stát, že některé charakteristiky mohou jít proti sobě a je nutné vědět, kterou z nich upřednostnit.
6.2.1 Co je kvalitní kód Je velmi těžké definovat kvalitní kód tak, aby tato definice univerzálně obstála v kontextu všech programovacích jazyků, různých zadání a požadavků. Proto musíme kvalitu kódu vždy vztahovat ke konkrétním cílům, kterých chceme dosáhnout. Těmi můžou být například [3]: ▞▞
▞▞
▞▞
Udržitelnost a rozšiřitelnost: Tento cíl stanovíme, pokud předpokládáme, že celou aplikaci budeme nějakou dobu muset udržet na trhu. Je pravděpodobné, že se objeví nějaké drobné chyby, které bude třeba opravit, nebo bude nutné přidat nějakou funkcionalitu. Vznikající kód se bude v budoucnu rozvíjet a měnit. Nejspíš se bude měnit i tým lidí, kteří kód vytvořili. Proto chceme mít kód dobře čitelný a srozumitelný, aby – až se k němu vrátíme a budeme ho chtít upravit – toto bylo možné a nebylo levnější celý kód napsat znovu. Výkonová optimálnost: Podmínky, v jakých se bude vznikající aplikace používat, vyžadují maximální rychlost nebo optimální práci s pamětí. V takovém případě musíme kód přizpůsobit těmto požadavkům, což může být někdy v rozporu s požadavkem na srozumitelnost a udržovatelnost. Testovatelnost: Při psaní kódu je nutné myslet na to, aby se kód „sám nebránil“ testování. Proto je třeba volit vhodnou architekturu aplikace a organizaci jednotlivých kusů kódu tak, abychom si při testování usnadnili práci, nebo aby bylo testování vůbec proveditelné. Příkladem může být testování metody, která v sobě soustředí funkčnost z mnoha různých oblastí (tvorba uživatelského rozhraní, tvorba a provedení dotazu do databáze, další business logika). Otestovat takovou metodu je většinou náročnější než testovat menší metody pokrývající vždy jen logicky vymezenou část funkcionality.
Jednotlivé cíle nemusí být nutně v rozporu, ale velmi často musíme volit pro jejich vyvážení kompromis. Jak jsme již zmínili výše, obecnou kvalitu kódu je těžké definovat. Proto se častěji používá definice negativní – tedy výčet jevů, které jsou považovány za nežádoucí (viz např. [3, 4]). Výskyt těchto jevů je nutné považovat za chyby a je vhodné kód proti nim testovat. Samozřejmě nejlepší je naučit programátory vyvarovat se těchto chyb. Mezi nežádoucí jevy v kódu patří například: ▞▞ ▞▞
Nevhodný návrh vede k tomu, že kód není srozumitelný, nebo je těžké ho testovat například kvůli nemožnosti efektivně simulovat některé části kódu pro testovací účely. Nesoulad s rozhraními podle specifikace může být zaviněn buď tak, že kód dělá něco jiného, než říká specifikace, nebo došlo k rozšíření rozhraní nad rámec specifikace. Jedná se o častý problém nesouladu specifikace a kódu, který vede k chybám v programu (nebo při komunikaci s programem).
100
Efektivní testování softwaru
Ukázka elektronické knihy, UID: KOS227969