​​V dnešní době všechny společnosti využívají mnoho různého softwaru jako řídící nástroj a pro podporu svých obchodních procesů. Ať už se bavíme o průmyslových podnicích, finančních institucích nebo telekomunikačních společnostech, obvykle platí, že byť software není jejich cílovým produktem, jsou na jeho bezchybném fungování životně závislé. Jinými slovy, bezchybné fungování podnikových aplikací je nutnou podmínkou existence a fungování podniků a testování softwaru k tomuto fungování zásadně přispívá.

Testování softwaru

Testování softwaru je nedílnou součástí samotného vývoje softwaru. Cílem testování je odhalit co nejdříve chyby, resp. odchylky od očekávaného chování v softwaru a zajistit jejich nápravu. Oblíbeným modelem testování je V-model (viz obrázek 1). Při testování dle tohoto modelu je kladen důraz na jednotlivé typy testů – unit testing, integrační a systémové testování a akceptační testování. Při testování se ověřují různé charakteristiky kvality softwaru, např. dle FURPS modelu.

Testovaný software může být velice různorodý, různě složitý, s různým cílem použití. Příkladem mohou být různé prodejní aplikace jako samoobsluhy, e-shopy, ale také aplikace typu CRM, ERP, internetové bankovnictví, různé integrační a komunikační softwary atd. Všechny tyto softwary je třeba při jejich vývoji, resp. před jejich ostrým používáním otestovat, zda splňují požadavky na ně kladené. A to jak požadavky funkční, tak požadavky nefunkční. Funkčními požadavky bývá popis, co software v danou chvíli dělat má, výjimečně i co naopak dělat nemá. Nefunkčními požadavky zde rozumíme např. požadavky na dostupnost, výkon, atd.

Podnikové aplikace

Speciálním typem softwaru jsou právě podnikové aplikace. Podnikovou aplikací zde chápu soubor HW a SW komponent, který realizuje nějakou funkčnost nutnou pro běh společnosti nebo přispívající k dosažení jejích obchodních cílů. Jako podnikové aplikace si lze představit např. systémy v bankách, u telco operátorů, ale samozřejmě i různé systémy ve výrobě. Hlavní podnikatelskou činností většiny firem je dodávat klientovi nějakou službu. K tomu potřebují podpůrné IT systémy, resp. aplikace. Bezproblémový chod těchto systémů a rychlá implementace změn dle požadavků jsou pro daný podnik klíčové.

V čem jsou podnikové aplikace z hlediska testování specifické? Je to především celková složitost, míra vzájemné integrace, architektonická různost vzájemně propojených dílčích systémů. Dále pak požadavky na vysokou dostupnost a stabilitu. Těchto dílčích systémů může být i několik set, těch hlavních desítky. Přitom dílčím systémem zde bývá relativně samostatná aplikace, která ale pro korektní fungování vyžaduje „živé“ relativně velké okolí – podpůrné systémy, služby, atd.

​Tyto dílčí systémy mohou mít různou vnitřní architekturu. Například třívrstvou, resp. vícevrstvou tvořenou typicky databázovou vrstvou, aplikačním serverem, případně load balancery a komunikující jednak s dalšími systémy v podniku a typicky s klientem, nebo uživatelem např. přes tenkého klienta – různé internetové prohlížeče v různých verzích, atd. Časté jsou systémy dvouvrstvé, kdy tzv. tlustý klient komunikuje přímo s databází, resp. volá obecně služby, které zpřístupňují nějakou obecnou funkčnost. Samostatným typem aplikace je tzv. „střední vrstva“, kdy jsou budovány tzv. Enterprise Service Bus (ESB) systémy zajišťující komunikaci mezi poskytovateli funkčnosti a konzumenty, přičemž je dodržena vzájemná kompatibilita v čase.

Vždy je třeba zajistit otestování jak vnitřní integrace daného sub-systému na okolní systémy, tak ověření funkčnosti, jež má daný systém realizovat vzhledem ke klientovi, konzumentovi. Jednotlivé subsystémy mohou být tvořeny jak balíkovým softwarem, tak vývojem na zakázku. Často bývá balíkový software přizpůsobován potřebám společnosti, což přináší další komplikace při implementaci a prostor pro testování.

Testování podnikových aplikací

Z pohledu testování, resp. implementace změn v takto složitém a různorodém světě je třeba brát v úvahu mnoho aspektů:

• Architekturu řešení a testovací prostředí,
• testovací data a jejich nutnou různorodost,   
• provedení testů různých úrovní (unit testy, assembly testy, integrační testy, systémové testy) a typů (funkční testy, testy nefunkčních požadavků, atd.),
• akceptace zákazníkem.

Změny, resp. požadavky na změny jsou realizovány formou projektů, nebo drobných změn a vylepšení. Vždy mívají zadavatele, jimiž jsou obvykle oddělení využívající funkčnosti, nebo vedení společnosti a bývají řízeny projektovým manažerem, jenž je odpovědný za správnou implementaci.
Požadavky jsou často definovány bez ohledu na architekturu a složitost aplikací. Tu správnou realizaci v aplikacích zajišťuje až architektonický návrh v rámci projektu. Zde se tester, resp. test architekt zamýšlí, provádí test analýzu požadavků a architektonického návrhu a dává první zpětnou vazbu realizačnímu týmu z pohledu proveditelnosti testování, a to s ohledem na možnosti testovacího prostředí, času, testovacích dat i lidských a finančních kapacit.

Obr. 1: V-Model je oblíbeným modelem testování softwaru, ve kterém jsou na první pohled zřejmé jednotlivé úrovně vývoje softwaru a odpovídající úrovně testování.

Testovací prostředí

V testování a vývoji softwaru obecně je definováno testovací prostředí jako obdoba produkčního prostředí s tím rozdílem, že v testovacím prostředí je třeba zohlednit ve všech systémech budoucí změny s ohledem na plánovaný čas nasazení do produkce. Tedy pokud je ve společnosti definován jednotný release kalendář, kdy je pevně stanoveno několik termínů v roce pro nasazování změn do produkce, je situace z pohledu prostředí jednodušší, nedochází zde k výrazným nekompatibilitám, ale zvyšuje se operační riziko v případě zanesení neodhalené chyby a bývá náročnější podpora produkce těsně po nasazení. V druhém případě, kdy se aplikace nasazují v různých termínech, bývá nutné buď zajistit otestování vzájemných meziverzí, nebo popsat riziko plynoucí z jejich neotestování.

Co je nutné v testovacím prostředí zajistit, je dostupnost jednotlivých komponent v průběhu testování.

V takto složitém světě bývají v principu dva typy komponent. Jednak ty, které cíleně měníme, s těmi obvykle jsme již v době architektury a návrhu v kontaktu, ale také komponenty, jež cíleně neměníme, ale jen používáme. Zde se často zapomíná na včasnou komunikaci s cílem zajistit dostupnost dané komponenty testovacího prostředí.

Testovací data

Další oblastí v testování podnikových aplikací, jíž je třeba se zabývat, jsou testovací data. Potřeba testovacích dat je definovaná na základě test analýzy z jednotlivých testovacích scénářů a týká se všech úrovní testování (viz V-model). Správná testovací data jsou klíčová pro úspěšné provedení testů. S ohledem na architekturu aplikací platí, že je třeba testovací data připravovat konzistentní vzájemně mezi jednotlivými systémy a s ohledem na cíle testování.

Jak mohou testovací data v testovaných systémech vzniknout? Cest je několik. Jednou možností je „kopie“ z produkčního prostředí. Zde je ovšem třeba zajistit vhodnou anonymizaci dat a také uvážit to, že testovací data nemusejí mít potřebnou variabilitu. Další možností je pořízení syntetických dat přes testovanou aplikaci, nebo přes primární systémy. V praxi se obě varianty vhodně kombinují.

Technicky lze data do daného systému pořídit např. pomocí DB insertů, zde je ale riziko nedodržení všech nutných referencí mezi DB tabulkami. Vhodnější je tedy pořídit data uživatelsky, zde ovšem je třeba, aby aplikace byla v této části funkční, což při vývoji nemusí být zajištěno a pak je tato metoda poměrně pracná. Zde lze doporučit využití nástrojů pro automatizované testování.  

Průběh testování

Máme testovací prostředí, testovací data a jdeme testovat. V případě, že máme poměrně složitý systém složený z více aplikací, nemůžeme začít testovat všechno hned. Je třeba testování dobře rozmyslet. Mějme situaci, kdy zadavatel definuje projekt, jenž mění funkčnosti např. v deseti systémech, a aplikujme V-model.

Zde by měly být vždy nejdříve provedeny „lokální“ testy v každém systému, a to různých úrovní – unit testy, funkční testy, ale například i zátěžové testy. Následně by měly být provedeny integrační testy vzájemné komunikace mezi systémy – to může mít zase několik úrovní, tu technickou, kdy ověřujeme, že systémy spolu „mluví“, až po věcnou, funkční, kdy ověřujeme, že systémy spolu mluví správně. Na závěr by měly být provedeny akceptační testy, které mohou mít různý rozsah od lokálních, kdy akceptující ověřuje jen změnu v dané aplikaci, anebo tzv. end to end, kdy akceptující ověřuje změny ve všech měněných systémech. Každému typu a úrovni testů přísluší adekvátní příprava a forma testovacích scénářů. Do procesu akceptace je třeba co nejvíc začlenit zadavatele změn.

Metodiky vývoje podnikových aplikací

Metodiky vývoje rozlišujeme v principu dvě: tzv. vodopád, kdy jsou postupně definovány požadavky, design, pak provedena implementace a testování a nasazení do produkce je až na konci vývojového cyklu, a agilní metodiku, kdy je software dodáván iterativně a inkrementálně a funkčnost se dostává do produkce postupně. Ve vývoji podnikových aplikací se používá obojí přístup, včetně jejich kombinací a hybridů, kdy např. celý projekt je veden v principu vodopádově a některá součást, subdodávka agilně. Tomuto přístupu se musí podřídit i testování.

Závěr

Testování podnikových aplikací je velice zajímavou oblastí testování. Zde více než kde jinde se ukazuje, že tester musí být přítomen na projektu hluboko v jeho začátku. Toto testování je velmi různorodé, každý projekt je jiný co do rozsahu změn, složitosti a dopadů, také potřeb testování. Trendem v současnosti je větší důraz na agilitu, zapojení zadavatele do testů, v neposlední řadě automatizace v testování v rámci continous integration, ale to už je námět na samostatný článek. 

Ondřej Chromek

Článek vyšel v časopisu IT Systems (www.SystemOnLine.cz).