Metodiky testování - úvod
Hodnocení uživatelů: / 0
NejhoršíNejlepší 

Dnes bych se tu chtěl poněkud obecněji podívat na metodiky testování. Tedy spíše na to, co to vlastně metodika je a co má společného s testováním.

 

Slovo metodika ve své podstatě označuje nějaký pracovní postup, způsob provádění nějaké činnosti a je logické, že i v testování existují metodiky. Už jsme tu ale uvedl v jiném článku skutečnost, že testování není solitér, vždy je součástí nějakého procesu, jehož úkolem je vývoj softwaru. Proto pokud se mluví o metodikách testování, z velké části se tím myslí metodika vývoje softwaru, jejíž součástí je i testování.

Úkolem metodiky, zcela jednoduše řečeno, je vytvořit rámec, v němž jsou definovány jednotlivé činnosti, jejich návaznosti a přesahy, zodpovědnosti (v obecné rovině rolí), metodika může obsahovat také šablony dokumentů, které mají být výstupem z jednotlivých fází (pokud samozřejmě takové dokumenty existují). Metodika tak tvoří jakousi mapu nebo návod, který měl být schopen říct každému "účastníkovi" procesu vývoje co je jeho úkolem, co musí být splněno, aby mohl zahájit svou "činnost", jaký je její očekávaný výstup a komu má být předán. 

Metodiky vývoje softwaru jsou v obecné podobě součástí výuky na (snad) většině škol zaměřených na IT. Proto si tu dovolím jen stručný průlet těmi nejzákladnějšími typy. V dalších článcích se budu podrobněji věnovat metodikám, které jsou reálně používané v praxi.

Kaskádový přístup

Jde o nejznámější metodiku, kterou si zřejmě vybaví každý, kdo se okolo tohoto tématu aspoň mihnul. Základnám principem této metodiky je postupné navazování jednotlivých fází vývoje, přičemž každá další fáze začíná v okamžiku, kdy ta předcházející skončí. Nejobvyklejší fáze vývoje softwaru můžeme sepsat do následujícího seznamu: Sběr dat, Analýza, Vývoj, Testování. Každá z těchto fází navazuje na tu předcházející a využívá výstupy z ní. Testování tedy začíná až v okamžiku, kdy je dokončen Vývoj aplikace.

V této metodice je možný pohyb pouze kupředu, lépe řečeno ze shora dolů. Z žádné fáze není možné se vrátit zpět. Pokud v dané fázi byly vykonány všechny činnosti, které vykonány být měly, a byly dodány všechny požadované výstupy, považuje se tato fáze za úspěšně ukončenou.

Tato metodika se může na první pohled jevit jako snadno použitelná a především odpovídající skutečnému postupu vývoje. Navíc umožňuje snadnější plánování zdrojů i termínů. Díky rozsáhlé dokumentaci, kterou tato metodika předpokládá, se zdá, že i kontrola správnosti vývoje musí být relativně snadná.

Problémem této metodiky je velká těžkopádnost (teoretici v systémovém inženýrství by řekli nepružnost). Je jako rozjetý vlak, který se v případě problémů těžko koriguje. Tato metodika je v podstatě nastavena na bezproblémový průchod. Problémů ale může nastat celá řada. Díky návaznosti fází se může například projevit efekt "tiché pošty". Každá fáze pracuje s výstupy fáze předcházející a musí předpokládat, že tyto výstupy jsou správné. Přestože tato metodika podporuje kontrolní mechanismy právě na úrovni přechodů mezi fázemi, tyto kontroly jsou díky povaze metodiky spíše zaměřené na formální stránku věci. Chyba vzniklá v jedné z fází se může přes tuto kontrolu dostat a tím "infikovat" zbytek vývoje. Chybí komplexnější pohled na celý proces vývoje. 

Velkým problémem této metodiky je fakt, že funguje jako jakýsi uzavřený systém. Zákazník do něj na jedné straně vloží své požadavky a na druhé straně získá hotovou aplikaci. Pokud své požadavky nespecifikoval dostatečně přesně, nebo na některé zapomněl, pak výsledná aplikace neodpovídá tomu, co očekával. Celý proces vývoje v tuto chvíli musí začít znovu. Podobně je tomu v okamžiku, kdy zákazník začne svoje požadavky modifikovat tehdy, kdy vývoj již opustil fázi sběru požadavků. Díky nepružnosti metodiky dochází v takové situaci k "zahození" dosavadních výsledků a proces začíná od začátku.

Z pohledu testování je nepříjemné, že se zde předpokládá testování až kompletně vyvinuté aplikace. Testování tu plní spíše úlohu ověření, že výsledek je správně, než jako garant kvality. 

Kaskádový přístup rozhodně není ideální, ani zdaleka. Ale poskytuje jakýsi základ pro mnoho dalších metodik. 

Iterativní přístup

Jak už to v IT bývá, při problémech jedné verze přichází jiná, která tyto problémy řeší. To je případ iterativního přístupu. Ten je postaven právě na tom, v čem kaskádový přístup selhává. Vyvíjená aplikace je rozdělena na menší části. Každá tato část se vyvíjí jako samostatný proces se všemi fázemi, které vývoj předpokládá, tedy analýzou, programováním a testováním. Proces vývoje těchto jednotlivých částí je tak mnohem kratší než vývoje aplikace jako celku. Mnohem dříve je tak na reálném výstupu možné ověřovat, zda odpovídá očekávání. Při problémech a chybách je možné tento krátký proces snadněji zopakovat a vývoj tak probíhá v jakýchsi cyklech. Na konci každého cyklu je informace, zda je výsledek správný.

Obvyklým postupem u iterativního přístupu je "nabalování" funkčností. Tedy začíná se od nějaké malé části, probíhá její vývoj až do fáze, kdy je "správně" vyvinuta a v ten moment se přidává další část a takto se pokračuje dále.

Z hlediska testování je to samozřejmě lepší přístup než kaskáda. Je možné snadněji a rychleji reagovat na nalezené chyby. 

Nejznámější implementací iterativního přístupu je tzv. spirálový model.  Ten rozlišuje základní čtyři činnosti: Analýzu, Hodnocení rizik, Vývoj+testování, Plánování další iterace. Tyto činnosti je možné vynést na osy grafu. Vývoj začíná v bodě nula, kdy neexistuje aplikace a začíná se sběrem požadavků. Tím "produkt" začíná získávat na "objemu". Každý posun do další fáze znamená jeho růst. Při několika iteracích a jejich grafickém znázornění vývoje aplikace získáme spirálu. Pěkný obrázek tohoto grafu je k dispozici na wikipedii:

 

 

 Agilní metodiky

Dnes aktuální téma. Nejde ani tak o nějakou revoluci, jako spíš o další vývojový stupeň navazující na předchozí přístupy. Snahou je minimalizovat formálnost ve vývoji softwaru a tím tento vývoj zrychlit. Základem je co krátký cyklus a vysoká úroveň komunikace se zákazníkem. Agilní metodika je zaměřená na malé týmy, důležitá je totiž přímá komunikace bez formalit. Cílem veškerého snažení v rámci agilních metodik je spokojenost zákazníka a proto důležitou roli hraje právě komunikace se zákazníkem a jeho zapojení do procesu vývoje.

Neznámější agilní metodiky jsou Extrémní programování  a SCRUM. Ještě tu o nich bude řeč.

 

Nejbližší události


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