Základní úrovně testování jsou definovány jako soubor testů, kterými je software testován na daném stupni podrobnosti. Podle toho v jaké fázi a s jakým časovým odstupem od sepsání kódu, se testování provádí, jej dělíme do pěti základních úrovní:
- Testování programátorem (Developer testing)
- Testování jednotek (Unit testing)
- FAT – Funkční testy
- Integrační testování (Integration testing)
- SIT – Systémové testování (System testing)
- UAT – Akceptační testování (Acceptance testing)
Testování programátorem
Ihned po vytvoření programového kódu, je tento kód prověřen programátorem. v praxi jsou tyto testy označovány jako „Assembly tests„. Většinou si však programátor netestuje svoji část kódu, ale realizuje se tzv. „test čtyř očí“. To znamená, že kód testuje jiný programátor, než ten který jej napsal. Program je v tomto stupni kontrolován na úrovni zdrojového kódu. V praxi je bohužel tento stupeň testování často podceňován. Přitom opravy chyby v této části testování software je nejméně nákladná. Sám jsem byl svědkem toho, jak vývojář, aniž by si po sobě jakkoliv zkontroloval kód, předal program k dalšímu testování. Tester se připravil k vlastnímu testování (nastuduje si dokumentaci, připraví testovací data apod.) a začal provádět testy. Záhy však zjistil, že program nelze spustit a nemůže tak ani začít samotné testování. Nahlásil tedy chybu tvůrci programu a ten ji posléze začal opravovat. Tester se tak zbytečně připravoval a začínal provádění testů. Kdyby si po sobě programátor zkontroloval kód dříve, zjistil by chybu mnohem rychleji než tester. Samotná oprava chyby by tak zabrala výrazně méně času. Takovéto postupy zbytečně zabírají čas i ostatním členům týmu.
Testování jednotek
Po ověření kódu programátorem přichází na řadu test jednotek. U objektově orientovaného programování se jedná o testování jednotlivých tříd a metod. Testovanou jednotkou v tomto případě rozumějme samostatně testovatelnou část aplikačního programu. Testy těchto jednotek se zapisují ve formě programového kódu. Proto jej z pravidla obsluhují vývojáři. Pro vytváření testů se využívá nástrojů na bázi frameworků.
Testy jednotek se velmi špatně aplikují na již zaběhlých projektech. U již vytvořených aplikací se většinou musí provést kompletní refaktoring kódu či dokonce mnohem hlubší úpravy. Takováto časová investice se u menších projektů většinou nevyplatí, ale ani u velkých projektů takovýto zásah není příliš šťastný a často se nesetkává s podporou u vedoucího projektu. Proto je vhodné zabývat se těmito testy již v etapě návrhu aplikace a v té době se rozhodnout, zda tyto testy budeme využívat. Jelikož obecně platí, že čím dříve (v rámci životního cyklu software) chybu nalezneme a opravíme, tím méně času nad touto opravou strávíme. Proto bych doporučoval této úrovni věnovat maximální pozornost a to již před samotným vývojem aplikace.
FAT – Funkční testy
Factory acceptance tests (FAT) je fáze během níž jsou testy prováděné na straně dodavatele. Během FAT jsou exekuovány především Funkční testy – ty jsou popsané ve zvláštním příspěvku. Aplikace nemusí být testována na plně integrovaném prostředí. Splnění akceptačních kritérií na konci FAT je nutnou podmínkou pro vstup do následující fáze SIT.
Integrační testování
V době, kdy je vývojář hotov se svými testy, přichází na řadu testovací tým. Integrační testy tedy nepřipravuje programátor, ale především testovací tým. Někdy bývají označovány jako „testy vnitřní integrace“. Musí být ověřena bezchybná komunikace mezi jednotlivými komponentami uvnitř aplikace. Integraci však lze ověřovat nejen mezi komponentami, ale také mezi komponentou a operačním systémem, hardwarem či rozhraním různých systémů. V této fázi se tak testuje integrace dosud jednotlivě ověřených částí. Postupně začínáme testovat integraci mezi dvěma komponentami a postupně přidáváme další. Integrační testy mohou být jak manuální, tak i automatizované.
Úroveň integračního testování je svým způsobem obsažena ve většině testovacích postupů softwaru. U menších projektů je však na tyto testy kladen velmi malý důraz. Má to své logické odůvodnění. Integrační testování lze v testovacím cyklu zcela vynechat. Na výslednou bezporuchovost softwaru to přitom nebude mít žádný vliv, tedy alespoň za předpokladu, že korektně provedeme následující úrovně testování. Chyba, kterou bychom odhalili během integračních testů, se zcela jistě projeví v průběhu dalších úrovní testování. Jak již bylo zmíněno dříve, během testování však platí: „čím dříve chybu objevíme, tím méně úsilí nás stojí její oprava“. Proto integrační testy mají svůj význam, nicméně nelze jejich použití nikterak přeceňovat.
Systémové testování
Spojení Integračních i Systémových testů je označována jako fáze SIT – System Integration Tests. Po ověření správné integrace nastává ten pravý čas na systémové testování. Během těchto testů je aplikace ověřována jako funkční celek. Tyto testy jsou používány v pozdějších fázích vývoje. Ověřují aplikaci z pohledu zákazníka. Podle připravených scénářů se simulují různé kroky, které v praxi mohou nastat. Obvykle probíhají v několika kolech. Nalezené chyby jsou opraveny a v dalších kolech jsou tyto opravy opět otestovány. Součástí této úrovně jsou jak funkční tak nefunkční testy. Poslední úroveň testů, které se provádějí před předáním produktu zákazníkovi, jsou tedy systémové testy. Tato úroveň testů tak většinou slouží jako výstupní kontrola softwaru. Systémové testování je obsaženo prakticky v každém procesu testování. Bez této úrovně by celé testování softwaru nemělo žádný význam. Bezporuchovost výsledného produktu by byla významně ohrožena. Proto tuto úroveň testů považuji za stěžejní v celém postupu testování software. Na realizaci těchto testů by se mělo myslet již v raném stádiu návrhu postupu testování, tak aby bylo možné obsahu testů co možná nejvíce přizpůsobit očekávanému softwaru.
UAT – Akceptační testování
User acceptance test (UAT) jsou akceptační testy na straně zákazníka. Pokud všechny předchozí etapy testů proběhly bez větších nedostatků, je možné předat aplikaci zákazníkovi. Ten si většinou se svým týmem testerů provede akceptační testy. Ty jsou často prováděny podle připravených scénářů, které společně připravil zákazník s dodavatelem. Testy probíhají na testovacím prostředí u zákazníka. Nalezené nesrovnalosti mezi aplikací a specifikací, jsou reportovány zpět vývojovému týmu. Opravené chyby jsou nasazeny na prostředí u zákazníka. V této úrovni je zřejmě nejdůležitější, definovat si předem jakou formou bude probíhat oznamování chyb od zákazníka a jak zabezpečit opravení těchto chyb v co možná nejkratší době. Z vlastních zkušeností mohu konstatovat, že zákazník zpravidla očekává určitou chybovost software a je spokojen, když jeho testovací tým nějakou chybu objeví. Velmi nespokojen je však ve chvíli, pokud je takovýchto chyb mnoho nebo jsou to chyby, jež mají zásadní dopad na funkčnost celé aplikace. Pokud jsou již nějaké chyby v úrovni akceptačních testů objeveny, je nutné v co nejkratším čase tyto chyby opravit a předat zákazníkovi k dalším testům. Velké prodlevy v nalezení a opravení chyby (v akceptační úrovni testování) mohou vést ke zpoždění termínu nasazení softwaru do provozu. Taková situace může mít fatální dopad na úspěch celého projektu.
