Tento obrázek jsem si vypůjčil na stránkách http://www.bugtracker.cz

 

V levé části modelu jsou uvedeny fáze vývoje aplikace. V pravé pak jednotlivé druhy testování. Každý druh testů slouží k ověření jiné fáze vývoje. Základem tohoto přístupu je postup testování od malých částí aplikace, přes větší funkční celky, přes integraci komplexních částí aplikace případně integraci více aplikací až po kompletní otestování celé aplikace. Přechod na další druh testování předpokládá úspěšné dokončení předcházející fáze. Často jsou pro tyto účely v rámci testovací dokumentace definovány konkrétní podmínky, za kterých je možné příslušný druh testování spustit.

 

UNIT testy 

Jde o první fázi testování, která se zaměřuje na nejmenší testovatelné části aplikace. Jde obvykle o testy jednotlivých komponent aplikace na úrovni modulů, objektů a tříd. Tento druh testování obvykle provádějí vývojáři a nebývá zahrnut do plánů testů aplikace. Vývojáři si těmito testy ověřují, že nová nebo změněná část kódu funguje (tedy nepadá do chyby) a že její funkce odpovídá očekávání.

 

Tyto testy jsou na pomezí mezi Unit testy a testováním prováděným testery. Úkolem Assembly testů je ověřit, že jednotlivé části aplikace je možné "sestavit" do funkčního celku. Jde tedy o test integrace jednotlivých komponent. Provádět tyto testy může vývojář a je to celkem obvyklé. U rozsáhlejších systému, případně u složitější struktury procesu vývoje bývá určen konkrétní pracovník, který je primárně odpovědný právě za sestavení aplikace a assembly testy.

 

Systémové a integrační testy 

Zde v tomto V modelu  je nejpodstatnější část testování shrnuta právě do této oblasti. Toto rozlišení je ovšem příliš hrubé a my si zde tuto skupinu testů, označených jako systémové a integrační, rozpadneme na další podskupiny.

 

  Předtím než je spuštěno testování aplikace je dobré ověřit, že tato aplikace je vůbec k testování vhodná. Tím je myšleno především to, že aplikace je nainstalovaná, spuštěná, přístupná a nakonfigurovaná pro potřeby testů. Jde o rychlé testy, obvykle obsahující jednoduchý "průchod" skrz aplikaci, které dokáží ověřit všechny zmíněné atributy. Tyto testy jsou již v působnosti testerů. Je ale možné, že je provádí pracovník odpovědný za správu testovacích prostředí.

 

  Integrační testy

U integračních testů je nutné rozlišovat mezi integrací vnitřní, která spočívá ve vzájemné komunikaci jednotlivých částí aplikace (modulů) a vnější, kdy jde o propojování jednotlivých aplikací do větších funkčních celků. U obou těchto integrací je nutné provádět integrační testy.

Integrační testy se tedy zaměřují na korektní komunikaci jednotlivých modulů, resp. aplikací. Právě integrace je z pohledu vývoje aplikací poměrně kritickou oblastí. Proto také integrační testy mají svoje nezastupitelné místo.

Integrační testy obvykle postupují od jednotlivých modulů směrem k věštím celkům. Tedy nejdříve jsou testována rozhraní jednotlivých modulů. Mnohdy jsou v této fázi využívány tzv. fake moduly. Jde o simulátory, jejichž úkolem je napodobovat komunikaci ostatních modulů ale bez jejich funkčnosti. Díky nim se ověří, že modul umí korektně odesílat i přijímat komunikaci s dalšími moduly.

Další fází je spojování modulů do větších celků, které mají z pohledu testování smysl. Poslední fází je testování kompletní aplikace.

Z pohledu integrace, kterou jsme si tu označili jako vnější, je nutné vzít v úvahu, že často dochází k integraci aplikací od různých výrobců. Tento druh testování je tak často náročný na kooperaci. Musí totiž při ní spolupracovat různé vývojové týmy. Ať už je tato spolupráce pouze na úrovni předání informací (popis interface) nebo jde o přímou kooperaci při testování.

 

Pokud se dnes mluví o testování, nejčastěji se tím myslí systémové testy. Jde o ověření, že aplikace jako celek funguje správně.Testuje se, že správně plní úlohu, pro kterou byla vyvinuta, že vrací správné výstupy, že byly ošetřeny všechny nestandardní situace a v neposlední řadě, že byly pokryty všechny požadavky ze strany zákazníka. Systémové testy obvykle probíhají v několika kolech. Jsou hlášeny nalezené chyby, ty jsou opraveny a v následujících kolech retestovány.

 

Z pohledu dodání aplikace zákazníkovi jsou nejpodstatnější Akceptační testy. Ty mají ověřit, že aplikace splňuje všechny zákazníkovy požadavky. Tyto testy může provádět stejný tým, který provedl systémové testy, ale stejně časté je i to, že zákazník pověří těmito testy jiný tým, který si často pro tyto účel vytvoří. Požadavky, které zákazník na funkci aplikace má, je vhodné ještě před zahájením vývoje (a zcela jistě před zahájením testování) shrnout do tzv. akceptačních kritérií. Ta mohou obsahovat požadavek na maximální počet chyb nalezených při testování, výkonové a zátěžové požadavaky a podobně. Splněním těchto požadavků vývoj aplikace v podstatě končí a aplikaci přebírá zákazník.

 

Nutno říct, že ani akceptace ještě nemusí znamenat úplný konec vývoje aplikace. Přestože je proběhnou všechny fáze testování, je stále vysoce pravděpodobné, že aplikace obsahuje chyby. Proto je v zájmu vývojářů tyto chyby opravovat. A s tím souvisí i potřeba opětovného testování.

Kromě opravy chyb může docházet také k rozšiřování funkčností aplikací.

V obou těchto případech je nedílnou součástí procesu vývoje také testování. Opět se zde uplatňuje většina výše zmíněných druhů testů. Nastupuje tu ale i jeden druh testování, který zde zmíněn ještě nebyl.

 

Tyto testy mají za úkol ověřit, že zásahy do aplikace nebyla narušen správná funkce těch částí, které těmito zásahy neměly být ovlivněny. Jinak řečeno testuje se, že oprava chyby nebo přidání nové funkčnosti nezpůsobily novou chybu v již funkčních částech aplikace.

Regresní testy se často automatizují, protože u nich jde o opakované provádění stejných operací se známým výsledkem. Jejich cílem je tak zjistit, zda neexistují odchylky mezi výstupem získaným před zásahem do aplikace a výstupem po tomto zásahu.

Regresní testy nemají své místo jen v okamžiku oprav nebo rozvoje již akceptovaných aplikací. Uplatňují se také u vývoje, který je rozdělen na etapy. Regresní testy zde ověřují, že vývoj v etapě neovlivňuje výstupy z etapy předcházející.