{jcomments on}Pokud je analýza vyvíjené aplikace psána v podobě případů užití (UseCase), pak tester při přípravě testů samozřejmě z těchto případů vychází. A nejen to. Testy, které jsou na dané aplikaci prováděné, musí existující případy užití pokrývat a zaručit tak, že reálné chování aplikace odpovídá chování, které navrhl analytik.

Nejsem si zcela jist, jak moc se tu mám nořit do teorie Případů užití. Ale minimálně něco si k ní říct musíme. Usecase je jedna z možností jak přetvořit požadavky zákazníka do podoby analýzy. Princip, jakým jsou případy užití vytvářeny je v určitém ohledu podobný vytváření testů a právě proto je tato podoba analýzy vhodným podkladem pro tvorbu testovací dokumentace.

Pokud analytik vytváří případy užití, snaží se budoucí aplikaci rozdělit na malé funkční bloky, které pak svým propojením vytvářejí celou aplikaci. Slovo funkční tu není úplně na místě, protože nejde o rozdělení na základě funkcí z hlediska technického (myšleno reálné funkce v kódu aplikace). Pohled analytika je zde výrazně uživatelský. Jeho úkolem je zmapovat způsob, jakým chce uživatel budoucí aplikaci používat a na základě těchto informací vytvořit jakési modelové situace. Ještě lépe se dá říct, že jde o scénáře. Každý případ užití má svojí danou strukturu a prvky, ze kterých se skládá.

Hybatelem děje případu užití je Aktér (nebo aktéři), který je tím, kdo vykonává činnost a má právo k danému případu užití přistupovat (tedy je to typ uživatele, který bude danou funkčnost reálně využívat a má mít právo ji využívat, typicky rozdíl mezi administrátorem a běžným uživatelem). Je samozřejmě nutné odlišovat aktéra a uživatele. Aktér je zkrátka objekt, který je vně dané aplikace a zastupuje určitou roli, kterou reálný uživatel může v aplikaci zastávat. Jeden uživatel může pochopitelně v aplikaci vystupovat ve více rolích, aktér ale zastupuje vždy jednu konkrétní roli. A aby toho nebylo dost, k jednomu případu užití může přistupovat více jak jeden aktér.

Aktér chce v daném případu užití dosáhnout nějakého cíle. Aby ho dosáhl musí projít určitou řadou kroků, které můžeme označit za scénář. Jde o pozitivní průběh, ve kterém se předpokládá, že vše probíhá bez chyb. Tento hlavní scénář je možné rozšířit o další průběhy. Jde přitom stále o stejný případ užití. Řeší se tak situace, kdy v daném případu užití existuje více jak jeden průběh, který vede ke splnění cílů aktérů. Jde tedy stále o pozitivní průběhy.

Případ užití může řešit i negativní průběhy. Obvykle je to řešeno formou Rozšíření (Extension), které stejnou formou jako pozitivní scénáře řeší možné chybové stavy.

každý UseCase má nějaké vstupní podmínky, které musí být splněny, aby ho bylo možné provést. Tyto podmínky mohou mít buď "vnější" podobu (například existence aktéra, jeho přihlášení do aplikace atd.) nebo mohou vycházet z jiného případu užití. Dochází tak ke spojování případů užití, kdy výstup z jednoho se stává vstupní podmínkou pro spuštění dalšího. Případ využití mohou být i vnořeny do sebe. To je využíváno tehdy, kdy určitá část jednoho případu užití odpovídá chování jiného existujícího případu užití.  Typickým příkladem je logování do aplikace. Jako samostatný scénář je zachyceno v příslušném případu užití. Ovšem logování je součástí i jiných případů užití. Aby v nich nemusel být popsán znovu celý postup, je možné případ užití logování vnořit do dalších případů užití.

Případy užití je možné psát a znázorňovat různými způsoby. Dobře využitelný je pro tyto účely jazyk UML. Já osobně musím říct, že přestože jsou pro mě případy užití v UML asi nejpoužitelnější, na formě, v jaké jsou vytvořeny vlastně až tak moc nezáleží. Podstatný je obsah. A tím se dostáváme k tomu, jaký dopad mají případy užití na přípravu testů.

Pokud jsou případy užití připraveny kvalitně, pak analytik odvedl část práce za testera. Tedy ne zase až tak velký, jak si někdy analytici myslí. Ale musím říct, že dobře popsané pozitivní a negativní průběhy a dobře popsané vstupné podmínky jsou ideálním výchozím bodem pro test analýzu. Je ale nutné si uvědomit, že tester a analytik mají na vyvíjenou aplikaci trochu jiný pohled a proto není možné vzít pouze případy užití a prohlásit je za testovací dokumentaci.

Analytik jde především po hlavní funkci aplikace. Jeho úkolem je především zachytit požadavky zákazníka a přetvořit je do techničtější podoby. Soustředí se tak na trochu jiné stránky aplikace než následně tester. Ale řekněme si jasně, pozitivní průběh si tester sám nevymyslí. Při přípravě testů pozitivních průběhu vychází skoro výhradně z případů užití (které samozřejmě může v rámci zaměření se na větší detail rozpracovat na více testů než odpovídá pozitivním průběhům v analýze). U negativních průběhů je situace trochu jiná. Analytik nemusí postihnout všechny situace, které mohou v daném případu užití nastat. To se obvykle týká validací vstupů. Analytik může tuto záležitost řešit buď obecně (jeden negativní průběh pro nevalidní vstup) nebo vůbec s tím, že jako podmínku spuštění případu užití definuje validní vstup. Tady nastupují další techniky testování (některé jsou tu už popsané) aby testování pokrylo všechny eventuality.

Když si zkusíme napsat jednoduchou kuchařku jak připravit testy na základě případu užití bude vypadat asi nějak takhle:

1. testy musí pokrývat každého aktéra, který v případu užití vystupuje

2. pro každý průběh (pozitivní, negativní) bude existovat minimálně jeden test

3. vstupní podmínky případu užití jsou zároveň vstupními podmínkami testů

4. na případ užití je nutné nahlížet i z pohledu jiných technik testování, pro pokrytí dalších průběhů (pozitivních negativních), které nejsou v analýze zachyceny. Kromě testování nesmyslných hodnot, prázdných hodnot apod. jde například o testování rozhodování (bude tu samostatný článek) atd. 

Obecně se dá říct, že testování založené na případech užití je dobrá cesta. Ovšem musí být dostatečně kvalitní analýza a musí fungovat komunikace mezi testerem a analytikem.