Dnes bych se tu rád stručně rozepsal o hlavních typech testů, které se na projektech používají.

Už jsem tu v jiném článku popisoval druhy testování s ohledem na jejich zapojení do vývoje softwaru. Dnes se zaměřím na tu nejpodstatnější část (tedy alespoň z pohledu objemu práce testerů) - Systémové a integrační testy. Už ve zmíněném článku jsem tyto testy dále rozpadl na další podmnožiny. Teď se na ně podíváme podrobněji.

V okamžiku kdy je aplikace dodána ve stavu, kdy je testovatelná (tedy je vyvinuta, nainstalovaná, spuštěná a přístupná) pak se obvykle jako první spouští Smoke testy. Ty mají za úkol ověřit, že aplikace je skutečně vhodná k testům. Obsah těchto testů se liší tester od testera, firma od firmy. Ale můžeme si zde uvést nejčastější vlastnosti těchto testů. Smoke testy se obvykle zaměřují pouze na hlavní funkce aplikace a to pouze v jejich pozitivním průběhu (více zde). Netestují se validace vstupů ani formáty výstupů. Smoke testy mohou být automatizované a to i v případě, kdy je zbytek testů prováděn manuálně. To je dáno právě tím, že rozsah těchto testů je podstatně menší a navíc také tím, že se zaměřují na funkčnosti, u nichž se nepředpokládají velké změny a proto není potřeba automatizovaný testovací skript často upravovat. Stručně řečeno - smoke testy jsou jedním z typů testů, kde se automatizace uplatňuje. Naproti tomu velice často jsou smoke testy prováděny také formou free testů. 

Úspěšné provedení smoke testů obvykle slouží jako vstupní kritérium pro spuštění dalších fází testování. Před smoke testy mohou proběhnout ještě testy Instalační. Jejich úkolem je ověřit, že aplikace je (v dodané podobě) instalovatelná. Tedy že dodávka obsahuje použitelný instalační balík, který obsahuje všechny nezbytné součásti a že instalace z tohoto balíku proběhne bez chyb až do spustitelnosti aplikace. Instalační testy nejsou příliš často prováděny stejnými testery jako zbytek testů. Obvyklejší je, že je provádí osoba, která je zodpovědná za správu testovacího prostředí a tedy i instalaci aplikace. Záleží samozřejmě na rozsahu projektu.

Jakmile jsou smoke testy a případné instalační testy úspěšně provedeny, začíná hlavní fáze testování. Její průběh je závislý na struktuře testované aplikace. Tím chci říct, že čím je testovaná aplikace jednodušší, tím méně fází má její testování. Já tu ale uvedu obvyklý postup testů u aplikací složitých, kterých je dnes naprostá většina.

Většina dnešních aplikací je složena z menších částí, kterým můžeme říkat moduly nebo například komponenty. Při testování takové aplikace se postupuje od menších částí k velkým celkům. Jako první se tedy provádí testování komponent. Jak je zjevné, toto testování se zaměřuje na nejmenší funkční celky aplikace, které je možné testovat samostatně (neplést s Unit testy, které se mohou zaměřovat i na menší části samostatně netestovatelné a které jsou prováděné vývojáři). Myšlenka těchto testů je snad celkem jasná - chyby komponent se nejsnáze nacházejí právě na úrovni komponent. Pokud se chyba komponenty projeví při jejím integraci do systému nebo dokonce až při integraci systému s dalším systémem, může být její odhalení podstatně složitější.

Přestože tu mluvíme o nejmenší samostatně testovatelné části aplikace, stejně se můžeme dostat do situace, kdy její testování není v této "solitérní" podobě není úplně snadné. Jde o to, že jednotlivé komponenty spolu samozřejmě v rámci aplikace komunikují a tedy mají vstupy z jiných komponent a i výstupy mohou být určeny pro další zpracování dalšími komponentami. Existují různé způsoby, jak toto obejít, jako jsou různé simulátory a nástroje. Vstup může být samozřejmě také simulován tak, že ho komponentě prostě "podstrčíte" a podobně.

Z vlastní zkušenosti musím říct, že fáze testování komponent se často spojuje s dalšími fázemi testování, především s fází integračního testování. Já sám tuto fázi označuji za testování vnitřní integrace. Jde totiž o testování správné komunikace jednotlivých komponent uvnitř aplikace. Bez ohledu na to, jakým konkrétním technickým řešením je tato integrace realizována, obsahem těchto testů je ověření, že jednotlivé komponenty si ve správný okamžik předávají správným způsobem zprávy, které mají správný obsah i formát.

Po otestování integrace přichází čas systémových testů. Ty se zaměřují na aplikaci jako celek v podobě, v jaké by ji měl používat zákazník. Zde se již ověřuje soulad reálného chování s chováním očekávaným, provádí se testování možných negativních průběhů, validují se výstupy a podobně. Pokud už žádná jiná fáze testování není použita, systémové testy jsou prováděny vždy (tedy za předpokladu, že se aplikace testuje).

Následovat mohou testy integrace aplikace s vnějšími systémy. Tady obvykle mluvím o integraci vnější. Tato fáze má samozřejmě smysl pouze tehdy, pokud k takové integraci dochází. Pokud ale ano, pak jde o fázi důležitou, která bývá někdy podceňovaná. Aplikace, která sama osobě pracuje dobře, ale nedokáže se domluvit se systémy, které pro svoje použití potřebuje, je pochopitelně těžko použitelná. Integrace přitom musí být správně navržena už při vytváření analýzy, podle které je aplikace vyvíjena. Už v této fázi vývoje softwaru by mělo dojít k testování a to testování dokumentace, aby se předešlo právě takovým chybám chybám. Ale o tom zase někdy jindy v rámci povídání o metodikách.

Integrační testování u této vnější integrace je poměrně náročné na přípravu. Především proto, že na těchto testech obvykle spolupracují všechny dotčené subjekty, tedy dodavatelé systémů, se kterými je testovaná aplikace integrována. Testování tak může mít podobu "štafetového závodu", kdy jeden tester ve svém systému provede nějakou operaci a druhý tester v tom svém sleduje výsledek. Samozřejmě opět záleží na konkrétním technickém řešení integrace. Pro testování mohou být využívány simulátory, testování může být prováděno i s pomocí tzv. "fake" vstupů, tedy vstupů které se tváří jako reálné reakce integrovaného systému, ale jejich obsah je upraven pro potřeby testování. První fáze těchto integračních testů se navíc obvykle soustředí jen na ověření správné funkce rozhraní, které je k integraci určené. Tedy na formát a obsah zpráv, které aplikace na toto rozhraní posílá.

Po úspěšném průchodu všemi fázemi systémových a integračních testů je aplikace vhodná pro testy akceptační. Tedy za předpokladu, že výsledky těchto testů splňují kritéria dohodnutá pro přechod do další fáze. O těchto testech zase někdy příště. A koukám, že zase až tak stručný jsem nebyl.