Testování GUI - malé nakousnutí velkého tématu
  

Uvědomil jsem si, že jsem tu zcela opominul poměrně zásadní téma a tím je testování GUI. Dnes ho tedy alespoň naťukneme. Hned na úvod bychom si měli říct, že naprostá většina funkčních testů mám podobu GUI testování. Taky bychom si ale měli přiznat, že testování GUI obvykle jinak chápe vývojový tým a jinak zákazník.

Asi nemá cenu tu řešit, co to vlastně GUI je. Úplně stručně - je to forma uživatelského rozhraní, díky kterému může uživatel aplikaci ovládat a zároveň skrze něj vidí výstupy aplikace. Písmeno G tu říká, že to má nějakou grafickou podobu, tedy že aplikace má nějaké obrazovky, formuláře, tlačítka a tak podobně.

Abychom se uvedli ještě trochu víc do problému, měli bychom si říct, že GUI je obvykle součástí vícevrstvé architektury aplikace. Nejspodnější vrstvu tvoří databáze nebo jiné úložiště dat, prostřední vrstva se označuje jako aplikační a obsahuje většinu logiky aplikace a nejvýše je právě GUI, jehož úkolem je zprostředkovat kontakt mezi uživatelem a nižšími vrstvami.

Když se tedy mluví o testování GUI, myslí se tím testování aplikace v podobě, v jaké s ní bude pracovat uživatel. Mělo by být ale jasno v tom, že to není jediný způsob jak takovou aplikaci testovat. Je samozřejmě možné otestovat aplikační logiku, skrývající se v prostřední vrstvě, napřímo a to například whitebox testovacími technikami.

Testování GUI má mnoho úkolů. Tím nejzákladnějším je samozřejmě zjištění, zda aplikace funguje tak jak má. Tedy, že všechny výpočty, práce s daty a algoritmy pracují dle očekávání. Tato část GUI testování je jednou z mála, kterou lze (alespoň do určité míry) automatizovat. Existuje celá řada nástrojů, které umožňují simulovat klikání do aplikace. Já tu v jiném článku uváděl jako příklad takového nástroje Selenium, ale existuje jich mnohem víc. V těchto testech se soutředíme skutečně na samotnou podstatu fungování aplikace. Proto je použití podobných nástrojů smysluplné. Jsou tu jednoznačné vstupy a očekávané výstupy.

Asi je zřejmé, že tyto testy se vlastně zaměřují na testování aplikační logiky a GUI slouží spíše jako "testovací nástroj". Je zde nutné vzít v úvahu, že samotná funkce tohoto "nástroje" nebyla ještě otestována a může se tak stát, že případný rozdíl výstupu reálného a očekávaného může nastat jak chybou v logice tak chybou v zobrazení tohoto výstupu na GUI.

Další testy se zaměřují více (nebo téměř výhradně) na samotné GUI. Jak už bylo řečeno, GUI zprostředkovává komunikaci aplikace s uživatelem. To znamená, že zobrazuje ovládací prvky, formuláře a výstupy. Testy se musí zaměřit na to, že jsou zobrazeny všechny očekávané formuláře, tlačítka, linky a výstupy. Testuje se, že formuláře obsahují všechna požadovaná pole a že nad těmito poli fungují požadované validace (povinná pole, formát atd.). U těchto testů je nutné vzít v úvahu například různé chování aplikace pro různé role uživatelů, nebo třeba odlišné zobrazování aplikace v různých fázích zpracování (pokud například obsahuje nějakou formu workflow). Pro testera je ideální, pokud analýza obsahuje kromě popisu chování aplikace také grafický návrh jednotlivých obrazovek, formulářů, výstupů.

Součástí testování GUI jsou i testy, které se označují jako testování použitelnosti. Zde prakticky opouštíme oblast jasně definovaných požadavků a měřitelných ukazatelů. Samotné testování použitelnosti je téma na samostatný článek (možná sérii článků) a já se k němu určitě brzy vrátím. Teď si jen ve stručnosti řekneme, že vedle samotné funkčnosti aplikace je důležité i to, aby byla pro uživatele přívětivá, přehledná, zkrátka aby ji uživatel chtěl používat. Tato oblast je poměrně komplikovaná a složitá. Samozřejmě naprogramovat lze leccos a tester už z podstaty své role dokáže prakticky cokoli otestovat. Ale uživatel a tedy zákazník nemusí být ochotný výslednou aplikaci používat. Samozřejmě je tu velké téma k úvaze, kdo a kdy má definovat to, ja má vlastně aplikace vypadat, jak se má ovládat. Je to určitě na analyticích, ale upřímně řečeno zákazník obvykle není schopen jasně definovat své požadavky v této oblasti. Zatímco požadavky na funkce aplikace se celkem daří vydefinovat, v oblasti ovládání aplikace má zákazník obvykle jen obecnou představu a doufá, že dodavatel má tolik zkušeností, že zkrátka něco vymyslí. Zde pramení mnoho problémů.

A tím se dostáváme k jednomu z klíčových témat testování GUI. Zákazník totiž ke GUI přistupuje poněkud jinak než vývojáři. Zatím co vývojáři vnímají GUI jako něco, co jen prezentuje samotnou práci aplikace a hlavní je tedy logika schovaná pod ním, zákazník má GUI na prvním místě. Pokud si zákazník organizuje svoje testy aplikace před její akceptací, pak je téměř jisté, že první hlášené chyby se budou týkat GUI a že v celkovém objemu nalezených chyb bude právě GUI chyb většina. Také hodnocení závažnosti těchto chyb bude mít zákazník zcela jiné než dodavatel. Bude se tak stávat, že GUI chyby budou mít zákazníkem nastavenou nejvyšší pririoritu.

Zákazník aplikaci platí a proto je v pořádku, že ji hodnotí ze svého pohledu. Pro vývojový tým je tak nutné si uvědomit, že otázky okolo GUI není vhodné odsouvat a je nutné podobu GUI a jeho řešení se zákazníkem probírat v průběhu celého vývoje. Jen tím se dá částečně odstranit možné překvapení zákazníka, když poprvé dostane aplikaci do rukou. I tak se ale nedá vyhnout tradičním chybám typu požadavku na jinou barvu nadpisů, zvětšení písma v menu atd.

Testování GUI má ještě jednu podobu, kterou není vhodné zanedbávat. Jde o testování kompatibility. Jde o testy, které ověří, že aplikace funguje korektně i na jiných prostředích, než je výchozí. Lidsky řečeno, například u webových aplikací je dobré otestovat, jestli fungují správně i na jiných prohlížečích a jiných verzích výchozího prohlížeče, pro který byla vyvinuta. Samozřejmě je nutné brát v úvahu požadavky zákazníka. Ten musí být schopen říct, na jakých prostředích chce aplikaci provozovat. Buď to řekne konkrétně (to je obvyklé u interních aplikací, kdy zákazník přesně ví, jaké prostředí má k dispozici a jaký případný upgrade plánuje) nebo obecně (například aplikace má podporovat tři nejrozšířenější webové prohlížeče ve dvou posledních verzích). Testy kompatibility je třeba dobře naplánovat, protože při široké definici podporovaných prostředí to může znamenat podstatný nárůst testů.

 

Nejbližší události


Testování software, Powered by Joomla!; Joomla templates by SG web hosting