Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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
Zdroj: [10] Vlastní zpracování
5.2.1 Statické testování
Tento způsob testování je specifický tím, že se jedná o testy produktu, který není spuštěný.
Netestujeme jednotlivé funkčnosti za běhu aplikace, ale prohlížíme ji a revidujeme.
Můžeme revidovat specifikaci, zdrojový kód atd. Výhodou je, že lze začít testovat ještě
před vyvinutím prvního funkčního prototypu [10].
5.2.2 Dynamické testování
Jedná se o testování aplikace za běhu. To znamená klasické testování funkčností a reakcí
na vstupy uživatele [10].
5.2.3 Automatizované testování
Tam, kde testování aplikace nevyžaduje významný podíl lidského úsudku a funkčnost se
nemění na rozdíl od zadávaných vstupních parametrů, lze použít libovolný nástroj, který
zvládne automatizovaně otestovat část aplikace. K tomu je potřeba programově napsat, co
se má otestovat, s jakými vstupními parametry a spustit test. Automat projíždí aplikaci
a výsledkem je předem definovaný report s chybami, které automat odhalil. Je tedy potřeba
mít testovací nástroj, vstupní a výstupní data a hlavně testovanou aplikaci, která podporuje
skrze své rozhraní automatizaci procesů. Nejběžnější použití automatizovaných testů je
- 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
Zdroj: [10] Vlastní zpracování
5.3.1 Testování jednotek
Unit testy přichází na řadu po té, co programátor ověří kód. Testují se zde třídy a jednotlivé
metody. Jednotku chápeme jako izolovanou část aplikace. Test je napsán ve formě
programového kódu a na bázi frameworku. Tyto testy jsou velice důležité, jelikož chybu
odhalíme v počáteční fázi a tím snižujeme pravděpodobnost zvýšení nákladů v budoucnu
[7].
5.3.2 Integrační testování
Testy integrace jsou prvními v pořadí, které probíhají uvnitř testovacího týmu. Ověřuje se
komunikace a funkčnost mezi jednotlivými komponentami a to jak uvnitř aplikace, tak
i mezi hardwarem. Jedná se o test komponent, které byly otestovány izolovaně, a je třeba
otestovat jejich součinnost [7].
- 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ů
Zdroj: Vlastní zpracování
7.4 Pilotní provoz business testovacího týmu
Při vzniku business testovacího týmu byl zvolen Projekt Alfa jako pilotní pro spuštění
procesu business testování. Na straně businessu je zapotřebí vytvořit testovací strategii
a dokumenty k testování. V této fázi jsou testovací scénáře pro nové funkčnosti vytvářeny
zejména Gestory, nebo Business analytiky daných oblastí. Regresní testy a k nim
přidružené testovací skripty, jsou vytvářeny novou rolí – Business Test analytikem.
- 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.
Zdroj: Vlastní zpracování
- 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
Zdroj: Vlastní zpracování
- 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
Zdroj: Vlastní zpracování
- 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%
Zdroj: Vlastní zpracování
- 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
Zdroj: Vlastní zpracování
- 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ů
Zdroj: Vlastní zpracování
Chyby budou zpracovávány dle závažnosti IT stranou. Jednotlivé problémové oblasti
a nejkritičtější chyby budou probírány každý týden na schůzce, kterého se zúčastní jak zástupci IT,
tak i strany businessu.
8.5 Testovací skripty
Testovací scénáře budou vytvářeny Business Test analytiky a gestory za jednotlivé oblasti.
Bude vytvořen dokument, ve kterém budou popsány funkčnosti, které je nutné pokrýt
v UAT. Za každý testovací skript a testovací scénář bude zodpovědný analytik, který by
měl sledovat stav vývoje jednotlivých funkčností. Podkladem pro vývoj testovacích skriptů
- 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
Zdroj: Vlastní zpracování
- 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
Zdroj: Vlastní zpracování
8.8 Akceptace převzetí do technického pilotu
Akceptace převzetí do technického pilotu proběhne na základě analýzy a vyhodnocení
UAT testů. Kritérium na počet otevřených chyb může být přehodnoceno dle možnosti
- 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
Zdroj: Vlastní zpracování
8.9 Vyhodnocení a ukončení testů
Samotné vyhodnocení testů bude probíhat po ukončení UAT testů. V průběhu testů však
budou k dispozici dílčí výsledky za jednotlivé dny a funkčnosti s podrobnou statistikou
výstupů. Bude tedy možné flexibilně reagovat na vývoj testů a přizpůsobit se stavu
aplikace. Vyhodnocení bude obsahovat hlavně informaci o tom, do jaké míry byly pokryty
požadavky na testy. To znamená, jestli se otestovalo vše, co se mělo v rámci UAT
- 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 -