Testujeme s rozumem (2.) – Jak z UC získat TC

Při přípravě na testování projektu je zapotřebí vytvořit scénáře (postupy), které budou testeři procházet při testování. Scénáře by v optimálním případě měly pokrývat případy užití, pro které je aplikace vyvíjena. Máme-li rozumně zpracovanou analýzu, může být získání těchto scénářů relativně snadné.

Tyto scénáře testů nazýváme „testovanými scénáři“, anglicky test case, zkratkou TC. Co je to TC? Co by měl obsahovat? TC je soubor vstupů, kroků i podmínek a očekávaných výstupů. Ale kde ho vezmeme?

Každá analýza vyvíjeného systému by měla obsahovat případy užití (use cases), dále UC. Tyto scénáře užití lze s výhodou použít pro vytvoření seznamu TC. Jak na to? Ukážeme si na následujícím příkladu.

Nyní máme zpracovaný zcela jednoduchý UC, kde máme základní průchod aplikací. Bohužel svět není jednoduchý a ani náš příklad nemůže být takto jednoduchý. Je zapotřebí se zamyslet a definovat další toky, kterými může tento scénář být přerušen, či pokračovat zcela jinou cestu. Jedná se o tzv. Alternate flows.

Nyní si sepíšeme do tabulky pod sebe všechny možné scénáře, a pojmenujeme si je. Pojmenování volte rozumně, neboť by se mělo používat skrze celé testování.

Teď již máme identifikovány hlavní scénáře, které budeme potřebovat otestovat. Pro vlastní testování však toto ještě nestačí. Musíme definovat vstupy a očekávané výstupy jednotlivých TC. Vstupy lze identifikovat dle rozhodovacích bloků v UC. Každé alternative flow by mělo být způsobeno nějakou příčinou, vstupem. V našem případě máme situaci poněkud zjednodušenou. V reálných systémech jsou i desítky vstupů. Zde lze s výhodou použít excel, či vhodný TC management nástroj.

V našem případě dochází k startu alternate flow 3 v scénáři č.4: Datum splatnosti v minulosti.
Je tedy evidentní, že v tomto scénáři se rozhodne o provedení alternativního scénáře v bodě 6. Tudíž je zapotřebí zadat číslo faktury, částku a datum splatnosti. Číslo faktury a částka je validní a datum splatnosti je neplatné (Invalid). Další vstupy jsou již pro tento scénář irelevantní a v tabulce se neobjeví.

Nyní vyplňme tabulku. „V“ představuje potřebný validní vstup a „I“ invalidní vstup. Pokud na vstupech nezáleží nebo jsou irelevantní, zanechte příslušné buňku tabulky prázdnou. Názvy jednotlivých TC volíme ve sloupci TC ID# tak, aby odpovídaly testovanému scénáři. V našem případě jde o evidenci faktury, zvolil jsem tedy zkratku IE (Invoice Evidence). V případě velkých systémů nám toto pojmenování pomůže v orientaci.

Nyní máme tabulku validních a nevalidních vstupů. Víme, na kterých vstupech záleží úspěšnost dané operace. Připravíme si testovací prostředí tak, abychom mohli splnit tyto scénáře. Dost často mají UC tzv. preconditions. Tyto precondititons například říkají, že uživatel, který chce založit jiného uživatele, musí mít administrátorská práva. Musíte tedy do systému před začátkem testovaní založit uživatele s administrátorskými právy.
Na základě takto připraveného testovacího prostředí jste již schopni definovat konkrétní tabulku s konkrétními vstupy.
V našem případě vypadá například takto. Pokud používáte excel, doplňte si tabulku o sloupce precondition a postconditions. Tam definujte, co je zapotřebí udělat před spuštěním testu a zároveň co má tester udělat po ukončení testu. (například po sobě v aplikaci uklidit).

Dost často na svých školeních se setkávám s názorem, že tento postup je příliš přebyrokratizovaný a prý zdržuje. Praxe ovšem ukazuje, že problémem není vyplnění tabulky, ale neochota některých (test) analytiků se dopředu zamyslet a definovat tyto scénáře a vstupy. Pokud se ovšem nechcete smířit s intuitivním testováním a postoupit například až k objektivnímu měření kvality, zavedení podobných pravidel vás nejspíše nemine.

Pozorný čtenář teď zareaguje: Vždyť v těch TC nemám přeci kroky, jak mám postupovat? Tehdy ale nehledáme artefakt TC ale Test Script. Čili postup, kterým bude tester postupovat při ověřování konkrétního testovaného případu. Test Scripty psát je časově náročné a mnohdy se musí s měnící aplikací znovu přepisovat. Proč je tedy píšeme?

Rozdíl mezi TC a Test Script je v době jejich vzniku a v tom, kdo tyto artefakty vytváří. Zatímco k definici TC dochází na začátku projektu a provádí je test analytik (dosti často i analytik projektu), tak Test Scripty si píší sami testeři.

Oblast okolo názvů, tvorby TC a organizace práce je natolik rozsáhlá, že by vydala na několik článků. Pokud máme menší projekty a sdílené role, potřebujeme relativně malý aparát. Pokud ovšem projekt přerůstá určitou hranici, je zapotřebí zvolit adekvátní metody přístupu k testování.

Předchozí díl: Úvod seriálu