UNICORN COLLEGEprev.unicorncollege.cz/european-it-center/pavlicek... · testování ve velkých...

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.

- 5 -

Popis procesů business testování a jejich optimalizace

Description of the business testing processes and its optimization

- 6 -

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

- 7 -

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

- 8 -

OBSAH

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

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

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

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

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 -

5. Typy testů ................................................................................................................... - 23 -

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

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 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 -

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

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

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

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

- 9 -

6.2.1 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 -

7. 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 -

8. 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 -

- 10 -

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

9. 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 -

- 11 -

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.

- 12 -

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].

- 13 -

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.

- 14 -

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].

- 15 -

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]

- 16 -

Č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//>.

- 17 -

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],

- 18 -

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í

- 19 -

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,

- 20 -

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,

- 21 -

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í:

Projekt: Tester: Funkční oblast:

Verze aplikace:

Identifikátor: Poznámka: Název scénáře:

Autor: Datum: Délka testu: Účel

1 2

Zvláštní požadavky

1 2

Testovaný tok: Typ kroku

Krok číslo

Popis Vstupní data ->TESTER PROVÁDÍ AKCI

Očekávané výsledky ->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

- 22 -

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.

- 23 -

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

- 24 -

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


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

- 25 -

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

- 26 -

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


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].

- 27 -

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.).

- 28 -

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í.

- 29 -

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.

- 30 -

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.

- 31 -

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

- 32 -

ú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ů

- 33 -

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

- 34 -

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é

- 35 -

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é

- 36 -

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].

- 37 -

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

- 38 -

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.

- 39 -

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

Detailní příprava business testů

Definice scope testů

Analýza změnových požadavků

Vytváření testovacích případů

Zapracování změnových požadavků

Definice dat použitých při testech

Definice celkové testovací strategie

Provedení testů

Exekuce testovacích případů

Analýza objevených chyb

Komunikace s externími dodavateli

Řešení problémů v průběhu testování

Report výsledků testů a

objevených chyb

Zaznamenání výsledků testu jednotlivých oblastí

Souhrnné statistiky za definované období

Report nalezených chyb

Řízení životního cyklu chyb

Kooperace při řešení chyb

Průběžná revize business testů a

testovací dokumentace

Analýza priorit jednotlivých testovacích případů

Určení kritických oblastí

Aktualizace testovací dokumentace

Aktualizace testovacích případů

Inovativní přístup pří řešení business testů

Zdroj: Vlastní zpracování

- 40 -

7.3 Definice kompetencí rolí

Tabulka 2: Definice kompetencí

Business Tester

Provádění testů

Zaznamenávání průběhu testů

Příprava dat

Hlášení chyb

Retest opravených chyb

Business Test analytik

Vytváření testovací strategie

Analýza a sumarizace testovacích požadavků

Návrh testů – testovacích skriptů

Vytváření testovacích skriptů

Specifikace podmínek pro testy

Business Test koordinátor

Návrh testů – testovacích skriptů

Koordinace testů v průběhu

Koordinace reportovaných chyb

Report výsledků jednotlivých oblastí

Business Test leader

Koordinace přípravy testovacích skriptů

Řízení členů týmu

Komunikace s externími subjekty

Schvalování výstupů


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.

- 41 -

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.

- 42 -

7.5 Přínosy business testů na projektu Alfa

Tabulka 3: Přínosy projektu Alfa

Přínos pro projekt Alfa Popis

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

testování

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

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

Nebude nutné před každými testy alokovat nové

testery.

Zavedení nových rolí

Business Test analytik

Business tester

Business Test leader

Business Test koordinátor

Zvýšení produktivity samotných

testů

Jednotlivý testeři budou mít zkušenosti s danou

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

ú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.

Vymezení odpovědnosti za přípravu

testovacích dat

Nebude tolik závislý na dodávce dat z oddělení IT.

V co největší míře budou data vytvářena samotným

testovacím týmem. Tím se sníží riziko nedodání

požadavků na data ve stanovený čas.

Rozšíření UAT o regresní testy Jeden ze zásadních přínosů. Do této doby byly

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

Kompletní a permanentní podpora

pro business testování

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.

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

pracovníků Businessu

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.


- 43 -

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

Plán business testů

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

náležitostmi definovanými s projektovým

managementem

Analýza a příprava business testů

V rámci analýzy bylo přesně vydefinováno testovací

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

Vyhodnocení business testů

Na základě statistik exportovaných z nástrojů k tomu

sloužících bylo vyhotoveno vyhodnocení a předáno

vedení projektu

Reportování chyb V průběhu testování docházelo ke správnému

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


- 44 -

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 Tester 2 Tester 3 Tester 4 Tester 5 Tester 6 Tester 7 Počet datasetů

Oblast 1 X X 26 Oblast 2 X X X 85 Oblast 3 X X X 42 Oblast 4 X X 89 Oblast 5 X X 12 Oblast 6 X 32 Oblast 7 X X X 155 Oblast 8 X X X X 266 Oblast 9 X X X 58

Oblast 10 X X 41 Oblast 11 X X X X 211 Oblast 12 X X X 69 Oblast 13 X X 36 Oblast 14 X X 14 Oblast 15 X X X X 150 Oblast 16 X X X 101 Oblast 17 X 98 Oblast 18 X X 65 Oblast 19 X X X 77 Oblast 20 X X 15 Oblast 21 X X X X 248 Oblast 22 X X X 120 Operační

systém W7 VISTA XP MAC LINUX XP W7

Prohlížeč IE7 Chrome

10 Opera 11.6 Firefox 5 Chrome

10 IE8 Firefox 8 Java 1.6.24 1.6.24 1.6.24 1.6.24 1.6.24 1.6.24 1.6.24


- 45 -

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í

- 46 -

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í.

- 47 -

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 Počet

zadaných chyb (všech)

Počet provedených

skriptů

Pokrytí testů

Úspěšnost ověřených

testů

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

funkčností

1.kolo 355 2 261 62% 78% 42%

2.kolo 170 2 805 78% 91% 72%

3.kolo 90 2 972 82% 98% 76%


- 48 -

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


- 49 -

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.

- 50 -

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

- 51 -

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

- 52 -

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

- 53 -

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ů


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ů

- 54 -

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


- 55 -

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


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

- 56 -

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 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 0

Major (B) Závažná chyba, má vliv na funkčnost, ale

neovlivňuje jí nějak zásadně 2

Minor (C) Standardní chyba, nemá vliv na

funkčnost, zejména grafické chyby 5

Trivial (D) Chyba s minimálním dopadem na

aplikaci, např. barvy objektů 7


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

- 57 -

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.

- 58 -

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.

- 59 -

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í.

- 60 -

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

- 61 -

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.

- 62 -

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., ISBN-

10: 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:

<http://www.swtestovani.cz/>.

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:

<https://www.unicorncollege.cz/>.

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: <https://www.unicorncollege.cz/>.

11. Testování software [online]. 2012 [cit. 2012-04-24]. Dostupné z URL:

<http://testovanisoftwaru.cz/>.

- 63 -

12. Testovací skript : CleverAndSmart [online]. Edit. 18.02.2009 [cit. 2012-04-25].

Dostupné z

WWW: <http://www.cleverandsmart.cz/testovaci-skript />.

13. Testovací případ : CleverAndSmart [online]. Edit. 14.02.2009 [cit. 2012-04-25].

Dostupné z

WWW: <http://www.cleverandsmart.cz/testovaci-pripad />.

- 64 -

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

- 65 -

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 -

- 66 -

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 -

Date post:	04-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

UNICORN COLLEGEprev.unicorncollege.cz/european-it-center/pavlicek... · testování ve velkých...

Documents