Zdeněk Jonáš
2.11.2009

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 obsahovpat 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.

Představte si jednoduchý systémový UC na evidenci vydané faktury v nějakém systému. Daný uživatel má právo zadávat faktury pouze do 100 tisíc.

Basic Flow

  • 1. Uživatel zadá číslo faktury.
  • 2. Systém provede kontrolu čísla faktury.
  • 3. Uživatel vyplní fakturovanou částku.
  • 4. Systém provede kontrolu výše částky.
  • 5. Uživatel vyplní datum splatnosti.
  • 6. Systém provede kontrolu data splatnosti.
  • 7. Systém vytvoří fakturu a podá uživateli zprávu o jejím úspěšném zaevidování.


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.

Alternate flow 1

Faktura v systému již existuje, nelze přidat.

  • Basic Flow v bodě 2. Systém podá uživateli zprávu o existenci faktury tohoto čísla a UC se tímto ukončí (faktura se nevytvoří).

Alternate flow 2

Co když částka na faktuře přesáhne hodnotu 100 tis Kč?

  • Basic Flow v bodě 4. Systém podá uživateli zprávu o převýšení maximální hodnoty faktury a UC se tímto ukončí (faktura se nevytvoří).

Alternate flow 3

Co když zadáme datum splatnosti v minulosti?

  • Basic Flow v bodě 6. Systém podá uživateli zprávu o špatné hodnotě data splatnosti a UC se tímto ukončí (faktura se nevytvoří).

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í.

Sestavení a pojmenování scénářů

Scénář 1 – založení faktury Basic Flow  
Scénář 2 – faktura tohoto čísla již v systému existuje Basic Flow Alternate flow 1
Scénář 3 – částka vyšší než 100 tisíc Basic Flow Alternate flow 2
Scénář 4 – datum splatnosti v minulosti Basic Flow Alternate flow 3


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.

TC ID# Scénář číslo faktury částka datum splatnosti Očekávaný výsledek
IE 1 Scénář 1 – založení faktury V V V Faktura úspěšně založena
IE 2 Scénář 2 – faktura tohoto čísla již v systému existuje I     Faktura nezaložena, uživatel informován.
IE 3 Scénář 3 – částka vyšší než 100 tisíc V I   Faktura nezaložena, uživatel informován.
IE 4 Scénář 4 – datum splatnosti v minulosti V V I Faktura nezaložena, uživatel informován.



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).

TC ID# Scénář číslo faktury částka datum splatnosti Očekávaný výsledek
IE 1 Scénář 1 – založení faktury 20 45 000 15.1.2010 Faktura úspěšně založena
IE 2 Scénář 2 – faktura tohoto čísla již v systému existuje 20     Faktura nezaložena, uživatel informován.
IE 3 Scénář 3 – částka vyšší než 100 tisíc 21 150 000   Faktura nezaložena, uživatel informován.
IE 4 Scénář 4 – datum splatnosti v minulosti 22 23 000 11.9.2001 Faktura nezaložena, uživatel informován.



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

Vaše emailová adresa nebude zveřejněna

Komentáře

Děkujeme za váš komentář
Další
  • Michal Škrdla

    Zdenku, pri testovani je take vhodne osetrit okrajove podminky.. napriklad zadani zaporne castky (u faktury by nemelo nastat, jednalo by se o dobropis ;-)) zadani neplatneho data (napriklad 29.2.2009) nebo treba i platneho ktere je necim vyznamne 29.2.2008 (nekteri bastlici kontroluji, zda ma v unoru zadas max 28. den) tudiz tech variaci na IE3 ci IE4 by melo byt mnohonasobne vic M.

  • To jo, ale byl by pak ten příklad ještě srozumitelný?

  • Ahoj Michale. Při testování této aplikace, by se toho muselo testovat daleko více. Hledal jsem příklad, který bude natolik jednoduchý aby demonstroval ten postup. Těch řádků a kombinací by tam mělo být daleko více. Pokud je datum spatnosti například špatně zadáno, tak aplikace by asi pouze vyhodila hlášku a uživatel by to zadal znovu. Atd. atd.

  • uf

    Take jsem cetl Cockburna a neco o testovani. Bohuzel, zatim musim testovat rucickama, jen neco malo automaticky. Clanek v podstate rika to, co si prectete v takovychto clancich - omlouvam se autorovi, ale cekal jsem vic. Prinosem je zdurazneni, ze je treba vypsat minimalne seznam testovacich variant a postup. I kdyz clovek testuje rucickama, ne vzdy udela stejnou nebo zadanou vec. Mam zajimave zkusenosti s testovanim: - jako autor programu zadavam vstup podle ocekavaneho chovani (rekneme mnou ocekavaneho) uzivatele. Pak testuje nekdo jiny a prvnim sahnutim program zboura. - zajimave bylo i nedorozuměni, kdy jsme nemohli nasimulovat chybu podle testeru. Nakonec se ukazalo, ze po formulari behaji v jednom miste jinak nez my - podle nas neocekavane, podle nich prirozene. Co je ale prirozene? - zakladni testy aplikace je potreba automatizovat, a to i v GUI. Skoda, ze pro nedostatek casu a inteligence jsem to zatim jen zkousel. Alespon prihlaseni do aplikace a volbu akce v menu - to me fakt drasa.

  • re: Uf. Tohle téma je asi nejčastěji omílané a známé. Nic méně, pokud chci vytvořit seriál o tom, jak postupně testovat, rozhodl jsem se ho zde uvést. Seriál by pak nebyl kompletní. Ohledně automatizovaného testování. Například webové aplikace testuji pomocí selenia, kde si scripty vyexportuju do JUnit, udělám si datový model, který z části koresponduje s doménovým modelem, vytvořím si metody pro generování dat a s těmi poté pracuji. Nakonec si to po sobě uklidím. (pokud to jde). O tomhle ale někdy příště.

  • uf

    @Zdenek: Jasne, tesim se na dalsi dily. Vsak se omlouvam. Sam jsem vytvoril tutorial, ale je v sufliku, protoze popisovane postupy a zdrojak bude muset byt udelan spravne, elegantneji a poradne. Obdivuji kazdeho, kdo si najde cas, aby neco napsal - vetsinou za tim je vic prace nez to jen namastit do masiny. Ale jsem dost citlivy na lidi, kteri publikuji proto, aby ze sebe udelali osobnost internetu.

  • Fany

    Hezky napsany clanek a vlastne popisuje idealni svet. Realita bohuzel byva diky terminum dodani aplikace trosku nekde jinde a to je skoda.

  • @Fany. Času je vždy málo. Jsou dvě možnosti co se s tím dá dělat. Jednak je zapotřebí začít s testováním co nejdříve, takže již během programování provádět tuto přípravu. Pokud ani toto neprojde a testera nedostanete do projektu dříve než v závěrečné fázi, snažil bych se převést tyto úkoly do fáze analýzy a na analytiky. Mohou provést některé tyto kroky za vás.

  • Fany

    Jeste bych mel "pripominku" k tem kontrolam. Nikdy jsem se nesetkal, aby v UC byly primo napsany castky, napr. tech 100000. Vetsinou se pise o nejakem limitu. Castky a ostatni validace vetsinou upresnuje dalsi dokument. Ja osobne pisi TC, tak aby byly "univerzalni". Takze do nich nezapisuju primo hodnoty jake ma tester zadat, ale napr.: zadej castku vetsi nez povoleny limit, a do poznamky v TC tester zapise jake cislo zadal. Verifikace a limity se casto meni ikdyz funkcnost zustava stejna a prochazet velke mnozstvi TC kvuli nove verzi formatu a verifikaci se mi zda neefektivni

  • Fany: Co se týče UC, tam lze jedině souhlasit, ale co se týče TC, tam jsem na pochybách - zajímalo by mě co k tomu napíše Zdeněk. Čísla do TC se často volí tak, aby byla na okraji definičních oborů, takže by se IMO měla do TC výslovně uvádět. Ten kdo test provádí totiž nemusí být tak kvalifikovaný jako ten kdo je sestavoval.

  • @Fany. Zkusím na to odpovědět. Ohledně čísel, je možné použít buďto intervaly třídy ekvivalence nebo přímo hodnoty. Hodnoty jsou lepší pro měření testování, neboť z intervalu nejste téměř nikdy schopen otestovat všechny varianty. Kdežto pokud vyberete z třídy ekvivalence vhodný reprezentativní prvek, máte otestováno. Neuvedete-li hodnotu přesně a práci vykonává tester, který nemá potřebné znalosti o systému, může strávit nekontrolovatelně hodně času tím, že testuje ekvivaletní případy a na některé může zapomenout. Genericky je v hodné psát test scripty, čili konkrétní postupy při testech. Ty je potom možné parametrizovat hodnotami přímo z TC. Rovněž tester nemusí vždy být schopen definovat hraniční podmínky a zvolit vhodné hodnoty. viz Richard. Vždy záleží na velikosti daného produktu. Pokud produkt testuji sám, nevypisuji si hodnoty, ale postačí mi pouze vydefinovat si scénáře a zbytek otestuji. Pokud ovšem mám na projektu, který trvá dva roky řídit 10 testerů, potřebuji takovýto aparát k tomu, abych byl schopen uřídit proces testování.

  • Fany

    Diky za odpovedi, rozhodne to dava smysl. Ono je to spise o tech zkusenostech :-) jaky pouzivate nastroj pro test management?

  • @Fany. Vhodný TC management nástroj ještě pořád hledáme. Na některé projekty jsme používali TestLink.