UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

UNICORN COLLEGE

Katedra ekonomiky a managementu

BAKALÁŘSKÁ PRÁCE

Popis procesů business testování a jejich optimalizace

Autor BP: Dalibor Pavlíček Vedoucí BP: Mgr. Julius Čunderlík

2012 Praha

Čestné prohlášení

Prohlašuji, že svou bakalářskou práci na téma Popis procesů business testování a jejich optimalizace jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne 4. 5. 2012

……………………. Dalibor Pavlíček

Poděkování

Děkuji vedoucímu bakalářské práci Mgr. Juliusovi Čunderlíkovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

Popis procesů business testování a jejich optimalizace Description of the business testing processes and its optimization

-5-

ABSTRAKT Tato práce si klade za cíl analyzovat, navrhnout, popsat a vyhodnotit procesy business testování ve velkých společnostech, jako jsou např. banky pojišťovny a obdobné finanční i nefinanční instituce. Hlavním cílem je vysvětlit, jak je takové testování nastaveno, popsat role, které se na něm podílejí a ověřit funkčnost vstupních a výstupních parametrů v jejich vzájemné kombinaci. Jedná se hlavně o optimalizaci a formalizaci samotných procesů business testování. V oblasti business testování jsem čerpal v některých částech této práce ze své osobní zkušenosti, jelikož na takovém projektu působím v roli Business Test analytika. Aplikace, které jsou v rámci business týmu testovány, jsou nejčastěji prodejní kanály a transakční komponenty. Tato práce je zaměřena na testování přímých kanálů a to zejména internetového bankovnictví. Jelikož jsou bankovní domy většinou obrovské společnosti s tisíci zaměstnanci a stovkou systémů, je problematika vývoje a testování velmi složitá. První část mé diplomové práce je zaměřena na vysvětlení základních pojmů v oblasti testování a základních druhů testů, které jsou využívány v rámci vývoje informačních systémů. Na závěr této části jsou popsány typy testů z obecného pohledu. Druhá část analyzuje business testování v bankovní společnosti, popisuje průběh pilotního projektu business testovacího týmu a vyhodnocuje jeho výstupy. V poslední části je popsán návrh testovací strategie a testovacího plánu, který je sestaven na základě vyhodnocení pilotního projektu. Klíčová slova: Business testování, tester, test analytik, testovací strategie, chyba, testovací plán, aplikace

-6-

ABSTRACT This work aims to analyze, describe and evaluate business testing processes in large companies such as banks. The main objective is to explain setting of the testing, describe the roles that work together and verify the functionality of inputs and outputs parameters in their combination. Representation covers mostly the optimization and the formalization of business processes. The field of business testing was also covered by using own experience from real project I've participated in as Business Test analytic. The subjects of testing applications in banks are mainly sales channels and transactional components. This work is focused on testing direct channels, especially internet banking. The banking sector is dependent on its sales channels and recently more clients started using internet banking and the overall demands increased on the product quality. Banks are usually large companies with thousands of employees and hundreds of systems, the issue of development and testing is very complex. The first part focuses on explaining the basic concepts in testing and reveals the basic types of tests that are used in software development. In the end of this section, the types of tests are described from a wider concept. The second part analyzes the testing business in the banking company, describes the implementation of pilot projects and evaluates the outcomes. The last section describes the design of test strategy and test plan, which are compiled based on evaluation of the pilot operation. Keywords: Business testing, tester, test analyst, test strategy, error, test plan, application

-7-

OBSAH

1.

Úvod ........................................................................................................................... - 11 -

2.

Úvod do problematiky testování .................................................................................. - 12 -

3.

Psychologie softwarového testování ............................................................................ - 13 -

4.

Základní pojmy ........................................................................................................... - 14 -

5.

4.1

Softwarová chyba ................................................................................................ - 14 -

4.2

Kvalita software .................................................................................................. - 15 -

4.3

Verifikace a validace ........................................................................................... - 16 -

4.4

Testovací plán ..................................................................................................... - 17 -

4.5

Testovací případ .................................................................................................. - 19 -

4.6

Testovací skript ................................................................................................... - 20 -

4.7

Testovací scénář .................................................................................................. - 21 -

Typy testů ................................................................................................................... - 23 5.1

5.1.1

Black box – Testování černé skříňky ............................................................ - 23 -

5.1.2

White box – Testování bílé skříňky .............................................................. - 23 -

5.1.3

Grey box – Testování šedé skříňky ............................................................... - 23 -

5.2

Rozdělení dle způsobu ......................................................................................... - 24 -

5.2.1

Statické testování ......................................................................................... - 24 -

5.2.2

Dynamické testování .................................................................................... - 24 -

5.2.3

Automatizované testování ............................................................................ - 24 -

5.2.4

Manuální testování ....................................................................................... - 25 -

5.3

6.

Viditelnost zdrojového kódu ................................................................................ - 23 -

Rozdělení dle času ............................................................................................... - 26 -

5.3.1

Testování jednotek ....................................................................................... - 26 -

5.3.2

Integrační testování ...................................................................................... - 26 -

5.3.3

Systémové a integrační testování .................................................................. - 27 -

5.3.4

Akceptační testování .................................................................................... - 28 -

Typy testování............................................................................................................. - 29 6.1

Testování konfigurace.......................................................................................... - 29 -

6.1.1 6.2

Postup při testování konfigurace................................................................... - 30 -

Testování kompatibility ....................................................................................... - 31 -8-

6.2.1

7.

8.

Postup při testování kompatibility ................................................................ - 32 -

6.3

Testování použitelnosti ........................................................................................ - 33 -

6.4

Testování webových aplikací ............................................................................... - 34 -

6.4.1

Testování konfigurace a kompatibility .......................................................... - 35 -

6.4.2

Testování použitelnosti ................................................................................ - 35 -

Business testování ....................................................................................................... - 37 7.1

Záměr .................................................................................................................. - 37 -

7.2

Business testovací tým ......................................................................................... - 38 -

7.3

Definice kompetencí rolí...................................................................................... - 40 -

7.4

Pilotní provoz business testovacího týmu ............................................................. - 40 -

7.5

Přínosy business testů na projektu Alfa ................................................................ - 42 -

7.6

Průběh testů projektu Alfa ................................................................................... - 43 -

7.7

Zaznamenané problémy v průběhu testů .............................................................. - 45 -

7.8

Chyby nalezené v průběhu business testování ...................................................... - 46 -

7.9

Vyhodnocení ....................................................................................................... - 47 -

7.10

Shrnutí a další postup........................................................................................... - 48 -

Test plán a strategie projektu BETA ............................................................................ - 49 8.1

Úvod ................................................................................................................... - 49 -

8.2

Harmonogram testů ............................................................................................. - 50 -

8.2.1

Free testy ..................................................................................................... - 50 -

8.2.2

Další důležité informace............................................................................... - 50 -

8.2.3

Příprava dat.................................................................................................. - 51 -

8.3

Zahájení UAT ...................................................................................................... - 51 -

8.3.1

Příprava dat na UAT .................................................................................... - 51 -

8.3.2

Průběh UAT................................................................................................. - 52 -

8.3.3

Další důležité informace k UAT ................................................................... - 52 -

8.4

Zaznamenávání chyb ........................................................................................... - 52 -

8.4.1

JIRA – nástroj pro evidenci chyb.................................................................. - 52 -

8.4.2

Závažnost chyb ............................................................................................ - 53 -

8.5

Testovací skripty ................................................................................................. - 53 -

8.6

Testovací tým ...................................................................................................... - 54 -

8.7

Akceptační kritéria – převzetí do UAT testů......................................................... - 55 -

8.8

Akceptace převzetí do technického pilotu ............................................................ - 55 -9-

8.9 9.

Vyhodnocení a ukončení testů ............................................................................. - 56 -

Závěr .......................................................................................................................... - 58 -

10.

Conclusion .............................................................................................................. - 60 -

11.

Seznam použité literatury ........................................................................................ - 62 -

12.

Seznam použitých symbolů a zkratek ...................................................................... - 64 -

13.

Seznam obrázků ...................................................................................................... - 65 -

14.

Seznam tabulek ....................................................................................................... - 66 -

- 10 -

1.

ÚVOD

Téma testování software jsem si vybral proto, že se již pár let pohybuji v této oblasti a nadále bych se chtěl touto disciplínou zabývat. Pracuji pro jeden z nejvýznamnějších bankovních domů v České republice a jsem v každodenním styku s aplikacemi, které využívají tisíce lidí každý den. Vývoj těchto produktů je extrémně náročný, jelikož na projektech participují desítky lidí a řízení takového týmu není jednoduché. Jsem rád, že jsem mohl být u zrodu business testovacího týmu, což pro mě byla obrovská zkušenost a který je i předmětem této práce. První část práce má za úkol seznámit s obecným pohledem na testování a nastínit různé typy testů, které se běžně používají na projektech a které jsou definovány v metodice testování. Nedílnou součástí první poloviny práce je představení základních typů dokumentace, bez které se důkladné a rozsáhlé testování neobejde. Testovací dokumentace je jeden z hlavních parametrů, na nichž závisí úspěch projektu. Tato část je spíše obecným pohledem na problematiku testování software, bez které se však toto odvětví vývoje software neobejde. V druhé části této práce je konkrétní příklad některých dokumentů, o kterých se zmiňuje část první. Tato část se rozděluje na další důležité prvky a to analýzu, popis a vyhodnocení pilotního projektu business testovacího týmu. Projekt Alfa, který je v rámci této studie podroben analýze, byl prvním projektem, který svými testy zastřešil právě tento nově vzniklý tým. Hlavní důvodem vzniku tohoto týmu byla absence řízeného a metodicky správného testování na straně business oddělení. Tato analýza poté slouží jako podklad pro závěrečnou část práce, kterou je návrh testovacího plánu a strategie pro testování Projektu Beta. Celá druhá část pojednává o vzniku a stabilizaci business testovacího týmu. Má za úkol poukázat na rozdíly mezi prvním pilotním projektem, na který nebyl dostatek času a druhým projektem, který se již precizně plánuje dopředu a na kterém můžeme pozorovat vliv zkušeností a znalostí načerpaných během pár let existence tohoto týmu.

- 11 -

2.

ÚVOD DO PROBLEMATIKY TESTOVÁNÍ

Je zřejmé, že v jednadvacátém století ovládá IT téměř každou oblast našeho života. Již dnes můžeme říci, že informační a telekomunikační technologie jsou všude kolem náš a těžko bychom si bez nich představili život. Člověk s nimi žije již v takové symbióze, že pomalu ztrácí povědomí o tom, jak jsou informační technologie důležité a pro náš život v podstatě nepostradatelné. Bez těchto technologií by většina činností trvala mnohem více času, těžko bychom si např. vybírali peníze kdekoliv na ulici z bankomatu. Existují však i takové oblasti, které jsou na informačních a telekomunikačních technologiích zcela závislé. A právě na tyto oblasti, vyžadující nespočet aplikací a systémů, které ve své podstatě musí fungovat téměř bezchybně, jsou kladeny velmi vysoké nároky. Zde vzniká první zásadní problém, který se dotýká vývoje a následného fungování různorodých aplikací a systémů, řídících a podporujících životy nás všech. Tím hlavním problémem je ona zmiňovaná „bezchybnost“. Co si představit pod tímto pojmem, rozebírají jiné kapitoly této práce, ale obecně lze na tento parametr nahlížet z různých úhlů. Nelze srovnávat např. systémy a infrastrukturu obsluhy letištní kontroly s webovými aplikacemi pro volný čas. Není nutné popisovat problematiku těchto dvou systémů, aby bylo jasné, jaký rozdíl je mezi požadavkem na kvalitu každého z nich. Je jasné, že se každá společnost, která se zabývá vývojem systémů, snaží o co nejdokonalejší produkt. Když se na toto tvrzení podíváme pohledem vývojářů tak můžeme tvrdit, že nelze naprogramovat systém bez chyby. Co nám tedy pomůže tento problém eliminovat a vyvarovat se selhání v budoucnosti? Odpovědí je softwarové testování, jehož hlavním cílem je chyby v programu odhalit a nechat následně odstranit. Bez precizního otestování je nasazení určitých systémů velmi rizikové. Chyby, které systém generuje jak při vývoji, tak např. při nasazení do provozu mají určitou hodnotu. Obecně můžeme tvrdit, že čím dříve je chyba odhalena, tím nižší jsou náklady na její odstranění [4].

- 12 -

3.

PSYCHOLOGIE SOFTWAROVÉHO TESTOVÁNÍ

Základním předpokladem pro správné pochopení problematiky testování je pochopení jeho definice. Často se můžeme setkat s následujícím názorem: „Testováním demonstrujeme to, že se v programu nevyskytují chyby.“1 Avšak tato definice není zcela správná. Testování programu dává produktu přidanou hodnotu, zvyšuje jeho konkurenceschopnost a možnost jeho využití. Tím, že budeme dokazovat bezchybnost systému, nikdy nebudeme efektivně testovat. Produktu přidáme hodnotu pouze tím, že budeme chyby hledat a následně opravovat a tím a vlastně dokazovat, že program není bezchybný. Testování systému je proces hledání chyb v co největším počtu - „Testování je proces procházení programu s úmyslem najít chyby.“2 Lidé se rádi orientují na nějaký cíl a jeho stanovení má pro ně významný psychologický efekt. Je-li naším cílem prokázat, že program nemá žádné chyby, potom budeme podvědomě řízeni ke splnění tohoto cíle a budeme mít tendenci vybrat takové testy funkčností, které mají nízkou pravděpodobnost selhání programu. Jestliže je však naším cílem ukázat, že program má chyby, bude existovat vyšší pravděpodobnost, že chyby nalezneme. Testování je ve své podstatě vlastně destruktivní proces a většina lidí ho proto shledává jako náročnou disciplínu. Většina lidí má spíše konstruktivní, nikoli destruktivní pohled na život. Lidé mají spíše sklony k tvorbě než k rozbíjení nějakých objektů na části a nalézání jejich nedostatků. Dalším psychologickým jevem, kterým můžeme lépe pochopit podstatu testování programu, je správná analýza a použití slov "úspěšný"

a

"neúspěšný".

Zejména

jejich

použití projektovými

manažery při

vyhodnocování výsledků exekuce testovacích případů. Většina projektových manažerů nazývá testovací případ, kde nebyla nalezena žádná chyba jako úspěšný test. Zatímco test, který objevil novou chybu, je obvykle nazýván jako „neúspěšný“. To však není zcela správná definice. Slovo "neúspěšný" označuje něco, co je nežádoucí nebo co nesplnilo svůj účel. Při správném způsobu pochopení testování, správně navržený a provedený test je úspěšný, pokud zjistí chyby, které mohou být opraveny a nebo když zjistíme, že neexistují žádné další chyby. Jediný neúspěšný test je ten, který není správně navrhnut a který neotestuje software tak, jak by měl.

1

Myers, G. J.; The ART of SOFTWARE TESTING, 2.nd ed.; Word Association, Inc.: New Jersey, 2004, s. 5.

2

Myers, G. J.; The ART of SOFTWARE TESTING, 2.nd ed.; Word Association, Inc.: New Jersey, 2004, s. 6.

- 13 -

4. ZÁKLADNÍ POJMY Tato kapitola popisuje základní pojmy v oblasti procesu testování software, jejichž znalost je důležitá, chceme-li se pohybovat v prostředí, které popisuje problematiku programového testování. V této práci jsou použity mnohokrát a bez jejich znalosti může být způsob interpretace chybný.

4.1 Softwarová chyba V obyčejném životě můžeme na něco ukázat a říci, že je to chyba. To samé můžeme aplikovat i v oblasti testování, ale v praxi to samozřejmě není takto jednoduché a proto je potřeba v první řadě správně definovat pojem chyba. Dokument, který může poměrně výrazně změnit pohled na to, co je chyba, nazýváme specifikace produktu. Specifikace je dohoda mezi dodavatelem a zadavatelem, popisuje chování systému, jeho funkčnosti a zejména to, co bude dělat a co dělat nebude. Tato dohoda může mít různé podoby, od ústní až po psaný dokument [5, s. 13]. O softwarové chybě mluvíme tehdy, jestliže: 

Software nedělá něco, co by podle specifikace produktu dělat měl,



Software dělá něco, co by podle specifikace dělat neměl,



Software dělá něco, o čem se produktová specifikace nezmiňuje,



Software nedělá něco, o čem se produktová specifikace nezmiňuje, ale měla by se zmiňovat,



Software je obtížně srozumitelný, těžko se s ním pracuje, je pomalý, nebo – podle názoru testera softwaru – jej koncový uživatel nebude požadovat za správný. Vysvětlili jsme si pojem softwarová chyba, ale proč vznikají a co jejich příčinou?

Jako první se nabízí nejjednodušší možná příčina, která vyplývá z logiky testování – chyba je způsobena selháním aplikace. Pravda je však jiná, největší podíl nalezených chyb můžeme přičíst především chybám ve specifikaci [5, s. 14].

- 14 -

Obrázek 1: Příčiny vzniku chyb

Zdroj:[5] Vlastní zpracování

4.2 Kvalita software Metodika RUP definuje kvalitu jako určitou úroveň uspokojení potřeb uživatelů systému. Protože každý uživatel má jiné požadavky a očekávání a není možné stanovit tuto úroveň jednotně, byl definován rozšířený seznam parametrů – dimenze kvality. Někdy bývají dimenze souhrnně označovány FURPS. Jednotlivé dimenze jsou následující [4]: 

Funkčnost – správná funkčnost produktu dle funkční specifikace,



Použitelnost – jaké úsilí musí uživatel vynaložit při práci s produktem, jestli je uživatelsky přívětivý – dobře se s ním pracuje,



Spolehlivost – definuje chování produktu v různých nestandardních situacích – celková robustnost systému



Výkon – jak se produkt chová při souběžné práci více uživatelů, kolik systémových zdrojů odebírá atd.,



Podporovatelnost – zda lze produkt bez problémů nainstalovat, zda dokáže dobře spolupracovat s novými verzemi určitých komponent atd. [7] - 15 -

Často se můžeme v oblasti testování setkat s názorem, že kvalita je spolehlivost produktu, což je však chybná úvaha. Jestliže program dosáhne úrovně, že je vysoce stabilní, důvěryhodný a spolehlivý, nemůžeme ještě v žádném případě tento produkt označit jako vysoce kvalitní. Tím, že je produkt spolehlivý, jsme ověřili jen jednu část celkového pohledu na kvalitu. Kvalita je tedy souhrnem vlastností a charakteristik výrobku, procesu nebo služby, který ukazuje jeho schopnost splnit určené nebo odvozené potřeby.3

4.3 Verifikace a validace Pojmy, které úzce souvisí s kvalitou, jsou mimo jiné také verifikace a validace. Verifikaci můžeme chápat jako činnost, jenž má za cíl potvrdit, že produkt vyhovuje specifikaci. Na druhou stranu validace sleduje, jestli je produkt v souladu s požadavky uživatele. Na první pohled se můžou zdát tyto pojmy velmi podobné, přesto je zde významný rozdíl. Pro lepší pochopení slouží následující příklad: Začátkem roku 1990 byl na oběžnou dráhu vypuštěn Hubbleův zrcadlový teleskop. Testování zrcadla bylo velice obtížné, na zemském povrchu se nedal natočit a nedalo se s jeho pomocí pozorovat. Proto se v rámci testů pečlivě proměřily všechny atributy a výsledky se porovnaly se specifikovaným zadáním. Po těchto testech byl teleskop schválen a vypuštěn do kosmu. Po uvedení do provozu se zjistilo, že teleskop vrací neostré obrázky. Zrcadlo bylo vybroušeno přesně podle specifikace, ale tato specifikace byla nesprávná. Zrcadlo bylo mimořádně přesné, ale nebylo správné. Testování ověřilo, že teleskop vyhovuje specifikaci – provedla se jeho verifikace, ale nebylo možné potvrdit, zda vyhovuje původním požadavkům – nebyla provedena validace těchto požadavků na výsledném produktu.4

3

PATTON, Ron. Testování softwaru. s. 42

4

Testování SW [online]. 2012 [cit. 2012-04-24]. Dostupné z WWW: < https://unicornuniverse.eu//>.

- 16 -

4.4 Testovací plán Testovací plán (občas se používá také pojem Globální testovací plán – viz RUP) je dokument, který obsahuje informace o všem, co je potřeba definovat v rámci přípravy testů. Jeho rozsah je široký a měl by popsat všechny subjekty, které do testování zasahují a které by mohly být v rámci procesu řešeny [5, s. 211]. Správný plán testování by měl obsahovat: 

Zdroje – Detailní popis rolí/osob, které budou na projektu pracovat, definice jejich úkolů a specifikace komunikačních kanálů. Nedílnou součástí by mělo být přesné popsání úložiště sdílených dokumentů a dalších nezbytných souborů, které budou na projekty použity. Může se například jednat i o testovací hardware, jeho úložiště, přístupová povolení atd. Obecně lze tuto část využít i jako základní informace pro nové členy týmu, základní overview, které nezbytně potřebují ke své práci [5, s. 214],



Definice pojmů – Slovník alespoň nejdůležitějších výrazů popisující jejich přesný význam a chápání na daném projektu u daného klienta. Jedna z nejdůležitějších částí dokumentu, jelikož správné a stejné chápaní pojmů je jednou z hlavních podmínek při kooperaci. Musíme si uvědomit, že na projektech bývá zainteresována veliká řada různých rolí, s různými zkušenostmi a jejich výklad může být rozdílný, což může mít fatální následky [5, s. 214],



Vzájemné povinnosti mezi skupinami – Popisuje povinnosti mezi skupinami, které spolupracují na projektu a mohou mít vliv na testovací práce. Práce samotného testovacího týmu je podřízena mnoha dalším týmům – programátorům, analytikům, správcům prostředí atd. Zvláště ve velkých vývojových týmem musí být této části věnována velká pozornost [5, s. 215],



Co se bude a nebude testovat – Může se stát, že nebude nutné testovat všechny části produktu, jelikož byly např. otestovány dříve, nebo byly otestovány dodavatelskou společností. V procesu plánování je proto potřeba popsat každou komponentu a určit, zda bude testována či nikoliv. Při rozhodnutí, že se daná komponenta nebude vůbec testovat, je nutné definovat z jakého důvodu a kdo je za toto rozhodnutí kompetentní [5, s. 217],

- 17 -



Testování v jednotlivých fázích vývoje – Při plánování jednotlivých fází vývoje je nezbytné analyzovat navržený model vývoje a určit, jaké typy testů budou v průběhu vývoje probíhat. Tato část je závislá na metodice vývoje, čili nelze obecně určit, jaké typy testů a kdy je vhodné použít. Je nezbytné každý typ testování přesně popsat a ukázat projektovému týmu. Zároveň je nezbytné určit kritéria, za kterých se do jednotlivých fází vstupuje a za kterých se z nich vystupuje (tzv. entry a exit kritéria) [5, s. 217],



Strategie testování – Popisuje postupy, kterými bude testovací tým software testovat. Musí obsahovat popis celkového plánu testování a zároveň definici testů v jednotlivých fázích vývoje. Jedná se o rozhodnutí, jakým způsobem a jakým typem testů bude software ověřen. Jaké nástroje budou použity atd. Této části plánování by měla být věnována zvláštní pozornost, jelikož je na ni závislý úspěch celého testování. Ve většině případů obzvláště na větších projektech jde o samostatný dokument [2, s. 40],



Pověření testerů – Jestliže už jsou vyřešeny požadavky na prostředí a je určena strategie testování, můžeme přiřadit oblasti jednotlivým členům projektu, kteří se budou testováním zabývat (Tester) [5, s. 218],



Časový plán testů – Návrh časového plánu testů vychází z dosud zjištěných informací a je promítnut do celkového plánu postupu prací na projektu. Jedná se zřejmě o nejkritičtější část plánování testů. Důležitým parametrem je rozdělení objemu testovacích prací, jelikož ty nejsou v celém životním cyklu projektu rozděleny rovnoměrně. Toto plánování je důležité i z kapacitních důvodů, jelikož řeší i jednotlivé alokace. Jedná-li se o větší projekt a na testování je potřeba velké množství testerů, je kriticky důležité přesně naplánovat jejich využití [5, s. 219],



Testovací případy, skripty a scénáře – obsahuje seznam testovacích případů, skriptů a scénářů, podle kterých bude aplikace ověřena – vychází z funkční specifikace [5, s. 220],



Zprávy o chybách – Popisuje způsob, jakým způsobem budou nalezené chyby reportovány. Tato část je velmi variabilní a na každém projektu se můžete setkat s jiným uspořádáním. Základem by měl být nástroj, který slouží k zaznamenávání

- 18 -

chyb. Dále je důležité určit způsob, jakým se bude chybám přidělována závažnost [5, s. 221], 

Metriky a statistiky – Jedná se o prostředky k měření a sledování průběhu testování. Během procesu plánování musíme přesně identifikovat všechny parametry, které budeme sledovat a určit rozhodnutí, které budeme na základě jejich vyhodnocení provádět. Mezi testovací metriky patří celkový počet chyb za jeden den testů, seznam otevřených chyb, rozdělení chyb dle závažnosti, počet úspěšně dokončených testovacích skriptů a počet skriptů, které nemohly být dokončeny s určením důvodu [5, s. 221],



Rizika a problémy – Jedná se o soupis potenciálních problémů a rizik, které by mohly v průběhu testování nastat a které by mohly mít významnější dopad na výsledek testů [5, s. 221].

4.5 Testovací případ Testovací případ (test case) popisuje, jak postupovat při testování daného požadavku. Podrobně definuje, jak otestovat požadovanou funkčnost, jaké parametry mají být zvoleny na vstupu a jaké by se nám měly vrátit na výstupu. Podle normy ANSI/IEEE 829 dokumentuje testovací případ skutečnou hodnotu vstupů spolu s očekávanými výsledky. Testovací případ by měl také popisovat veškerá omezení v procesu testování, vyplývajících z určitého testovacího případu. Každý testovací případ by měl obsahovat tyto náležitosti [13]: 

Identifikátor – Jedinečný identifikátor odkazující na specifikaci návrhu testů a specifikaci testovacích procedur,



Testovaná položka – Popis testované funkce. Tento popis by měl být podrobnější, než je uvedeno v testovacím plánu. Dále je zde uveden např. odkaz na specifikaci produktu, či jiné dokumenty spojené s testovacím případem,



Specifikace vstupů – V této části jsou definované všechny vstupy nebo podmínky, které před provedením testovacího případu do programu vložíme,

- 19 -



Specifikace výstupů – Zde jsou definované všechny výsledky, které jsou očekávané po provedení testovacího případu,



Požadavky na prostředí – Tato část popisuje vše, co je k provedení testovacího případu potřeba. Může se jednat o software, hardware, uživatele, služby atd.,



Zvláštní požadavky – V této části jsou uvedeny všechny ostatní neobvyklé parametry, které jsou nutné provádět před nebo při samotném testování.

4.6 Testovací skript Testovací skript je v podstatě postup, jak se bude určitý testovací případ vykonávat. Testovací skript je realizace testovacího případu za použití konkrétních specifikovaných dat. Testovací skript krok za krokem definuje způsob, jakým je testovací případ prováděn. Nedílnou součástí testovacího skriptu jsou následující informace [12]: 

Identifikátor – Jedinečný identifikátor odkazující na testovací případ a návrh testů,



Účel – Pro jaký účel skript vznikl a k jakému testovacímu případu se váže,



Zvláštní požadavky – Jiné procedury a postupy, dovednosti nebo zvláštní vybavení, které je při vykonávání skriptu potřeba,



Kroky skriptu – Detailní popis způsobu provádění testů.

Testovací skript může obsahovat následující části, které již nejsou zcela nezbytné: 

Záznam – Definuje, jakou metodou a jakým způsobem se budou výsledky testu zaznamenávat,



Příprava – Určuje, co je potřeba připravit k testu,



Zahájení – Popisuje, co všechno je potřeba k zahájení testu,



Skript – Popis jednotlivých kroků s postupem testování,



Měření výsledků – Způsob určování výsledků,



Předčasné zastavení – Popisuje kroky pro přerušení testu z důvodu neočekávané chyby,



Obnovení – Určuje, jak má tester postupovat při přerušení testu a jak má pokračovat,

- 20 -



Ukončení – Definuje kroky pro ukončení testu,



Úklid – Popis kroků pro obnovu prostředí pro další testy,



Mimořádná opatření – Způsob jak postupovat v případě, kdy testy neprobíhají podle plánu.

Podoba testovacích skriptů se v praxi velmi liší. Forma jedné z možnosti, jak sestavit takový skript ukazuje obrázek 2.

Obrázek 2: Test skript Systém:

Datum provedení: Tester:

Projekt: Funkční oblast: Identifikátor: Název scénáře: Autor: Datum: Délka testu:

Verze aplikace: Poznámka:

Účel 1 2

Zvláštní požadavky 1 2

Testovaný tok: Typ Krok Popis kroku číslo

Vstupní data

Očekávané výsledky

->TESTER PROVÁDÍ AKCI

->TESTER KONTROLUJE VÝSLEDEK

Komentáře

Záznam ("P"=OK, "N"=chyba, "X"=nemožno provést)

1

Zdroj: vlastní zpracování

4.7 Testovací scénář Návrh testů nebo testovací scénář je složen z testovacích případů, které na sebe logicky navazují a musí být vykonávány v určitém pořadí. Struktura testovacího scénáře se

- 21 -

může podobat struktuře Specifikace požadavků, jelikož cílem by mělo být pokrytí všech požadavků testovacími případy. Struktura návrhu může mít následující podobu [11]: 

Testované vlastnosti – Jedná se o soupis požadavků, které by měly být testy pokryty,



Přístup k testování – Každý z přístupů vyžaduje jinou dovednost. Mezi tyto přístupy patří zejména způsob testování (black, white nebo grey box) a různé typy testů (Unit testy, integrační atd.),



Testovací skripty - určuje testovací skripty, které jsou použity ve scénáři,



Kritéria – Obecně definuje kritéria, za jakých můžeme prohlásit, že test prošel či nikoliv.

- 22 -

5. TYPY TESTŮ 5.1 Viditelnost zdrojového kódu Obrázek 3: Rozdělení testů z hlediska zdrojového kódu

Zdroj: [11] Vlastní zpracování

5.1.1 Black box – Testování černé skříňky Testování černé skříňky znamená, že testujeme, aniž bychom v podstatě viděli kód aplikace. Nevíme přesně, jak daná aplikace funguje, jen sledujeme, jak reaguje na naše vstupy. Tento typ testování se také často nazývá testem chování, jelikož ověřujeme, jak se aplikace chová v interakci s uživatelem. Abychom mohli testovat účinně, potřebujeme specifikaci aplikace, abychom věděli, jak se má v určitých momentech chovat. Nepotřebujeme vědět, co se děje uvnitř. Obecně můžeme říct, že tyto testy jsou charakteristické tím, že se chováme jako běžný uživatel [3, s. 50]. 5.1.2 White box – Testování bílé skříňky Testování bílé skříňky se provádí tím způsobem, že vidíme a máme přístup k programovému kódu a můžeme jej kontrolovat. Často se nazývá strukturální testování, jelikož při návrhu a samotné exekuci testů využíváme podkladovou strukturu kódu programu. Tyto informace jsou běžnému uživateli nepřístupné. Výhodou je, že tester může lépe odhalit vznik chyby a může předvídat slabá místa aplikace [6, s.141]. 5.1.3 Grey box – Testování šedé skříňky Později vznikl i další typ testu dle přístupu – šedá skříňka. Jedná se o střed mezi černou a bílou skříňkou. Tester sleduje chování aplikace, ale má k dispozici i nějakou část

- 23 -

zdrojového kódu. Bývá to např. algoritmus výpočtu funkce, matematické principy využité v aplikaci atd. [4]

5.2 Rozdělení dle způsobu Obrázek 4: Rozdělení testů z hlediska způsobu

Zdroj: [10] Vlastní zpracování

5.2.1 Statické testování Tento způsob testování je specifický tím, že se jedná o testy produktu, který není spuštěný. Netestujeme jednotlivé funkčnosti za běhu aplikace, ale prohlížíme ji a revidujeme. Můžeme revidovat specifikaci, zdrojový kód atd. Výhodou je, že lze začít testovat ještě před vyvinutím prvního funkčního prototypu [10]. 5.2.2 Dynamické testování Jedná se o testování aplikace za běhu. To znamená klasické testování funkčností a reakcí na vstupy uživatele [10]. 5.2.3 Automatizované testování Tam, kde testování aplikace nevyžaduje významný podíl lidského úsudku a funkčnost se nemění na rozdíl od zadávaných vstupních parametrů, lze použít libovolný nástroj, který zvládne automatizovaně otestovat část aplikace. K tomu je potřeba programově napsat, co se má otestovat, s jakými vstupními parametry a spustit test. Automat projíždí aplikaci a výsledkem je předem definovaný report s chybami, které automat odhalil. Je tedy potřeba mít testovací nástroj, vstupní a výstupní data a hlavně testovanou aplikaci, která podporuje skrze své rozhraní automatizaci procesů. Nejběžnější použití automatizovaných testů je - 24 -

v zátěžových testech, ale dají se v zásadě použít i v jiných oblastech [9]. „Automatizované nástroje pro testování nemohou v žádném případě testery softwaru nahradit – pouze jim pomáhají odvádět jejich práci snáze a lépe.“ 5 Výhody AT: 

Velmi nízké náklady na provoz,



Absence lidské chyby,



Možnost testovat velké množství vstupů a výstupů,



Není zde časový limit (může pracovat celý den),



Paralelnost.

Nevýhody AT: 

Vysoké vstupní náklady na pořízení,



Potřeba zkušených obsluhujících pracovníků,



Tvorba testů je časově náročná.

5.2.4 Manuální testování Standardní testování uživatelem, který využívá svého úsudku zkušeností a intuice. Výhodou je, že uživatel může lépe reagovat na vzniklé situaci, přesněji vyhodnotí slabá místa aplikace a nevyžaduje před testy tolik příprav jako automatizované testy. Na druhou stranu však jeho výsledky mohou být dost subjektivní, není to stroj, takže je možné, že opomene otestovat nějakou funkčnost a v některých případech nemusí zcela porozumět problematice daného testu, čímž může snížit jeho kvalitu [11]. Výhody MT: 

Obecně jednoduchost,



Není potřeba drahých nástrojů,



Ve většině případů jsou dostačující méně zkušení pracovníci.

5

PATTON, Ron. Testování softwaru. s. 186

- 25 -

Nevýhody MT: 

Relativně časově náročné



Náklady na testování rostou lineárně s počtem testerů



Limitované množství variant testů

5.3 Rozdělení dle času Rozdělením dle času rozumíme rozklad na určité úrovni podrobnosti. To znamená testování v určité fázi životního cyklu, ve které se aplikace právě nachází. Podle toho dělíme časové testy do pěti základních úrovní [10]. Obrázek 5: Rozdělení testů z hlediska času

Zdroj: [10] Vlastní zpracování

5.3.1 Testování jednotek Unit testy přichází na řadu po té, co programátor ověří kód. Testují se zde třídy a jednotlivé metody. Jednotku chápeme jako izolovanou část aplikace. Test je napsán ve formě programového kódu a na bázi frameworku. Tyto testy jsou velice důležité, jelikož chybu odhalíme v počáteční fázi a tím snižujeme pravděpodobnost zvýšení nákladů v budoucnu [7]. 5.3.2 Integrační testování Testy integrace jsou prvními v pořadí, které probíhají uvnitř testovacího týmu. Ověřuje se komunikace a funkčnost mezi jednotlivými komponentami a to jak uvnitř aplikace, tak i mezi hardwarem. Jedná se o test komponent, které byly otestovány izolovaně, a je třeba otestovat jejich součinnost [7]. - 26 -

5.3.3 Systémové a integrační testování Po otestování jednotlivých komponent přichází na řadu testování systému jako celku. Aplikace je testována z pohledu uživatele. Testy jsou navrženy tak, aby simulovaly práci běžných uživatelů. Většinou jsou tyto testy naplánovány na více kol, z důvodu možnosti retestů. Systémové testy jsou posledními testy před předáním aplikace zákazníkovi, jedná se tedy o jakousi výstupní kontrolu aplikace. Hovoříme o nejdůležitějších testech, které nechybí téměř v žádném procesu testování. Jednotlivé typy testů používaných v této fázi [10]: 

Function tests – Tento typ testů ověřuje, jak přesně systém vykonává funkce, které jsou od něj očekávány. Předmětem těchto testů je typicky reakce na uživatelské příkazy, práce s daty, uživatelské obrazovky s integrací s okolními systémy atd.



Performance tests – K těmto testům je vydefinováno určité množství požadavků s určitými parametry a je sledována odezva a výkon aplikace. Slouží k naplánování a optimalizaci využití aplikace v ostrém provozu. Velký význam má stejně jako Stress testy hlavně při testování webových aplikací, kde počet uživatelů vysílajících požadavky, může být několik tisíc v jeden okamžik,



Security tests – Spočívá v testu ochrany před neautorizovanými požadavky, dále se může jednat o ukládání hesel, jejich dostupnost, šifrování atd.,



Smoke tests – Test základních funkčností programu, provádí se před hloubkovým testem a ověřuje se, že v aplikaci není žádná kritická chyba, která by znemožnila otestovat významnější část komponenty.



Regresní testy – Ověření, že nebyla chyba zavlečena tam, kde v minulosti nebyla. Jedná se v podstatě o test těch funkčností, které buď již byly testovány, nebo které nebyly aktuálně vyvíjeny,



Inkrementální testy – Jedná se o testy, které se provádějí po přidání nového modulu k již otestovaným modulům,



Recovery tests – Testy na ověření, za jak dlouho se aplikace vzpamatuje po svém pádu. Ten může být způsoben např. výpadkem proudu, hardwarovou chybou atd.,



Stress tests – Velké množství většinou automaticky vygenerovaných požadavků testují, že aplikaci v případě chvilkového zahlcení nehavaruje. Může být podpořeno omezením zdrojů (paměti, výkonem atd.).

- 27 -

5.3.4 Akceptační testování UAT jsou realizovány v prostředí zákazníka. Jedná se o testy, ve kterých si zákazník ověří funkčnost aplikace. Předem je připraven seznam testovacích případů, které jsou poté procházeny. Je důležité definovat způsob zadávání chyb a zajistit rychlé řešení a opravu nedostatků aplikace. Většinou bývá definováno, za jakých podmínek zákazník aplikaci převezme – akceptační kritéria. Typy testů používaných v této fázi [10]: 

Alpha tests – tento typ testů je prováděn ve vývojovém (testovacím) prostředí, neprovádí ho samotní vývojáři,



Beta tests – podobné jako Alpha testy, avšak probíhají v prostředí zákazníka,



Akceptační tests – Testuje zákazník a ověřuje, že se aplikace chová dle specifikace i v jeho prostředí.

- 28 -

6. TYPY TESTOVÁNÍ 6.1 Testování konfigurace Jedna z překážek bezproblémového vývoje software je fakt, že aplikace pracuje ve většině případů na různých konfiguracích svého prostředí. Samozřejmě existuje software, který je vyvíjen pouze na určitou konfiguraci a podpora pro jiné typy neexistuje. Těch je však velmi málo a hlavně v poslední době se rozšířil pojem webová aplikace, kterou využívají miliony lidí po celém světě s naprosto rozdílnou konfigurací zařízení. Testování konfigurace je tedy proces, při němž ověřujeme chování určitého software nad různými typy komponent hardwarového charakteru. Předmětem kapitoly jsou hlavně [5, s. 109]: 

Komponenty – Téměř všechny počítače jsou tzv. modulární. To znamená, že se skládají z různých systémových desek, komponentních karet a dalších interních zařízení. Těmi mohou být např. diskové jednotky, zvukové a grafické karty, modemové a síťové karty atd. Všechny tyto druhy komponent vyrábějí stovky různých výrobců,



Periferie – V tomto případě např. tiskárny, monitory, kamery, klávesnice, myši atd.,



Rozhraní – Komponenty a periferie jsou připojeny pomocí různých rozhraní, např. PS/2, USB, SATA, eSATA, zásuvka pro připojení do sítě (LAN) atd.,



Ovladače zařízení – Komponenty a periferie komunikují se aplikacemi pomocí modulů nízké úrovně – ovladače zařízení. Dodavatelem těchto ovladačů je většinou výrobce hardware a instalují se po připojení komponenty k PC. Jestliže máme zájem testovat konfiguraci, je nejdůležitější naplánovat, jaké části

z konfigurace budou mít největší dopad na běh aplikace. Je určitě rozdíl v tom, jaké komponenty využívá grafické studio a např. software pro tisk vizitek. Jak však zjistit, že se jedná o chybu konfigurace? Existuje v podstatě jen jediný způsob. Vyzkoušet nasimulovat tuto chybu na zcela jiné konfiguraci. Když se chyba nevyskytne na jiném zařízení, jedná se s největší pravděpodobností o chybu konfigurace. A naopak, pokud je chyba nasimulována na více konfiguracích, jedná se zřejmě o chybu softwarového typu.

- 29 -

6.1.1 Postup při testování konfigurace Základní věcí v oblasti přípravy testů konfigurace je zjištění všech relevantních informací, které jsou k dané aplikace dostupné. Je nutné zjistit, které komponenty aplikace využívá, s čím měli například vývojáři problém a kde vidí potenciální riziko. Následující postup může vypadat takto [5, s. 115]: 

Určíme, jaký typ hardwaru budeme k testům využívat. Většina aplikací, bude pravděpodobně využívat monitor jako zobrazovací zařízení. Ale existují různé velikosti, různá rozlišení obrazovky atd.



Zjistíme, jaké typy, značky a verze hardwaru a jaké ovladače jsou na trhu. Tuto informaci by ve skutečnosti neměl zjišťovat tester. Ve většině případů si zadavatel určí konfigurace, na kterých si přeje aplikaci provozovat. Toto je velice důležitá informace v procesu vývoji software. Vždy by měl vývojový tým vědět, na kterou konfiguraci aplikaci vyvíjí. Je totiž vždy nemilým překvapením, když zákazník zjistí, že si kvůli svému novému produktu musí pořídit úplně nové stroje, protože jeho hardware je zastaralý.



Zjistíme, jaké funkce, režimy a nastavení hardware umožňuje. Je důležité vědět, jaké máme možnosti konfigurace. Např. monitor má různé hloubky barev, tiskárna rozdílné typy tisků a diskové jednotky více rychlostí zápisu.



Naplánování počtu a typů množin konfigurací. S ohledem na počet verzi ovladačů a nastavení se vyberou ty konfigurace, které je testovací tým schopen za určitou dobu otestovat. Za jistých okolností lze testovat konfiguraci i v rámci např. systémových testů, kde každý tester bude testovat určitou oblast na jiné konfiguraci.



Identifikujeme takové funkce aplikace, které pracují s hardwarovou konfigurací. To znamená, že nebudeme testovat všechny funkčnosti na dané konfiguraci, ale zjistíme, jaké oblasti aplikace vyžadují ke své práci hardware určitého nastavení. Jestliže testujeme např. rychlost ukládání velkého objemu dat na disk, nebudeme při nastavení konfigurace věnovat pozornost grafické kartě ale diskové jednotce.

- 30 -



Navrhneme testovací případy nad každou konfigurací. Navrhneme takové případy, které pokryjí otestování dané funkčnosti nad zvolenými konfiguracemi. Nebudou se v zásadě lišit od klasických systémových testů, avšak ve většině případů budou obsahovat jen jejich část.



Opakovat testy dokud nebudou výsledky v souladu se zadanými kriterii.

6.2 Testování kompatibility Test kompatibility odhalí, do jaké míry je produkt schopný pracovat s jiným systémem. Tyto testy jsou velice důležité a vývoj aplikací je dnes vlastně postaven na tom, že aplikace při svém běhu komunikuje s několika dalšími systémy ve svém okolí. Z vlastní zkušenosti vím, že např. v bankovním sektoru je několik desítek aplikací, které spolu musí navzájem komunikovat, a při testování je velmi obtížné identifikovat, jestli se jedná o chybu aplikace nebo kompatibility. V důsledku je to sice chyba, avšak je nutné analyzovat, co chybu způsobilo. Test kompatibility zahrnuje např. [5, s. 123]: 

Načítání dat z externího zdroje,



Využívání různých okolních aplikací pro výpočet složitějších algoritmů,



Komunikaci mezi aplikací a operačním systémem,



Migraci dat mezi systémy.

Mezi základní otázky, které je potřeba si při plánování testů kompatibility klást patří: 

Jaké jiné platformy (např. webový prohlížeč, operační systém atd.) mají být s testovaným programem kompatibilní? Zároveň jestliže je objekt našich testů sám platformou, jaké ostatní aplikace mají pod ním dle zadání fungovat?



Jak je definována komunikace (rozhraní) mezi aplikacemi, které mají být kompatibilní?



Jaké typy dat budou při komunikaci s jinými aplikacemi využívány a jaké typy sdílených dat aplikace využívají? Výběr samotné platformy a verze aplikace není stejně jako v testech konfigurací ve

většině případů úkolem testera. Za to je zodpovědný hlavně ten, jenž dobře zná koncové uživatele a zároveň má přehled o tom, jaké platformy aplikace využívají. Typicky by tuto - 31 -

úlohu měla na projektech zastávat role Test architekta a tyto informace by měly být součástí specifikace. Každá aplikace má svoje vlastní kritéria a obecně lze říci, že z pohledu řízení projektů se vždy snažíme o co možná nejmenší množinu aplikací, které budou s programem v interakci. Což je například v oblasti telekomunikací a bankovnictví problém. V oblasti testování kompatibility hovoříme o dvou typech testů – dopředná a zpětná kompatibilita. Dopředná kompatibilita znamená, že software je schopný spolupracovat s novými verzemi aplikací a zpětná kompatibilita definuje, do jaké míry je software schopný spolupracovat se staršími verzemi aplikací [5, s. 124]. 6.2.1 Postup při testování kompatibility Analýza stávajících standardů a zásad, které můžeme považovat pro testovaný software či platformu jako závazné. Tato analýza se dá rozdělit do dvou úrovní a to na standardy vyšší a nižší úrovně. Standardy vyšší úrovně popisují aplikaci jako celek, popisují splnění požadavků produktu. Zejména jeho vzhled, podporované funkce atd. Naproti tomu standardy nižší úrovně představují detailnější informace - formáty dat, popisují protokoly atd. Standardy vyšší úrovně definují, pod jakým operačním systémem aplikace poběží, v jakém prohlížeči aplikace funguje atd. Popisuje spíše obecné vlastnosti aplikace v závislosti na kompatibilitě. Standardy nižší úrovně jsou z hlediska úspěšnosti v podstatě důležitější než standardy vyšší úrovně. Jestliže není dodržen vyšší standard, software ve většině případů nedostane např. certifikát o kompatibilitě s určitou platformou. Ale nemusí to mít žádný vliv na jeho funkčnost. Ale v případě standardu nižší úrovně je situace jiná. Jestliže není dodržen standard nižší úrovně, může nastat problém v komunikaci na základní úrovni funkcí aplikace a tím pádem v kompatibilitě s ostatními systémy. Představte si aplikaci pro mobilní zařízení na libovolné platformě. Jestliže tato aplikace nesplňuje standardy vyšší úrovně, znamená to např., že funkční tlačítka mají jiný vzhled, než je standard dané platformy, avšak fungují zcela v pořádku. Avšak jestliže nesplňuje aplikace standardy nižší úrovně, znamená to, že např. ukládá soubory ve formátu, který není podporovaný, což je ovšem z funkčního hlediska zásadní problém. Všechny možné varianty testů kompatibility je nutné rozdělit do testovatelné množiny na základě zdrojů - 32 -

a možností a je nutné opakovat testy, dokud nebudou výsledky v souladu se zadanými kriterii [5, s. 127].

6.3 Testování použitelnosti Jedním z hlavních důvodů, proč jsou aplikace vyvíjeny, má být jejich přidaná hodnota v určité oblasti. Software by měl ve většině případů ulehčit práci, popřípadě zpřehlednit a zefektivnit pracovní postupy. Tomu, že aplikace splňuje tato kritéria, říkáme použitelnost. Jistě, nikdo nechce vyvíjet něco, co by nebylo použitelné, ale praxe je ve skutečnosti trochu odlišná. Technologickým parametrům programového kódu je někdy věnováno příliš pozornosti a v důsledku toho se často zapomíná na to hlavní – že s programem bude někdo pracovat a bude ho používat [5, s. 147]. 

Uživatelské rozhraní Jedná se o souhrn prvků, pomocí nichž komunikujeme se softwarovou aplikací.

Většina programů má uživatelské rozhraní. Je to v podstatě místo, kam zadáváme vstupy a přebíráme výstupy. S pojmem uživatelské rozhraní je často spojována ergonomie. Tento pojem je dosti široký a jeho definice je daleko za hranicemi této problematiky, ale v tomto spojení ji můžeme chápat jako definici něčeho, co je pohodlné a lehce dostupné. Přesně takové by mělo být uživatelské rozhraní. 

Dobré uživatelské rozhraní Dodržuje určité standardy nebo zásady. Tím, že aplikace dodržuje standardy nebo zásady je velice pravděpodobné, že má dobré uživatelské rozhraní. 

Intuitivní Znamená to, že je uživatelské rozhraní zřetelné a není příliš zahlcené. Nikdy by se nemělo stát, že rozhraní bude překážet v práci, že bude uživatele omezovat. Vše by se mělo nacházet tam, kde to uživatel intuitivně očekává.



Konzistentní Jeden z klíčových parametrů produktu. Pojem konzistence označuje něco, co lze použít i v jiných aplikací, co dodržuje předem stanovené standardy a co uživateli ulehčí práci v novém prostředí. Většina uživatelů pracuje s operačním - 33 -

systémem Windows. Jedním ze způsobů, jak demonstrovat konzistenci uživatelského rozhraní je například pravé tlačítko myši. V konzistentním rozhraní je tímto tlačítkem vyvoláno kontextové menu daného objektu s funkcemi jako kopírovat, smazat atd. Dalším příkladem jsou např. klávesové zkratky. 

Flexibilní Takové rozhraní by mělo nabízet dostatek možností volby, ale ne zase příliš mnoho, aby nedošlo ke zmatení uživatele



Pohodlné Samotná práce s aplikací by měla být pohodlná, neměla by být pro uživatele obtížná. Aplikace nesmí uživateli znesnadňovat práci a nesmí překážet. Tento parametr je však velmi subjektivní.



Správné To znamená, že rozhraní dělá to, co by dělat mělo. V praxi by tedy měly všechna tlačítka dělat to, k čemu jsou naprogramována a neměla by odkazovat nikam, kam to uživatel nepředpokládá.



Užitečné Uživatelské rozhraní by mělo mít užitečné funkce, to znamená takové, které opravdu uživatel využije ke své práci. To, že aplikace obsahuje zbytečné a nevyužívané funkce prodražuje jak programování, tak samotné testování.

6.4 Testování webových aplikací Testování webových aplikací v sobě zahrnuje všechny typy testů, které jsou výše popsány. Testování konfigurací, testování kompatibility a testování použitelnosti. Stejně jako v lokálních aplikacích tak i webové aplikace obsahují objekty, které mají určité parametry a reprezentují funkčnosti, pro které byly vytvořeny. Je zde však jeden základní rozdíl, který není na první pohled zcela patrný, a tím jsou ony standardy. Zatímco většina klasických aplikací běží pouze na platformě Windows a nepotřebuje ke svému zobrazení jiné programy, webové aplikace jsou omezeny a podléhají zobrazení v prohlížeči. Je nutné - 34 -

připomenout, že týmy, které vyvíjí prohlížeče, nevycházejí se stejných standardů a proto vývoj takových aplikací je o něco složitější. To samé lze tvrdit i o samotném testování. Je důležité si uvědomit, že v dnešní době jsou webové aplikace, co se týče funkčnosti téměř na stejné úrovni jako lokální aplikace. Proto jsou testy webových aplikací složitější, jelikož komunikují vesměs přes vzdálené servery a uživatel využívá ke komunikaci s nimi jen tenkého klienta – prohlížeč. Tím rapidně vzrůstá počet potenciálních chyb [5, s. 167]. 6.4.1 Testování konfigurace a kompatibility 

Hardwarová platforma – V dnešní době je nespočet možností přístupu k webovým aplikacím (PC, chytrý telefon, tablet, notebook atd.),



Software prohlížeče a jeho verze – každý z prohlížečů podporuje trochu jiné funkce, má odlišné vlastnosti při zobrazování obsahu, odlišně pracují s externími aplikacemi a jsou různě podporované. Mezi nejznámější prohlížeče můžeme zařadit Internet Explorer, Mozilla Firefox, Google Chrome, Opera, Safari atd. Problémem jsou i jejich verze, které v poslední době vycházejí poměrně často,



Zásuvné moduly prohlížečů – téměř do všech prohlížečů lze doplnit řadu zásuvných modulů (plug-in), které zajišťují další doplňkové funkce, jako přehrávání videa, stahování a přehrávání hudby,



Volby prohlížeče – prohlížeče nabízejí nepřeberné množství nastavení,



Rozlišení obrazovky a hloubka barev – prohlížeče lze nastavit na různé typy rozlišení a hloubku barev,



Velikost textu – problematická oblast zejména v kombinaci s rozlišením obrazovky,



Rychlost připojení – některé aplikace se stávají nepoužitelné s nedostatečnou rychlostí připojení.

6.4.2 Testování použitelnosti 

Bezdůvodné používání technologií – zbytečné používání technologií, které nejsou nutné k funkčnímu provozu, vede k prodražení projektu a může také v konečném důsledku odradit uživatele. Zvláště složitější typy nejnovějších technologií jsou citlivé - 35 -

na nastavení prohlížeče, a v případě, že uživatel není schopný si sám toto nastavení nakonfigurovat, vzniká problém, 

Dlouhé rolující stránky – uživatelsky nepřívětivé, vše důležité by se mělo nacházet navrchu zobrazené stránky. Je vhodné rolování minimalizovat,



Příliš dlouho časy odezvy – Jeden z největších problémů. V dnešní době informačních systémů jako webových aplikací je čas odezvy základní parametr. Při delších odezvách se prodražuje práce uživatele a celkově se stává aplikace nepoužitelná.

Samotné testování není tolik rozdílné od testování klasických lokálních aplikací. Z vlastní zkušenosti však mohu potvrdit, že v oblasti testování webových aplikací je mnohem větší chybovost a identifikace chyb je daleko složitější s ohledem na prohlížeče, operační systémy a rychlosti připojení [5, s. 177].

- 36 -

7. BUSINESS TESTOVÁNÍ Business testovací tým, ve kterém v tuto chvíli působím, se začal formovat poměrně nedávno. V době mého začlenění do testovacího týmu byl v podstatě na svém počátku a já jsem měl jedinečnou možnost být součástí vzniku testovacího oddělení, jak se říká na „zelené louce“. Mnohé jsem se naučil a načerpal zkušenosti, které budu využívat v budoucnu a které bych jinde získával velmi těžko. Tato část práce bude pojednávat o vytvoření business testování jako samostatné jednotky a všech důležitých aspektech, které vedly k tomu, že tento tým již nějakou dobu úspěšně zastřešuje testování na business oddělení. Součástí výstupů je i optimalizace procesů, které souhrnně popisuje návrh testovacího plánu a strategie projektu BETA. Na samém začátku je důležité představit prostředí, ve kterém business testovací tým vznikl. V první řadě je důležité připomenout, že se jedná o jeden z největších bankovních domů v České republice, jehož struktura organizace je poměrně složitá. Pokusím se o zjednodušený pohled. Stejně jako v klasickém zakázkovém vývoji software, stojí i zde proti sobě zadavatel (klient) a zhotovitel (IT). Jako zadavatel v tomto případě vystupuje Business oddělení, které specifikuje svoje požadavky, sbírá informace od okolních oddělení a vytváří funkční požadavky. Tyto podklady poté přenese do IT oddělení, kde dochází ve velmi zjednodušené podobě ke schválení, či zamítnutí jednotlivých požadavků. Přijaté požadavky jsou IT naimplementovány a poté otestovány. Business ve velmi omezené míře prováděl free testy nových funkčností. To byl však zcela nepřijatelný fakt. I v obyčejném životě je naprosto přirozené, že zákazník je ten, kdo dané produkty vyzkouší, než si je koupí. To samé by mělo platit i při vývoji software. A proto bylo vyhodnoceno jako žádoucí, aby víceméně podobný testovací tým, jakým disponovalo IT, vznikl i na straně Businessu.

7.1

Záměr

Z výše popsaného je jasné, že důvodů, které vedly k myšlence založit testovací tým na straně zákazníka (Business), byla celá řada. Také nedostatků, které doprovázely proces testování business oddělením, bylo mnoho. Těmi se ale budeme zabývat později, teď si - 37 -

vysvětlíme, co vlastně vedení očekávalo od vytvoření testovacího týmu. V každém případě to byla optimalizace a formalizace procesů do té doby prováděných business testů a zlepšení jejich výstupů. Do této doby nebyla v business testech definována přesná pravidla, nebyly vyhotoveny téměř žádné formální dokumenty k zaznamenávání a vyhodnocování testovacích případů. Dalším přínosem mělo být vymezení jednotlivých rolí, které se budou na testech podílet a hlavně definice oblastí, za kterou budou mít určité role zodpovědnost. Bez přesného vymezení, kdo za co zodpovídá, nemá nikdo kontrolu nad tím, jestli všechny testy opravdu proběhly, což je při zpětné revizi a vyhodnocení problém. Součástí optimalizace mělo být i převedení zodpovědnosti za faktickou realizaci business testů z útvaru IT do Business oddělení. Tyto myšlenky měl nový testovací tým splnit a zásadně tak transformovat přístup k testům.

7.2

Business testovací tým

Nejdůležitější částí projektu business testování bylo vytvoření stabilního testovacího týmu. Bylo nutné definovat jednotlivé role a určit jejich odpovědnosti a jejich funkce, které k nim nedomyslitelně patří. V procesu business testování je využito mnoho externích zdrojů k nastavení určitých prostředí a služeb, ale ty nejsou definovány jako součást testovacího týmu. Mezi nejdůležitější role v tomto týmu patří Business Test leader, Business Test koordinátor, Business Test analytik a Business tester. Náplň jejich práce je různorodá, avšak můžeme obecně tvrdit, že tyto role by měly řídit a vykonávat aktivity zachycené v tabulce 1. V rámci definování testovací strategie je nutné začlenit testovací tým do struktury projektu. Jelikož na testování participuje celá řada externích rolí, je potřeba definovat např. kontaktní osoby, podporu ze strany IT při samotných testech a precizní naplánování termínu testů z důvodů odstávky určitých služeb atd. – to vše by mělo být v testovacím plánu.

- 38 -

Tabulka 1: Aktivity členů business testovacího týmu

Definice scope testů Analýza změnových požadavků Vytváření testovacích případů Detailní příprava business testů Zapracování změnových požadavků Definice dat použitých při testech Definice celkové testovací strategie Exekuce testovacích případů Analýza objevených chyb Provedení testů Komunikace s externími dodavateli Řešení problémů v průběhu testování Zaznamenání výsledků testu jednotlivých oblastí Souhrnné statistiky za definované období Report výsledků testů a Report nalezených chyb

objevených chyb

Řízení životního cyklu chyb Kooperace při řešení chyb Analýza priorit jednotlivých testovacích případů Určení kritických oblastí Průběžná revize business testů a testovací dokumentace

Aktualizace testovací dokumentace Aktualizace testovacích případů Inovativní přístup pří řešení business testů Zdroj: Vlastní zpracování

- 39 -

7.3 Definice kompetencí rolí Tabulka 2: Definice kompetencí

Provádění testů Zaznamenávání průběhu testů Business Tester

Příprava dat Hlášení chyb Retest opravených chyb Vytváření testovací strategie Analýza a sumarizace testovacích požadavků

Business Test analytik

Návrh testů – testovacích skriptů Vytváření testovacích skriptů Specifikace podmínek pro testy Návrh testů – testovacích skriptů Koordinace testů v průběhu

Business Test koordinátor

Koordinace reportovaných chyb Report výsledků jednotlivých oblastí Koordinace přípravy testovacích skriptů Řízení členů týmu

Business Test leader

Komunikace s externími subjekty Schvalování výstupů Zdroj: Vlastní zpracování

7.4 Pilotní provoz business testovacího týmu Při vzniku business testovacího týmu byl zvolen Projekt Alfa jako pilotní pro spuštění procesu business testování. Na straně businessu je zapotřebí vytvořit testovací strategii a dokumenty k testování. V této fázi jsou testovací scénáře pro nové funkčnosti vytvářeny zejména Gestory, nebo Business analytiky daných oblastí. Regresní testy a k nim přidružené testovací skripty, jsou vytvářeny novou rolí – Business Test analytikem.

- 40 -

V rámci vývoje předchozích verzí aplikace, které zajišťuje projekt Alfa, probíhalo testování pouze na straně IT a bylo nedostatečně ověřeno zadavatelem – Business oddělení. Toto bylo v rozporu s metodikou testování, jelikož jako UAT bylo prohlášeno poslední kolo IT testů. Business neměl tedy reálnou představu o tom, v jakém stavu se aplikace nachází. Další věcí, která stála za myšlenkou vytvoření stálého business testovacího týmu, byl fakt, že testovací skripty vznikaly sice na straně businessu, avšak oddělení IT si je poté aktualizovalo a nastavilo tak, aby vyhovovali jejich pohledu na testy. Z tohoto důvodu poté vznikaly problémy, které vyústily v to, že business neměl v žádném případě kompletní přehled o pokrytí požadavků testovacími skripty. Také se stávalo, že pohled obou stran se významně lišil, což poté způsobovalo neefektivní řešení jednotlivých chyb, probíhaly dlouhé debaty o tom, jestli nalezené nedostatky jsou chybou či nikoliv. V neposlední řadě nebyly definovány žádné role, které by měly za jednotlivé skripty zodpovědnost. To způsobovalo problémy při řešení nesrovnalostí, které vznikaly mezi aplikací a testovacími podklady. Toto všechno a fakt, že formální proces business testování byl realizován ve většině případu pouze free testy, které měli na starosti hlavně gestoři jednotlivých oblastí, byl důvod k tomu, proč se vedení banky rozhodlo založit zcela nový business testovací tým, který bude participovat na všech důležitých projektech.

- 41 -

7.5 Přínosy business testů na projektu Alfa Tabulka 3: Přínosy projektu Alfa Přínos pro projekt Alfa

Popis Testovací tým bude mít určitý počet stálých členů,

Navýšení kapacit pro průběh

kteří budou alokovány pouze na business testování.

testování

Nebude nutné před každými testy alokovat nové testery. Business Test analytik Business tester

Zavedení nových rolí

Business Test leader Business Test koordinátor Jednotlivý testeři budou mít zkušenosti s danou

Zvýšení produktivity samotných

oblastí. Navíc nebudou zatěžovány žádnými jinými

testů

úkoly, jako to bylo v případě zaměstnanců businessu dříve.

Efektivní revize a úprava testovací dokumentace

Testovací tým bude mít po testech čas revidovat a následně upravovat testovací dokumenty. Dříve v podstatě žádná testovací dokumentace nebyla. Nebude tolik závislý na dodávce dat z oddělení IT.

Vymezení odpovědnosti za přípravu V co největší míře budou data vytvářena samotným testovacích dat

testovacím týmem. Tím se sníží riziko nedodání požadavků na data ve stanovený čas. Jeden ze zásadních přínosů. Do této doby byly

Rozšíření UAT o regresní testy

UAT pouze free testy nových funkčností.

Kompletní a permanentní podpora pro business testování

Snížení pracovní zátěže ostatních pracovníků Businessu

Ostatní členové oddělení businessu budou nadále spolupracovat na projektech, avšak budou mít již širokou škálu podpory od testovacího týmu. Do této doby testovali za business zaměstnanci, kteří to neměli primárně v popisu práce. Tím se snižoval jejich výkon v ostatních oblastech.

Zdroj: Vlastní zpracování - 42 -

7.6 Průběh testů projektu Alfa Průběh business testů odpovídal standardním fázím klasických UAT. Bohužel se z časových důvodů fáze přípravy testovací dokumentace a samotné testování aplikace prakticky překrývaly, což mělo za následek snížení kvality provedených testů. Docházelo tím pádem k problémům, které však byly očekávané a na které se tým mohl předem připravit. Pozitivní je, že tým dokázal reagovat na skutečnosti, které nastaly, a přizpůsobil podle toho své zaměření. Tyto skutečnosti budou v konečném důsledku sloužit jako podklad k vylepšení a zefektivnění testů v dalších projektech a zkušenosti z toho plynoucí budou zaznamenány a použity při revizi a následné optimalizaci jednotlivých procesů. Tabulka 4: Stav jednotlivých fází UAT Úspěšně dokončené fáze

Popis Testovací plán business testů byl dokončen i se všemi

Plán business testů

náležitostmi definovanými s projektovým managementem V rámci analýzy bylo přesně vydefinováno testovací

Analýza a příprava business testů

prostředí, byla určena testovací data a dokončeny testovací scénáře

Realizace business testů

Testy byly dokončeny ve stanoveném čase Na základě statistik exportovaných z nástrojů k tomu

Vyhodnocení business testů

sloužících bylo vyhotoveno vyhodnocení a předáno vedení projektu V průběhu testování docházelo ke správnému

Reportování chyb

reportování chyb a následnému řešení oddělením IT

Nedokončené fáze

Popis

Revize procesů testování a testovací dokumentace.

V tuto chvíli není zcela ukončena revize procesů testování na projektu Alfa. Zároveň musí dojít ke kompletaci testovací dokumentace

Zdroj: Vlastní zpracování

- 43 -

V rámci plánování testů byla sestavena matice oblastí, které byly přiděleny jednotlivých testerům. V tabulce pět je uveden počet jednotlivých datasetů definovaných ke každé oblasti. Dataset je testovací případ s určitým datovým setem. Datových sad ke každému testovacímu případu může být libovolné množství. Nedostatkem tohoto rozdělení je absence informace o počtu skriptů v jednotlivých oblastech. V praxi jsou v průběhu testů oblasti rozdělovány podle jejich aktuálního stavu. V dolní části tabulky je zachyceno testování konfigurace. Každý tester má přidělenou určitou konfiguraci, kterou otestuje jedno testovací kolo. V dalších kolech jsou stanice pro testy prohozeny tak, aby se každá oblast otestovala na co nejvíce různých konfiguracích. Tabulka 5: Rozdělení oblastí mezi jednotlivé testery UAT

Tester 1

Oblast 1

Tester 2 X

Oblast 2 Oblast 3

X

X

X

Oblast 9

X

Oblast 11 X

X

X

X

X

X

Oblast 13

X

Oblast 14

X X X

X

266 X

X

X

X

69 X

Oblast 16

X

X

Oblast 17

X

36 14

X

150 X

X

Oblast 18

X

Oblast 19

X

65 X

X

Oblast 21

X X W7 IE7

VISTA Chrome 10

1.6.24

1.6.24

X

X

X

X

XP

MAC

Opera 11.6 1.6.24

77 X

15

X

248 120

XP

W7

Firefox 5

LINUX Chrome 10

IE8

Firefox 8

1.6.24

1.6.24

1.6.24

1.6.24

Zdroj: Vlastní zpracování

- 44 -

101 98

X X

58 211

X

X

155

41

X

Oblast 15

12 32

X

X

85

89 X

X

Počet datasetů

42

X

X

Oblast 10

Java

X

X X

Prohlížeč

Tester 7

26

X

Oblast 8

Oblast 22 Operační systém

Tester 6

X

X

Oblast 7

Oblast 20

Tester 5

X

Oblast 6

Oblast 12

Tester 4

X

Oblast 4 Oblast 5

Tester 3

7.7 Zaznamenané problémy v průběhu testů Tabulka 6: Problémy v průběhu testů Problém v průběhu testů

Popis

Kapacitní problémy

V průběhu testů docházelo k výpadku plánovaného počtu kapacit (výměna členů týmu, školení, nemoc atd.) – 8% z celkového plánu.

Hardwarové problémy

Jednalo se zejména o výkonnostní problémy. Některé aplikace vyžadují více systémových zdrojů

Problémy s přístupovými právy

Dlouhá reakční doba na požadavek o založení přístupových práv - nižší efektivnost testování

Nedostatečné zkušenosti

Někteří členové testovacího týmu neměli dostatečné zkušenosti a vědomosti. Postupem času došlo ke zlepšení.

Testovací nástroje

Nesprávné používání bug-tracking nástroje – chyby ve workflow

Retesty chyb

Retesty chyb nebyly provedeny včas – prodlevy v testech kvůli častým migracím

Nasazování hotfix a patche

Časté nasazování hotfix a patche v průběhu testovacího dne – 5,5% celkového času (nejsou zde zahrnuty plánované odstávky jednotlivých služeb)

Nedostatečná a neaktuální dokumentace

Týkalo se hlavně regresních testů, bylo často složité nalézt informaci o správném fungování aplikace

Nedostatečná komunikace

Komunikace mezi členy Businessu a IT nebyla korektně nastavená a neprobíhala v dostatečné míře

Testovací data

Výrazné problémy s připravenými daty ze strany IT – některé dodány až v průběhu druhého kola testů (dohromady testována tři kola)

Nedostatek času

Nedostatek času ve fázi plánování a přípravy testů

Know-how

V původním plánu nebyl vyhrazen dostatečný časový úsek na převzetí know-how , což mělo vliv na kvalitu počátečních výstupů – v průběhu zlepšení Zdroje: Vlastní zpracování

- 45 -

7.8 Chyby nalezené v průběhu business testování Chyby, které tester při provádění samotného testu objevil, reportoval v nástroji JIRA. Tento nástroj má svoje předdefinované workflow upravené dle potřeby projektu, chyba je tedy efektivně řešena v co nejkratším čase. Po opravě je vrácena zpět na testera, který musí provézt retest a případně chybu zavřít nebo vrátit zpět k analýze. Obecně je důležité objevit kritické chyby co nejdříve, aby se stihly včas opravit a následně ověřit. V rámci všech tří kol bylo zadáno celkem 615 chyb z toho 340 označených jako uznané. Tabulka 7: Souhrn přijatých chyb za business testování

UAT

Blocker (A!)

Critical (A)

Major (B)

Minor (C)

Trivial (D)

Celkový součet

Oblast 1

2

6

9

6

27

48

Oblast 2

0

0

1

1

2

1

Oblast 3

1

1

2

2

1

1

Oblast 4

1

1

2

2

1

2

Oblast 5

1

0

2

2

5

8

Oblast 6

0

0

6

6

39

42

Oblast 7

0

1

6

12

14

32

Oblast 8

3

6

11

15

30

66

Oblast 9

5

11

21

38

19

96

Oblast 10

0

1

11

23

13

48

Oblast 11

0

3

2

2

0

7

Celkem

13

30

73

109

151

340

Zdroj: Vlastní zpracování

Zamítnuto bylo 275 chyb z toho 29 duplicitních, není rozlišeno, jestli pouze mezi business týmem, nebo v souvislosti s IT testy. Dalších 49 z nich bylo opraveno souběžně se zadáním chyby a 67 z různých důvodů nebylo označeno jako chyba a byly zavřeny. Z celkového

počtu

zamítnutých

chyb

bylo

30

zadáno

z důvodů

chyby

ve

skriptu a 30 vyplynulo ze špatného pochopení testovacího skriptu. Nakonec celých 70 chyb bylo reportováno kvůli chybě dat nebo testovacího prostředí.

- 46 -

7.9 Vyhodnocení Vytvořením business testovacího týmu došlo k nezávislému testování projektu Alfa druhým týmem. Na to, že se jednalo o první projekt tohoto týmu a časový úsek pro přípravu byl velmi krátký, můžeme hovořit o úspěchu. Cíle, které si vedení založením business testovacího týmu stanovilo, byly ve větší míře splněny. Je však ještě spousta úkolů, které se musí dokončit, ale obecně se pilot označil jako úspěšný. Problém je hlavně v tom, že testovací tým musí být zaměřen na více druhů aplikací a tudíž i více projektů s jinými procesy. Navíc některé projekty, které jsou v harmonogramu testů, se téměř překrývají. Z toho důvodu je potřeba kupříkladu připravit testovací data dopředu, což zvyšuje riziko znehodnocení těchto dat. V rámci pilotních testů nedošlo ani k překrývání zaměření IT a business testů, což dokazuje počet nalezených chyb v UAT, které nejsou duplicitní. Tento potenciální problém byl velmi diskutovaný, ale naštěstí v praxi se nepotvrdil, což jen potvrzuje, že snaha o vytvoření těchto testů byla správná. Samozřejmě se během tohoto projektu vyskytla celá řada problémů, které byly nečekané a které se musely poprvé řešit. Avšak s tím se počítalo a nebyla plánována kritická hranice objemu testů. Závěrem lze konstatovat, že zkušenosti z tohoto provozu byly dále využívány na dalších projektech a výsledkem je návrh testovacího plánu a strategie pro projekt Beta v další části práce. Tabulka 8: Vyhodnocení pilotu

UAT

1.kolo 2.kolo 3.kolo

Pokrytí testů

Úspěšnost ověřených testů

Úspěšnost ověření nových funkčností

2 261

62%

78%

42%

170

2 805

78%

91%

72%

90

2 972

82%

98%

76%

Počet zadaných chyb (všech)

Počet provedených skriptů

355

Zdroj: Vlastní zpracování

- 47 -

7.10 Shrnutí a další postup Po vyhodnocení testů začal proces zpětné revize testování a testovací dokumentace projektu Alfa, v níž byly zahrnuty všechny nedostatky, které byly během testů objeveny. Tabulka 9: Postup pro optimalizace procesů Další postup pro zefektivnění procesů business testování Revize testovacích scénářů a testovacích dat Optimalizace testovacích scénářů a skriptů Revize dokumentace Analýza oblastí k automatizovaným testům Nastavení obecných pravidel a metrik UAT, které budou společné pro testy všech projektů, do kterých se testovací tým zapojí Jednotlivé odchylky budou součástí všech testovacích plánů pro jednotlivé projekty Eliminace chyb uvedených v kapitole „Zaznamenané problémy v průběhu testů“ Definice přesného složení testovacího týmu, jeho velikost a zastoupení jednotlivých rolí Převzetí tvorby dat od strany IT – kritická oblast při samotných testech Zdroj: Vlastní zpracování

- 48 -

8. TEST PLÁN A STRATEGIE PROJEKTU BETA Tato část práce popisuje naplánování testů a testovací strategie pro projekt Beta na základě zkušeností z pilotního provozu business testů na projektu Alfa. Smyslem této části je optimalizace procesů business testování a celkové zvýšení efektivity testů. Při sestavování plánu byla brána v úvahu fakta, která vyplynula z analýzy po vyhodnocení pilotního business testování. Z těchto analýz se vychází v podstatě až do dnešní doby a jsou zdrojem optimalizačních procesů každého projektu, na kterém se business testovací tým podílí.

8.1 Úvod Cílem této části práce a obecně testovacího plánu a strategie je popsat podmínky, vstupy a hlavní strategii testování, v tomto případě projektu Beta. Jeho úkolem je poskytnout ucelený pohled a zajistit konzistenci informací o charakteru testování, což je jeho hlavní prioritou. Vydefinovat role, harmonogram a důležité informace, které bude projekt ve fázi testování vyžadovat. Testování projektu Beta zahrnuji i free testy business týmem v průběhu vývoje. Projekt Beta se zabývá vývojem jednoho z přímých kanálů bankovního domu, kterým je v tomto případě internetové bankovnictví. V rámci společnosti se jedná o velmi náročné testování. Jenom počet testerů se na obou stranách (Business, IT) pohybuje kolem čtyřiceti. Celý vývojový tým pak alokuje stovky členů. Jak již bylo v této práci popisováno, největším problémem testů webových aplikací je konfigurace. Uživatel přistupuje skrze tenkého klienta, kterým je prohlížeč. Těch je však na trhu celá řada a jejich verzí nespočet. Dalším důležitým faktorem je typ operačního systémů. Proto ve fázi plánování je kriticky důležité definovat konfigurace a poté počet testerů. Pro lepší orientaci je důležité nastínit procesy v rámci životního cyklu projektu Beta. Business oddělení předá požadavky svým analytikům, kteří na jejich základě vypracují business specifikace. IT analytici tyto specifikace zpracují a upraví do takové podoby, podle které je možné aplikaci navrhnout a vyvíjet.

- 49 -

8.2 Harmonogram testů Tabulka 10: Harmonogram testů Datum

Popis

červenec 2012

Zahájení Business free testů

prosinec 2012

Start IT testů - Integrační, performance a End to End testy

únor 2013

Zahájení UAT testů

březen 2013

Ukončení UAT testů (rezerva)

březen 2013

Nasazení v rámci projektu Beta Zdroj: Vlastní zpracování

8.2.1 Free testy V rámci jednotlivých etap vývoje projektu Beta bude možnost otestovat vyvinuté komponenty. Takto bude mít Business možnost zkontrolovat a v případě nesrovnalostí připomínkovat ty oblasti, které jsou označeny jako dokončené. K tomuto účelu je zvolen free test, zvolený jako nejefektivnější. Není nutné vytvářet podrobné testovací skripty a scénáře, tester bude testovat dle business dokumentace. IT vždy po každé iteraci vývoje dodá specifikaci, v níž bude definovaná funkčnost, která bude k dispozici pro testy. Nedílnou součástí ukončení každé iterace bude finální iterační porada, na které bude vývojový tým prezentovat komponenty, které jsou již vyvinuty. Při demonstraci funkčnosti přímo v aplikaci na schůzce se můžou business analytici obrátit s připomínkami přímo na vývojáře dané oblasti. Komponenta, která bude předmětem prezentace, bude k dispozici na testovacím prostředí dva dni před plánovanou schůzkou. Určené role provedou na tomto prostředí free test dle business dokumentace v maximální rozsahu čtyř hodin a nalezené chyby budou reportovat prostřednictvím nástroje JIRA. Role, které provádí free testy, se poté zúčastní samotné prezentace. 8.2.2 Další důležité informace Jako podklad pro free testy bude sloužit business a IT dokumentace (funkční specifikace) a další výstupy z IT testů. Testování bude probíhat izolovaně, nebude možno testovat všechny logické komponenty v dané oblasti, které ještě nejsou vyvinuty. Zároveň nebude možné otestovat plně ty funkčnosti, které kooperují s jinými službami. Prostředí nebude - 50 -

napojeno na externí služby v průběhu free testů. Výsledky těchto free testů nebudou v žádném případě brány jako formální akceptace ze strany Businessu. 8.2.3 Příprava dat V souvislosti s přípravou dat je důležité stanovit termín, do kterého dodá IT informace o tom, jaké typy dat bude k free testům potřeba a jaký bude předpokládaný objem. Business testovací tým zanalyzuje požadavky a určí, jaká data je schopen připravit sám a která bude nutné vytvořit na straně IT. Poté budou data dodána i s informacemi o jejich využití a všemi náležitostmi. Jakmile budou data dodána, bude mít Business čas na to, aby tyto data zrevidoval a případně vrátil zpět k přepracování. Za testovací data po schválení ponese odpovědnost Business.

8.3 Zahájení UAT Zahájení UAT je z hlediska harmonogramu projektu naplánované únor 2013. O jejich zahájení však bude rozhodovat aktuální stav aplikace, zvláště výsledek IT testů. Jestliže bude aplikace funkční a bez chyb je předběžně počítáno s tím, že v případě zahájení UAT bude na IT plná podpora pro business testy. V případě problémů s dodávkou, to znamená, že aplikace nebude funkční do té míry, aby mohla být převzata do UAT, bude stanoven určitý čas k opravě otevřených chyb. Tento čas bude definován na posledním setkání zástupců obou stran po analýze výsledků z IT testů. O tento čas budou zároveň UAT testy prodlouženy. O zahájení testů rozhoduje Business Test manažer společně s ředitelem Business oddělení. 8.3.1 Příprava dat na UAT Business Test analytici, kteří připravují testovací skripty, vydefinují testovací data, která budou k průběhu UAT potřeba. Výsledek se poté zanalyzuje s nutností přesné definice, co je možné založit na Businessu bez zatěžování IT. Tato data se připraví a zrevidují v průběhu přípravy. Ostatní požadavky na data, která není testovací tým schopen připravit

- 51 -

vlastními silami, budou odeslána na IT, kde proběhne jejich příprava a vrátí se zpět k následné kontrole. 8.3.2 Průběh UAT Testy jsou naplánované na tři testovací kola s předem definovanou délkou. Standardně je tato doba fixně nastavena na sedm dní s tím, že toto platí pro první dvě kola. Poslední kolo bude mít variabilní počet dní s ohledem na začátek testů. To znamená, že může být zkrácenou nebo prodlouženo. V průběhu testů je však možné přehodnotit délku jednotlivých kol s ohledem na počet reportovaných chyb a dostupnost funkčností. 8.3.3 Další důležité informace k UAT Je nutné zajistit administrátorské oprávnění pro stanice, na kterých budou UAT probíhat. Kvůli požadavku na funkčnost aplikace na více konfiguracích je nutné po každém kole přeinstalovat operační systém. Dále bude důležité zajistit dostatek pracovních míst pro testery v případě, že stávající kapacity nebudou vyhovovat. Požadavek na administrátorské práva musí obsahovat vymezení odpovědnosti za rizika plynoucí z něj, dobu trvání povolení pro definované stanice a role, které budou zodpovědné za korektní nastavení testovacího prostředí na těchto PC. Veškeré instalační balíčky dodá před testy IT.

8.4

Zaznamenávání chyb

Zaznamenávání chyb bude probíhat v nástroji JIRA od společnosti Atlassian. Tento nástroj je dlouhodobě používaný na všech projektech a lze jej velmi lehce dle požadavků nastavit. Jedná se webovou aplikaci, ke které přistupují uživatelé přes prohlížeč. Test leader pošle požadavek na založení uživatelů do tohoto prostředí – pro nové členy testovacího týmu. 8.4.1 JIRA – nástroj pro evidenci chyb Bude definován požadavek na založení nového projektu Beta do prostředí nástroje. Každá chyba, která se bude reportovat, musí obsahovat určité parametry. Tyto parametry slouží k lepší orientaci a efektivnějšímu workflow. Mezi tyto vlastnosti patří hlavně název komponenty, za kterou má vývojář odpovědnost. Je nutné určit funkcionalitu, ve které se - 52 -

chyba nachází. Tento parametr slouží hlavně ke zvýšení kvality vyhodnocování chybovosti jednotlivých oblastí. Dalšími parametry, které by měly být součástí zadaných chyb, je jejich typ. To znamená, jaký má chyba charakter, dále verze aplikace a celková konfigurace, na které byla nasimulována. K chybě je vhodné přidat otisk obrazovky nebo informace ze souboru, který slouží k logování. Chyba by po založení měla být ihned přiřazena na koordinátora, který problém analyzuje a chybu buď pošle dále, nebo vrátí k doplnění. V případě, že chyba nemá odůvodnění, je tato chyba zavřena ihned. Není efektivní posílat na IT neexistující chybami. Zvláště u rozsáhlejších testovacích týmů může být podíl těchto chyb významný. 8.4.2 Závažnost chyb Tabulka 11: Závažnost chyb Blocker (A!)

Kritická chyba, bez její opravy není možné funkčnost použít

Critical (A)

Velmi závažná chyba, má zásadní vliv na funkčnost, avšak lze jí obejít

Major (B)

Závažná chyba, má vliv na funkčnost, ale neovlivňuje jí nějak zásadně

Minor (C)

Standardní chyba, nemá vliv na funkčnost, zejména grafické chyby

Trivial (D)

Chyba s minimálním dopadem na aplikaci, např. barvy objektů Zdroj: Vlastní zpracování

Chyby budou zpracovávány dle závažnosti IT stranou. Jednotlivé problémové oblasti a nejkritičtější chyby budou probírány každý týden na schůzce, kterého se zúčastní jak zástupci IT, tak i strany businessu.

8.5 Testovací skripty Testovací scénáře budou vytvářeny Business Test analytiky a gestory za jednotlivé oblasti. Bude vytvořen dokument, ve kterém budou popsány funkčnosti, které je nutné pokrýt v UAT. Za každý testovací skript a testovací scénář bude zodpovědný analytik, který by měl sledovat stav vývoje jednotlivých funkčností. Podkladem pro vývoj testovacích skriptů - 53 -

budou business dokumentace v předepsané podobě na společném úložišti, který bude definován při pravidelných schůzkách. Koordinaci vývoje scénářů má na starosti Business Test leader. Všechny skripty budou vyhotoveny v termínu určeném pro jejich přípravu. Jejich součástí bude i definice testovacích dat, které je nutné zajistit pro testování. Na základě výsledků přípravy skriptů bude poslán požadavek na vytvoření dat.

8.6 Testovací tým Velikost týmu pro UAT byla předběžně stanovena na čtyřicet až padesát testerů. Toto číslo však není konečné, po dokončení fáze přípravy scénářů se jednotlivé oblasti přepočítají časově a určí se finální počet. V případě najmutí externích pracovníků proběhne zaškolení, které zaštítí Business Test leader. Toto školení bude definováno a popsáno později v případě požadavku na jeho realizaci. Rozsah by měl být maximálně dva dny. Protože se projektu účastní více rolí, jejich kompetence jsou přesně stanoveny dle jejich náplně, jak ukazuje tabulka 12. Tabulka 12: Odpovědnost rolí Role

Odpovědnost na projektu

Test leader

Řízení testů, řízení koordinátorů, dohled nad přípravou test skriptů a dat, reporting

Test analytik/koordinátor

Psaní skriptů, koordinace testovacího týmu

Test koordinátor

Koordinace testovacího týmu

Test analytik

Psaní skriptů

Tester

Testování

Koordinátor přípravy skriptů

Zastřešení přípravy a psaní skriptů

Koordinátor evidence chyb z free testů

Koordinace zadávání chyb a vyhodnocování duplicit Zdroj: Vlastní zpracování

- 54 -

8.7 Akceptační kritéria – převzetí do UAT testů Business tým přijme aplikace do svých testů jen za splnění určitých podmínek. Zásadní je přitom počet otevřených chyb a celkový stav aplikace. Statistiky, které budou sloužit jako podklad pro zahájení UAT, budou dodány jako vyhodnocení IT testů. K tomu, aby byla aplikace přijata do UAT je nutná úplná a správná příprava testovacího prostředí. Bez něho nebude možné testy začít. Nedílnou součástí prostředí jsou i testovací data, které si bude tým revidovat před začátkem testů. Musí být přesně stanovený postup pro zadávání chyby, správně nastavené životní cyklus chyb včetně stanovení jejich koordinátorů. Statistiku a vyhodnocení systémových a integrační testů provede strana IT. Na schůzce bude probrán stav a učiněn formální zápis výstupů z IT testů. Součástí reportu bude seznam otevřených chyb. V případě dohody mezi oběma stranami nemusí být splněna podmínka na počet a typ otevřených chyb. V tom případě však musí být definováno, jakým způsobem a kdy budou tyto chyby opraveny. Tabulka 13: Maximální počet chyb k zahájení UAT Priorita

Popis

Maximální počet chyb

Blocker (A!)

Kritická chyba, bez její opravy není možné funkčnost použít

0

Critical (A)

Velmi závažná chyba, má zásadní vliv na funkčnost, avšak lze jí obejít

2

Major (B)

Závažná chyba, má vliv na funkčnost, ale neovlivňuje jí nějak zásadně

7

Minor (C)

Standardní chyba, nemá vliv na funkčnost, zejména grafické chyby

15

Trivial (D)

Chyba s minimálním dopadem na aplikaci, např. barvy objektů

20

Zdroj: Vlastní zpracování

8.8 Akceptace převzetí do technického pilotu Akceptace převzetí do technického pilotu proběhne na základě analýzy a vyhodnocení UAT testů. Kritérium na počet otevřených chyb může být přehodnoceno dle možnosti

- 55 -

oprav chyb během UAT testů. Předání do provozního pilotu proběhne podle předem stanoveného časového harmonogramu. Jestli nebude dodržen hrozí posunutí migrace na předem neurčený čas. Podmínkou akceptace je minimálně jedno úspěšně otestované kolo v UAT. Za úspěch se v tomto případě považuje jedno spuštění každého testovacího případu na prostředí, nebo bude potvrzeno, že byl úspěšně spuštěn ve fázi systémových testů. Níže je definovaný maximální počet chyb, které mohou být otevřeny. Aplikace musí splňovat předem definované parametry SLA a chyby, které nelze jednoznačně reprodukovat, nesmí vznikat častěji než jednou za padesát testovacích cyklů. Musí být stanoven termín opravy chyb a tyto chyby budou odstraněny do jednoho týdne po akceptaci. Podmínkou bude dohoda o podpoře pilotního provozu ze strany IT. Tabulka 14: Maximální počet chyb k zahájení pilotu Priorita

Blocker (A!)

Critical (A)

Major (B)

Minor (C)

Trivial (D)

Popis Kritická chyba, bez její opravy není možné funkčnost použít Velmi závažná chyba, má zásadní vliv na funkčnost, avšak lze jí obejít Závažná chyba, má vliv na funkčnost, ale neovlivňuje jí nějak zásadně Standardní chyba, nemá vliv na funkčnost, zejména grafické chyby Chyba s minimálním dopadem na aplikaci, např. barvy objektů

Maximální počet chyb 0

0

2

5

7

Zdroj: Vlastní zpracování

8.9 Vyhodnocení a ukončení testů Samotné vyhodnocení testů bude probíhat po ukončení UAT testů. V průběhu testů však budou k dispozici dílčí výsledky za jednotlivé dny a funkčnosti s podrobnou statistikou výstupů. Bude tedy možné flexibilně reagovat na vývoj testů a přizpůsobit se stavu aplikace. Vyhodnocení bude obsahovat hlavně informaci o tom, do jaké míry byly pokryty požadavky na testy. To znamená, jestli se otestovalo vše, co se mělo v rámci UAT - 56 -

otestovat. V případě, že nebude aplikace otestována na 100%, bude se nahlížet do výsledků IT testů. Jestliže nebude splněna tato podmínka, bude svolána mimořádná schůzka, kde se určí další postup. Součástí bude seznam otevřených chyb včetně trendové přímky jejich nalezení. Toto je důležité k identifikaci, je-li aplikace v čase méně chybová (chybovost má snižující se tendenci). Jestliže trend nebude klesat, bude se opět řešit na zvláštní schůzi, která bude dodatečně svolána. Posledním důležitým bodem vyhodnocení je stanovení kvality výstupů a doporučení dalších postupů. Na základě této informace se bude situace nadále řešit. Po skončení UAT testů budou data a prostředí ponecháno v aktuálním stavu, nebudou upravována či obnovována - z důvodů znuvupoužitelnosti.

- 57 -

9.

ZÁVĚR

Tématem bakalářské práce je „Popis procesů business testování a jejich optimalizace“. Hlavním cílem bylo představit a poté analyzovat procesy, které utvářejí samotné business testování a jeho výstupy. Další část měla být zaměřena na optimalizaci těchto procesů, což bylo představeno pomocí testovacího plánu a strategií projektu Beta. Ve své první části práce vysvětluje základní termíny a typy testů, které je potřeba k popisu procesů znát. Velmi důležitý s ohledem na samotnou realizaci procesů je přehled o dokumentech, které testovací tým používá při samotném testování. Jako cíl této části bylo poskytnutí uceleného pohledu na testování a základní charakteristiky business testování, což bylo nezbytné pro řešení problematiky ve druhé části této práce. Druhá a hlavní část práce je rozdělena na dvě oblasti. První se zabývá problematikou vytvoření business testovacího týmu v bankovním prostředí, analýzou a vyhodnocením pilotního projektu Alfa. Druhá oblast této části popisuje jeden z nejdůležitějších dokumentů ohledně testování – testovací plán a strategie. Tento plán jsem navrhl s ohledem na zkušenosti, které jsem získal z působení na projektu business testování. Celkově vychází z vyhodnocení pilotního projektu a jeho cíl je ukázat, jak se procesy v průběhu životního cyklu business testovacího týmu optimalizovaly. Začátky business testů znamenaly vytvoření nového testovacího týmu, definici rolí, kompetencí a úkolů pro jednotlivé etapy testování. V krátkém časovém úseku byly vytvořeny zcela nové testovací skripty a připraveny různé typy dokumentů pro evidování výsledků testů. Kvalitu těchto výstupů ověřil právě pilotní provoz na projektu Alfa. Projekt Alfa lze vyhodnotit jako úspěšný, vezmeme-li v úvahu časový prostor, který byl pro přípravu vyhrazen. Je nutné si uvědomit, že testeři neměli v podstatě žádnou zkušenost s procesy, které tento tým zavedl. Jeho složení bylo nestálé a bohužel docházelo k časté výměně členů. Mezi hlavní oblasti, které je nutné analyzovat a jejich procesy optimalizovat, patří zejména stálost testovacího týmu, neaktuální testovací dokumentace a v neposlední řadě vyhodnocení a zaznamenávání průběhu testu. Tento proces je podpořen nástrojem Microsoft Office a při větším počtu uživatelů s jinými verzemi aplikace vznikají chyby při používaní, které stojí testovací tým čas. V tomto případě stojí za úvahu pořízení specializovaného nástroje pro řízení a vyhodnocení průběhu testu. - 58 -

Na základě těchto skutečností byl navrhnut testovací plán a strategie pro projekt Beta. Při sestavování byly brány v potaz problémy, které vznikly při pilotním provozu business testovacího týmu na projektu Alfa. Projekt Beta řeší business testování webové aplikace – internetového bankovnictví. Výsledkem této části je ucelený pohled na testování z pohledu business oddělení. Se zkušenostmi z projektů v minulosti se optimalizace procesů business testovacího týmu projeví právě v této části práce. Výsledkem je porovnání a úspěšnost nastavení jednotlivých procesů mezi pilotním projektem Alfa a projektem Beta. Mezi úspěšně optimalizované procesy lze zařadit přípravu dat, která prošla velkou změnou od začátku působení business testovacího týmu. Většina dat je připravovaná v rámci tohoto týmu s minimem požadavků na stranu IT. Dalším důležitým optimalizovaným procesem je automatizované testování. Podařilo se nastavit tento proces do takové míry, že významná část testovacích případů je prováděna automatizovaně. Domnívám se, že i přes omezený rozsah, poskytuje tato práce ucelený pohled do problematiky business testovacího týmu v prostředí jedné z největších bank v České republice. Ukazuje, jak náročné je naplánovat tyto testy na velkých projektech, jakým je například vývoj internetového bankovnictví.

- 59 -

10. CONCLUSION In the first part this work explains the basic terms and types of tests that are necessary to describe the processes. Very important with regard to the actual implementation process is an overview of the documents that the test team used in the actual testing. Goal of this part was to provide a comprehensive view of testing and basic characteristics of the business testing, which was necessary to address the issue in the second part of this work. The second and main part is divided into two areas. The first deals with the introduction of the business test team in the banking environment, analysis and evaluation of the pilot project Alpha. The second area of this section describes one of the most important documents about testing - test plan and strategy. I proposed the plan with regard to the experience I gained from the operation of the business testing project. Overall, these documents are based on the evaluation of the pilot project and their objective is to show the optimization of the processes in the business team´s lifecycle. The beginnings of business tests meant to create a new test team, definition of the roles, responsibilities and tasks for each stage of testing. New test scripts and different types of documents for the recording of test results were prepared in a short time. The quality of these outputs was verified in pilot operation, which was project Alpha. Project Alpha can be evaluated as successful, if we take into the account the time for preparation. It should be noted that testers had almost no experience with the processes that were created by this team. Its composition was unstable and there was frequent exchange of the members, which should not help the continuous improvement of the results. The main areas to analyze and optimize their processes are stability of the test team, test-date documentation and finally evaluation and recording test run. This process is supported by the Microsoft Office and a larger number of users with different versions of an application caused increasing number of errors, which was time consuming for test team members. In this case it is worth considering acquisition of a specialized management tools during the test. Based on these facts the test plan and strategy for project Beta were designed. The design took into the account the problems that arose during the pilot operation on the project Alpha. The project Beta addresses the testing of the web applications - internet - 60 -

banking. The result of this section is a comprehensive look at the testing point of view of the business department. Based on experience from projects in the past, business process optimization takes effect in this part of the work. The result is a comparison of the successful settings of the pilot project Alpha and project Beta. The example of successfully optimized process is data preparation, which has undergone many changes since the beginning of the business activity of the test team. Testing data is prepared in the context of the team with the minimum requirements for the IT side. Another important process, which was optimized, is automated testing. We managed this process that a significant portion of test cases are done automatically. I believe despite the limited scope, this work provides a comprehensive insight into the problems of the test team in the business environment in the one of the largest banks in the Czech Republic. It shows how difficult is to plan these tests on large projects, such as the development of internet banking.

- 61 -

11. SEZNAM POUŽITÉ LITERATURY 1. MYERS, Glenford J. The ART od SOFTWARE TESTING. second edition.,2004. ISBN 978-0-471-46912-4. 2. DUSTIN, Elfriede. Effective software testing: 50 specific ways to improve your testing. Pearson Education, Inc., 2003. ISBN 0-201-79429-2. 3. KANER, Cem, Jack FALK a Nguyen HUNG QUOC. Testing computer Software. Second Edition. Canada: John Wiley & Sons, Inc., 1999. ISBN 0-471-35846-0. 4. KROLL Per, Philippe Kruchten, Paperback, Addison-Wesley Professional., ISBN10: 0321166094 5. PATTON, Ron. Testování software. First Edition. Praha: Computer Press, 2002. ISBN 80-7226-636-5 6. GAO, Jerry. Testing and quality assurance for component-based software. First Edition. Norwood: ARTECH HOUSE, INC., 2003. ISBN 1-58053-480-5. 7. IBM Rational Unified Process (RUP). [cit. 2012-04-15]. Dostupné z URL: <www.ibm.com/software/awdtools/rup/> 8. Testování software [online]. 2012 [cit. 2012-04-24]. Dostupné z URL: . 9. BLAŽOVÁ, Romana. TST Automatické testy : Přednáška pro předmět Testování software [online]. Publ. 20.04.2010 [cit. 2012-04-25]. Dostupné z URL: . 10. BLAŽOVÁ, Romana. TST KDO, CO a KDY v procesu testování : Přednáška pro předmět Testování software [online]. Přednáška. Publ. 02.03.2010 [cit. 2012-04-25]. Dostupné z URL: . 11. Testování software [online]. 2012 [cit. 2012-04-24]. Dostupné z URL: . - 62 -

12. Testovací skript : CleverAndSmart [online]. Edit. 18.02.2009 [cit. 2012-04-25]. Dostupné z WWW: . 13. Testovací případ : CleverAndSmart [online]. Edit. 14.02.2009 [cit. 2012-04-25]. Dostupné z WWW: .

- 63 -

12. SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK Zkratka

Popisek

ICT

Informační a komunikační technologie

ANSI/IEEE 829

Standard pro dokumentaci testů softwaru

UAT

User Acceptance Testing - důležitá testovací fáze projektu, ve které probíhá testování systému uživateli

PS/2

Šestikolíkový konektor pro připojení periférií k PC – myš, klávsesnice

USB

Universal Serial Bus - univerzální sériová sběrnice

SATA

Serial ATA (SATA) - používá se pro připojení vnějších datových zařízení

eSATA

Externí SATA - používá se pro připojení vnějších datových zařízení

LAN

Local Area Network - označuje počítačovou síť

SLA

Service Level Agreement - smlouva o garantované úrovni služeb

- 64 -

13. SEZNAM OBRÁZKŮ Obrázek 1: Příčiny vzniku chyb ................................................................................... - 15 Obrázek 2: Test skript ................................................................................................. - 21 Obrázek 3: Rozdělení testů z hlediska zdrojového kódu............................................... - 23 Obrázek 4: Rozdělení testů z hlediska způsobu ............................................................ - 24 Obrázek 5: Rozdělení testů z hlediska času .................................................................. - 26 -

- 65 -

14. SEZNAM TABULEK Tabulka 1: Aktivity členů business testovacího týmu ................................................... - 39 Tabulka 2: Definice kompetencí .................................................................................. - 40 Tabulka 3: Přínosy projektu Alfa ................................................................................. - 42 Tabulka 4: Stav jednotlivých fází UAT........................................................................ - 43 Tabulka 5: Rozdělení oblastí mezi jednotlivé testery ................................................... - 44 Tabulka 6: Problémy v průběhu testů........................................................................... - 45 Tabulka 7: Souhrn přijatých chyb za business testování ............................................... - 46 Tabulka 8: Vyhodnocení pilotu.................................................................................... - 47 Tabulka 9: Postup pro optimalizace procesů ................................................................ - 48 Tabulka 10: Harmonogram testů.................................................................................. - 50 Tabulka 11: Závažnost chyb ........................................................................................ - 53 Tabulka 12: Odpovědnost rolí ..................................................................................... - 54 Tabulka 13: Maximální počet chyb k zahájení UAT .................................................... - 55 Tabulka 14: Maximální počet chyb k zahájení pilotu ................................................... - 56 -

- 66 -