facebook
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
Dialog 3000Skylla
IT SYSTEMS 9/2013 , ITIL – Řízení IT

Testování podnikových aplikací

je plavba po rozbouřené řece



DeloitteTestování bývá často považováno za nechtěné dítě implementace. Stojí hodně peněz, není jednoduché ho zorganizovat, zabere spoustu času v kritických fázích implementačního projektu a poukazuje na věci, které se během něj zanedbaly. Bohužel realita je taková, že by pro oblast testování mohl být definován nový Murphyho zákon: co se neotestuje, to nefunguje. Tento článek se zabývá častými nešvary v oblasti testování balíkového softwaru typu ERP, CRM apod.


Základní typy testů

Testování balíkového softwaru by mělo vycházet z tradičního V-modelu (obr. 1). V-model na jedné straně podává přehled o základních implementačních artefaktech (např. požadavky, funkční návrh, technický návrh apod.) a na straně druhé podává přehled o typech testů (např. jednotkové testy, funkční testy, integrační testy, uživatelské akceptační testy apod.) a jejich vazbách na projektové artefakty.
 

Obr. 1: V-model
Obr. 1: V-model


Zjednodušeně lze říci, že jednotlivé vyvinuté části kódu se ověřují jednotkovými testy. Jednotkovým testem si typicky vývojář, případně konzultant sám ověří, že jeho kód, respektive konfigurace, funguje podle zadání, které dostal. Následujícím testem je systémový test, kde jsou již prověřovány komplexnější části aplikace, ale bez vazby na okolní aplikační prostředí. V rámci integračního testu dále dojde k prověření end-to-end správného napojení implementované aplikace na okolní informační systémy. Uživatelské akceptační testování provádí již budoucí uživatelé systému. Během těchto testů ověřují, že implementovaná aplikace odpovídá jejich business požadavkům. Uživatelské akceptační testy by měly probíhat již na plně odladěné aplikaci a měly by mít charakter průřezových testů napříč nejkritičtějšími aplikacemi či funkcemi implementovaného řešení.

Většina implementačních projektů bývá bohužel kapacitně, časově a finančně podhodnocena. V okamžiku, kdy se nestíhají termíny, je testování jedna z prvních oblastí, kde se začne krátit původní harmonogram. Projektový management začne vyvíjet nátlak, aby se omezil rozsah testování, vypustily se některé druhy testů nebo došlo ke zkrácení testování o několik týdnů až měsíců. Tato jejich snaha bohužel bývá mnohdy úspěšná.

Životní cyklus testování

V následujícím textu se zaměříme na problémy související s přípravou testovací strategie, přípravou testování, realizací testů a ukončením testování, tedy navazujícími fázemi testování.
 

Obr. 2: Životní cyklus testování
Obr. 2: Životní cyklus testování


Testovací strategie pokládá základní kámen celého testování. Měla by odpovědět na základní otázky:

  • Proč testovat?
  • Co testovat a netestovat?
  • Kdy testovat?
  • Kdo bude testovat?
  • Kde testovat?
  • Jak testovat?

Ačkoli se jedná o základ celého testování, její příprava je nezřídka považována za zbytečnou administrativu a samotná strategie testování za cár papíru. Tím se samozřejmě může stát, pokud její autor nedokáže dostatečně srozumitelně odpovědět na výše uvedené otázky nebo pokud nedojde k odsouhlasení obsahu tohoto dokumentu všemi zúčastněnými stranami.

Principy

Mezi základní principy testování, které by měly být promítnuty do obsahu strategie testování, jistě patří principy měřitelnosti, transparentnosti, trasovatelnosti a auditovatelnosti. Měřitelnost znamená možnost jednoznačně vyčíslit a popsat stav testování v daném čase a umožňuje stanovit a vyhodnotit kvantitativní kritéria pro akceptaci testů. Transparentností je myšleno pravidelné a důvěryhodné vzájemné informování všech zúčastněných a využívání důvěryhodných technických prostředků pro podporu testování. Trasovatelnost spočívá v zajištění jednoznačné identifikace business, funkčních a systémových (nefunkčních) požadavků skrze všechny relevantní implementační fáze a jejich trvalé a udržované provázání s odpovídajícími projektovými artefakty, jako jsou odpovídající části funkčních a technických specifikací, testovacích scénářů a testovacích skriptů apod. Auditovatelností se pak rozumí možnost zpětné kontroly vykonaných testů, oprav defektů apod.

Nerespektování principu transparentnosti se projevuje tím, že implementační partner mívá tendenci neinformovat o průběhu jednotkových a systémových testů, kdy tvrdí, že tyto testy jsou jeho interní záležitostí. Jedná se však o mylnou představu, která může být dočasně výhodná jen ze strany implementačního partnera, kdy tím může získat na úkor omezeného testování dodatečný čas na dokončení vývoje. Břímě testování se tak přenáší na zákazníka, který se postupně více zapojuje do testování, a později vlastními silami odhaluje chyby, které měl dříve odchytit implementační partner.

Nedostatky či neexistence trasovatelnosti se projevuje ve snížené schopnosti kvalitně připravit a naplánovat testování a ve snížené vypovídající hodnotě testování. Bez trasovatelnosti je nemožné konstatovat, které požadavky byly otestovány a s jakým výsledkem. Není pak vůbec jisté, jestli implementovaný systém odpovídá tomu, co bylo původně businessem požadováno.

V případě nerespektování principu měřitelnosti bývá systém akceptován na základě vnitřního pocitu či víry, že se řešení povede „nějak“ nasadit a že to bude „nějak“ fungovat. Akceptovat dílo v minimální hodnotě několika milionů na základě vnitřních pocitů či víry je bez diskuse pro každého racionálně uvažujícího zákazníka velmi rizikové.

Pravidla

Strategie vymezuje základní pravidla pro testování. Mezi ně lze zařadit i SLA vztahující se na opravy defektů identifikovaných během testování. Implementační partneři se typicky snaží buď SLA na opravu defektů zcela vyhnout, nebo je nastavit velmi volně. Neexistence SLA nebo příliš dlouhé lhůty pro odstranění defektů jsou pro zákazníka velmi nebezpečné zejména během uživatelského akceptačního testování. Vzhledem k tomu, že na akceptaci systému na základě uživatelských akceptačních testů je zpravidla navázán platební milník, může mít implementační partner při neexistenci SLA či jeho nedostatečném nastavení tendenci taktizovat zdržováním uvolňování oprav chyb a ve větší míře je uvolňovat až ke konci testování, což se pak může projevit tak, že zákazník nemusí stihnout plně otestovat implementované řešení, a neodhalit tak jeho zásadní vady, nebo se to může projevit v demotivaci testerů, kteří pak identifikované chyby ani raději nehlásí.

Kapitolou samou pro sebe jsou snahy dodavatelů bagatelizovat význam některých testů. Dodavatelé se snaží typicky vyhnout zátěžovým testům. Slyšel jsem dodavatele říkat: „Máme tak naddimenzovaný hardware, že by na tom mohl běžet i centrální mozek lidstva.“ Zákazník však nedal na doporučení, aby se zátěžové testy nevynechávaly, a ignoroval i argumenty, že naddimenzování hardwaru nemusí nic znamenat, že výkonnost je dána také kvalitou kódu. Zátěžové testy se tedy nekonaly a výsledek po nasazení do produkce byl takový, že na dokončení základních transakcí uživatelé čekali i několik minut.

Příprava testovacích scénářů

Je žádoucí vycházet při přípravě testovacích scénářů a skriptů z funkčních a nefunkčních požadavků. V případě, že nejsou k dispozici požadavky, je složitější určit, jaká jsou nejvýznamnější očekávání od nového systému. Příprava scénářů a skriptů bez tohoto vodítka je pak zdlouhavá, neboť je nutné detailně prostudovat příslušné funkční specifikace a opakovaně se bavit s businessem, co a jak je pro ně důležité. Neexistence požadavků či neexistence trasovatelnosti požadavků na testovací scénáře či skripty pak omezuje možnost vyhodnocení výsledků testů. Akceptovat nový systém na základě ukazatele, který říká, že řešení bezchybně splňuje 95 procent požadavků businessu je méně rizikové než akceptovat systém na základě ukazatele, který říká, že 95 procent testů dopadlo v souladu s funkční specifikací.

Realizace

Základním bodem této fáze je příprava testovacích dat, což bývá často podceňováno. Pro testy se využívají jak nově vytvořená data či transakce, tak i data a transakce migrované. Situaci dále komplikuje potřeba zajistit integritu dat mezi jednotlivými integrovanými informačními systémy. Pořídit v implementovaném systému několik desítek záznamů klientů pro potřebu testování bývá zpravidla jednoduší a přímočará věc, kterou zvládne i automat. V případě, že data potřebujete mít ve více systémech, může se celkový čas přípravy prodlužovat o čekání na replikaci dat do těchto systémů či čas potřebný na zpracování dat v těchto integrovaných systémech. Dále je potřeba mít na paměti, že některá data lze použít pro test jen jednou a že data mohou mít jen omezenou životnost, tj. že test se na vybraných datech musí odehrát k určitému termínu, neboť po tomto termínu se data změní tak, že jsou dále pro původní test již nepoužitelná.

Vykonání testů

Testovaní v rámci navazujících testů na základní testy (jako jsou jednotkové testy či systémové testy) by se již vývojáři a konzultanti neměli účastnit z důvodu konfliktů zájmů. Na menších implementačních projektech nezřídkakdy probíhá testování tak, že testuje funkční konzultant, a odpovědný business zástupce, který se necítí na samostatné testování systému, konzultantovi jen nahlíží přes rameno, jak tam na „něco kliká“. Rizika plynoucí z této fatální záměny testování za aktivitu CRP (conference room pilot) není potřeba zmiňovat.

Během testování si testeři obvykle snaží zjednodušit práci. V případě, že identifikují chybu, automaticky zakládají nový defekt, aniž by se přesvědčili, jestli v seznamu chyb podobná chyba již neexistuje. V případě, že s vyhledáním potenciálně stejných defektů nedokáže efektivně pomoci nástroj pro defect management, může být založení nového defektu o mnoho rychlejší než vyhledání již existujícího defektu a navýšení počtu jeho výskytu. Takovéto počínání nejenže zkresluje statistiky testu, ale také navyšuje pracnost, protože nový defekt někdo musí převzít, zanalyzovat, označit za duplicitu, či v horším případě duplicitně vyřešit. Uvolňování oprav nahlášených defektů vyžaduje důslednou disciplínu, vhodný nástroj a bezchybnou koordinaci a komunikaci. V praxi se bohužel často stává, že vlivem chybného verzování je již jednou opravený kód přepsán jeho nefunkční starší verzí. Časté opakované výskyty již jednou opravených a přetestovaných chyb jsou jednou z největších frustrací testera.

Dalším častým problémem na straně implementačního partnera při řešení identifikovaných chyb je fenomén označovaný jako ping-pong. Ping-pong s identifikovaným defektem nastává v okamžiku, kdy nelze přesně a rychle stanovit, co je příčinou chyby. V případě jednoho dodavatele si chybu mezi sebou mohou „pinkat“ dva vývojáři různých částí kódu nebo například vývojář a administrátor báze s tím, že všichni tvrdí, že chyba není na jejich straně. V pozdějších fázích akceptačních testů rovněž často dochází k tomu, že vývojář řádně neotestuje opravu a předá ji pro uvolnění na testovací prostředí bez provedení potřebných regresních testů.

Ukončení testů

Problémy v oblasti vykazování dokončených testů byly již zmíněny v části o principu transparentnosti testování. Vzhledem k tomu, že se během testů a ani před zahájením navazujících testů téměř nikdy nepodaří opravit všechny chyby, je detailní informace o výsledcích předchozího testování (např. ve formě mapování neopravených nebo přetrvávajících chyb na procesy či scénáře) důležitá pro naplánování testování navazujícího.

Mnozí zákazníci z těch, co nemají vlastní útvar testování či ho nemají přiměřeně dimenzovaný, si plně neuvědomují závažnost testování, nejsou dostatečně připraveni oponovat návrhům implementačního partnera, který má z principu věci značnou informační převahu, a nejsou tak schopni najít optimální řešení pro oblast testování. Vzhledem k tomu, že najít na trhu dostatečně zkušené lidi pro testování s ideálním mixem znalostí a zkušeností implementovaného produktu a odvětví není lehká úloha, a vzhledem k faktu, že pro mnohé firmy je implementace klíčových aplikací, jako je ERP, CRM či CBS jedinečná a svým rozsahem zřídka opakovatelná událost, jeví se jako nejefektivnější obrátit se na externího nezávislého poradce, který má dobré know-how z oblasti testování, znalost nástrojů pro podporu testování a praktické zkušenosti s testováním z mnoha implementačních projektů.

Zdeněk Slunečko

Autor působí jako senior konzultant ve společnosti Deloitte. Pravidelně se účastní domácích a zahraničních projektů v oblasti informačních technologií, které svým rozsahem pokrývají celý životní cyklus podnikových informačních systémů. Pracuje na projektech zejména v odvětvích bankovnictví, technologie a telekomunikace.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.