UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Transkript

1 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

2 Č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 Dalibor Pavlíček

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

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

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

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

7 OBSAH 1. Úvod Úvod do problematiky testování Psychologie softwarového testování Základní pojmy Softwarová chyba Kvalita software Verifikace a validace Testovací plán Testovací případ Testovací skript Testovací scénář Typy testů Viditelnost zdrojového kódu Black box Testování černé skříňky White box Testování bílé skříňky Grey box Testování šedé skříňky Rozdělení dle způsobu Statické testování Dynamické testování Automatizované testování Manuální testování Rozdělení dle času Testování jednotek Integrační testování Systémové a integrační testování Akceptační testování Typy testování Testování konfigurace Postup při testování konfigurace Testování kompatibility

8 6.2.1 Postup při testování kompatibility Testování použitelnosti Testování webových aplikací Testování konfigurace a kompatibility Testování použitelnosti Business testování Záměr Business testovací tým Definice kompetencí rolí Pilotní provoz business testovacího týmu Přínosy business testů na projektu Alfa Průběh testů projektu Alfa Zaznamenané problémy v průběhu testů Chyby nalezené v průběhu business testování Vyhodnocení Shrnutí a další postup Test plán a strategie projektu BETA Úvod Harmonogram testů Free testy Další důležité informace Příprava dat Zahájení UAT Příprava dat na UAT Průběh UAT Další důležité informace k UAT Zaznamenávání chyb JIRA nástroj pro evidenci chyb Závažnost chyb Testovací skripty Testovací tým Akceptační kritéria převzetí do UAT testů Akceptace převzetí do technického pilotu

9 8.9 Vyhodnocení a ukončení testů Závěr Conclusion Seznam použité literatury Seznam použitých symbolů a zkratek Seznam obrázků Seznam tabulek

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

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

12 3. PSYCHOLOGIE SOFTWAROVÉHO TESTOVÁNÍ Základním předpokladem pro správné pochopení problematiky testování je pochopení jeho definice. Často se můžeme setkat s následujícím názorem: Testováním demonstrujeme to, že se v programu nevyskytují chyby. 1 Avšak tato definice není zcela správná. Testování programu dává produktu přidanou hodnotu, zvyšuje jeho konkurenceschopnost a možnost jeho využití. Tím, že budeme dokazovat bezchybnost systému, nikdy nebudeme efektivně testovat. Produktu přidáme hodnotu pouze tím, že budeme chyby hledat a následně opravovat a tím a vlastně dokazovat, že program není bezchybný. Testování systému je proces hledání chyb v co největším počtu - Testování je proces procházení programu s úmyslem najít chyby. 2 Lidé se rádi orientují na nějaký cíl a jeho stanovení má pro ně významný psychologický efekt. Je-li naším cílem prokázat, že program nemá žádné chyby, potom budeme podvědomě řízeni ke splnění tohoto cíle a budeme mít tendenci vybrat takové testy funkčností, které mají nízkou pravděpodobnost selhání programu. Jestliže je však naším cílem ukázat, že program má chyby, bude existovat vyšší pravděpodobnost, že chyby nalezneme. Testování je ve své podstatě vlastně destruktivní proces a většina lidí ho proto shledává jako náročnou disciplínu. Většina lidí má spíše konstruktivní, nikoli destruktivní pohled na život. Lidé mají spíše sklony k tvorbě než k rozbíjení nějakých objektů na části a nalézání jejich nedostatků. Dalším psychologickým jevem, kterým můžeme lépe pochopit podstatu testování programu, je správná analýza a použití slov "úspěšný" a "neúspěšný". Zejména jejich použití projektovými manažery při vyhodnocování výsledků exekuce testovacích případů. Většina projektových manažerů nazývá testovací případ, kde nebyla nalezena žádná chyba jako úspěšný test. Zatímco test, který objevil novou chybu, je obvykle nazýván jako neúspěšný. To však není zcela správná definice. Slovo "neúspěšný" označuje něco, co je nežádoucí nebo co nesplnilo svůj účel. Při správném způsobu pochopení testování, správně navržený a provedený test je úspěšný, pokud zjistí chyby, které mohou být opraveny a nebo když zjistíme, že neexistují žádné další chyby. Jediný neúspěšný test je ten, který není správně navrhnut a který neotestuje software tak, jak by měl. 1 Myers, G. J.; The ART of SOFTWARE TESTING, 2.nd ed.; Word Association, Inc.: New Jersey, 2004, s Myers, G. J.; The ART of SOFTWARE TESTING, 2.nd ed.; Word Association, Inc.: New Jersey, 2004, s

13 4. ZÁKLADNÍ POJMY Tato kapitola popisuje základní pojmy v oblasti procesu testování software, jejichž znalost je důležitá, chceme-li se pohybovat v prostředí, které popisuje problematiku programového testování. V této práci jsou použity mnohokrát a bez jejich znalosti může být způsob interpretace chybný. 4.1 Softwarová chyba V obyčejném životě můžeme na něco ukázat a říci, že je to chyba. To samé můžeme aplikovat i v oblasti testování, ale v praxi to samozřejmě není takto jednoduché a proto je potřeba v první řadě správně definovat pojem chyba. Dokument, který může poměrně výrazně změnit pohled na to, co je chyba, nazýváme specifikace produktu. Specifikace je dohoda mezi dodavatelem a zadavatelem, popisuje chování systému, jeho funkčnosti a zejména to, co bude dělat a co dělat nebude. Tato dohoda může mít různé podoby, od ústní až po psaný dokument [5, s. 13]. O softwarové chybě mluvíme tehdy, jestliže: Software nedělá něco, co by podle specifikace produktu dělat měl, Software dělá něco, co by podle specifikace dělat neměl, Software dělá něco, o čem se produktová specifikace nezmiňuje, Software nedělá něco, o čem se produktová specifikace nezmiňuje, ale měla by se zmiňovat, Software je obtížně srozumitelný, těžko se s ním pracuje, je pomalý, nebo podle názoru testera softwaru jej koncový uživatel nebude požadovat za správný. Vysvětlili jsme si pojem softwarová chyba, ale proč vznikají a co jejich příčinou? Jako první se nabízí nejjednodušší možná příčina, která vyplývá z logiky testování chyba je způsobena selháním aplikace. Pravda je však jiná, největší podíl nalezených chyb můžeme přičíst především chybám ve specifikaci [5, s. 14]

14 Obrázek 1: Příčiny vzniku chyb Zdroj:[5] Vlastní zpracování 4.2 Kvalita software Metodika RUP definuje kvalitu jako určitou úroveň uspokojení potřeb uživatelů systému. Protože každý uživatel má jiné požadavky a očekávání a není možné stanovit tuto úroveň jednotně, byl definován rozšířený seznam parametrů dimenze kvality. Někdy bývají dimenze souhrnně označovány FURPS. Jednotlivé dimenze jsou následující [4]: Funkčnost správná funkčnost produktu dle funkční specifikace, Použitelnost jaké úsilí musí uživatel vynaložit při práci s produktem, jestli je uživatelsky přívětivý dobře se s ním pracuje, Spolehlivost definuje chování produktu v různých nestandardních situacích celková robustnost systému Výkon jak se produkt chová při souběžné práci více uživatelů, kolik systémových zdrojů odebírá atd., Podporovatelnost zda lze produkt bez problémů nainstalovat, zda dokáže dobře spolupracovat s novými verzemi určitých komponent atd. [7]

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

16 4.4 Testovací plán Testovací plán (občas se používá také pojem Globální testovací plán viz RUP) je dokument, který obsahuje informace o všem, co je potřeba definovat v rámci přípravy testů. Jeho rozsah je široký a měl by popsat všechny subjekty, které do testování zasahují a které by mohly být v rámci procesu řešeny [5, s. 211]. Správný plán testování by měl obsahovat: Zdroje Detailní popis rolí/osob, které budou na projektu pracovat, definice jejich úkolů a specifikace komunikačních kanálů. Nedílnou součástí by mělo být přesné popsání úložiště sdílených dokumentů a dalších nezbytných souborů, které budou na projekty použity. Může se například jednat i o testovací hardware, jeho úložiště, přístupová povolení atd. Obecně lze tuto část využít i jako základní informace pro nové členy týmu, základní overview, které nezbytně potřebují ke své práci [5, s. 214], Definice pojmů Slovník alespoň nejdůležitějších výrazů popisující jejich přesný význam a chápání na daném projektu u daného klienta. Jedna z nejdůležitějších částí dokumentu, jelikož správné a stejné chápaní pojmů je jednou z hlavních podmínek při kooperaci. Musíme si uvědomit, že na projektech bývá zainteresována veliká řada různých rolí, s různými zkušenostmi a jejich výklad může být rozdílný, což může mít fatální následky [5, s. 214], Vzájemné povinnosti mezi skupinami Popisuje povinnosti mezi skupinami, které spolupracují na projektu a mohou mít vliv na testovací práce. Práce samotného testovacího týmu je podřízena mnoha dalším týmům programátorům, analytikům, správcům prostředí atd. Zvláště ve velkých vývojových týmem musí být této části věnována velká pozornost [5, s. 215], Co se bude a nebude testovat Může se stát, že nebude nutné testovat všechny části produktu, jelikož byly např. otestovány dříve, nebo byly otestovány dodavatelskou společností. V procesu plánování je proto potřeba popsat každou komponentu a určit, zda bude testována či nikoliv. Při rozhodnutí, že se daná komponenta nebude vůbec testovat, je nutné definovat z jakého důvodu a kdo je za toto rozhodnutí kompetentní [5, s. 217],

17 Testování v jednotlivých fázích vývoje Při plánování jednotlivých fází vývoje je nezbytné analyzovat navržený model vývoje a určit, jaké typy testů budou v průběhu vývoje probíhat. Tato část je závislá na metodice vývoje, čili nelze obecně určit, jaké typy testů a kdy je vhodné použít. Je nezbytné každý typ testování přesně popsat a ukázat projektovému týmu. Zároveň je nezbytné určit kritéria, za kterých se do jednotlivých fází vstupuje a za kterých se z nich vystupuje (tzv. entry a exit kritéria) [5, s. 217], Strategie testování Popisuje postupy, kterými bude testovací tým software testovat. Musí obsahovat popis celkového plánu testování a zároveň definici testů v jednotlivých fázích vývoje. Jedná se o rozhodnutí, jakým způsobem a jakým typem testů bude software ověřen. Jaké nástroje budou použity atd. Této části plánování by měla být věnována zvláštní pozornost, jelikož je na ni závislý úspěch celého testování. Ve většině případů obzvláště na větších projektech jde o samostatný dokument [2, s. 40], Pověření testerů Jestliže už jsou vyřešeny požadavky na prostředí a je určena strategie testování, můžeme přiřadit oblasti jednotlivým členům projektu, kteří se budou testováním zabývat (Tester) [5, s. 218], Časový plán testů Návrh časového plánu testů vychází z dosud zjištěných informací a je promítnut do celkového plánu postupu prací na projektu. Jedná se zřejmě o nejkritičtější část plánování testů. Důležitým parametrem je rozdělení objemu testovacích prací, jelikož ty nejsou v celém životním cyklu projektu rozděleny rovnoměrně. Toto plánování je důležité i z kapacitních důvodů, jelikož řeší i jednotlivé alokace. Jedná-li se o větší projekt a na testování je potřeba velké množství testerů, je kriticky důležité přesně naplánovat jejich využití [5, s. 219], Testovací případy, skripty a scénáře obsahuje seznam testovacích případů, skriptů a scénářů, podle kterých bude aplikace ověřena vychází z funkční specifikace [5, s. 220], Zprávy o chybách Popisuje způsob, jakým způsobem budou nalezené chyby reportovány. Tato část je velmi variabilní a na každém projektu se můžete setkat s jiným uspořádáním. Základem by měl být nástroj, který slouží k zaznamenávání

18 chyb. Dále je důležité určit způsob, jakým se bude chybám přidělována závažnost [5, s. 221], Metriky a statistiky Jedná se o prostředky k měření a sledování průběhu testování. Během procesu plánování musíme přesně identifikovat všechny parametry, které budeme sledovat a určit rozhodnutí, které budeme na základě jejich vyhodnocení provádět. Mezi testovací metriky patří celkový počet chyb za jeden den testů, seznam otevřených chyb, rozdělení chyb dle závažnosti, počet úspěšně dokončených testovacích skriptů a počet skriptů, které nemohly být dokončeny s určením důvodu [5, s. 221], Rizika a problémy Jedná se o soupis potenciálních problémů a rizik, které by mohly v průběhu testování nastat a které by mohly mít významnější dopad na výsledek testů [5, s. 221]. 4.5 Testovací případ Testovací případ (test case) popisuje, jak postupovat při testování daného požadavku. Podrobně definuje, jak otestovat požadovanou funkčnost, jaké parametry mají být zvoleny na vstupu a jaké by se nám měly vrátit na výstupu. Podle normy ANSI/IEEE 829 dokumentuje testovací případ skutečnou hodnotu vstupů spolu s očekávanými výsledky. Testovací případ by měl také popisovat veškerá omezení v procesu testování, vyplývajících z určitého testovacího případu. Každý testovací případ by měl obsahovat tyto náležitosti [13]: Identifikátor Jedinečný identifikátor odkazující na specifikaci návrhu testů a specifikaci testovacích procedur, Testovaná položka Popis testované funkce. Tento popis by měl být podrobnější, než je uvedeno v testovacím plánu. Dále je zde uveden např. odkaz na specifikaci produktu, či jiné dokumenty spojené s testovacím případem, Specifikace vstupů V této části jsou definované všechny vstupy nebo podmínky, které před provedením testovacího případu do programu vložíme,

19 Specifikace výstupů Zde jsou definované všechny výsledky, které jsou očekávané po provedení testovacího případu, Požadavky na prostředí Tato část popisuje vše, co je k provedení testovacího případu potřeba. Může se jednat o software, hardware, uživatele, služby atd., Zvláštní požadavky V této části jsou uvedeny všechny ostatní neobvyklé parametry, které jsou nutné provádět před nebo při samotném testování. 4.6 Testovací skript Testovací skript je v podstatě postup, jak se bude určitý testovací případ vykonávat. Testovací skript je realizace testovacího případu za použití konkrétních specifikovaných dat. Testovací skript krok za krokem definuje způsob, jakým je testovací případ prováděn. Nedílnou součástí testovacího skriptu jsou následující informace [12]: Identifikátor Jedinečný identifikátor odkazující na testovací případ a návrh testů, Účel Pro jaký účel skript vznikl a k jakému testovacímu případu se váže, Zvláštní požadavky Jiné procedury a postupy, dovednosti nebo zvláštní vybavení, které je při vykonávání skriptu potřeba, Kroky skriptu Detailní popis způsobu provádění testů. Testovací skript může obsahovat následující části, které již nejsou zcela nezbytné: Záznam Definuje, jakou metodou a jakým způsobem se budou výsledky testu zaznamenávat, Příprava Určuje, co je potřeba připravit k testu, Zahájení Popisuje, co všechno je potřeba k zahájení testu, Skript Popis jednotlivých kroků s postupem testování, Měření výsledků Způsob určování výsledků, Předčasné zastavení Popisuje kroky pro přerušení testu z důvodu neočekávané chyby, Obnovení Určuje, jak má tester postupovat při přerušení testu a jak má pokračovat,

20 Ukončení Definuje kroky pro ukončení testu, Úklid Popis kroků pro obnovu prostředí pro další testy, Mimořádná opatření Způsob jak postupovat v případě, kdy testy neprobíhají podle plánu. Podoba testovacích skriptů se v praxi velmi liší. Forma jedné z možnosti, jak sestavit takový skript ukazuje obrázek 2. Obrázek 2: Test skript Systém: Projekt: Funkční oblast: Identifikátor: Název scénáře: Autor: Datum: Délka testu: Datum provedení: Tester: Verze aplikace: Poznámka: Účel 1 2 Zvláštní požadavky 1 2 Testovaný tok: Typ kroku Krok číslo Popis 1 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) Zdroj: vlastní zpracování 4.7 Testovací scénář Návrh testů nebo testovací scénář je složen z testovacích případů, které na sebe logicky navazují a musí být vykonávány v určitém pořadí. Struktura testovacího scénáře se

21 může podobat struktuře Specifikace požadavků, jelikož cílem by mělo být pokrytí všech požadavků testovacími případy. Struktura návrhu může mít následující podobu [11]: Testované vlastnosti Jedná se o soupis požadavků, které by měly být testy pokryty, Přístup k testování Každý z přístupů vyžaduje jinou dovednost. Mezi tyto přístupy patří zejména způsob testování (black, white nebo grey box) a různé typy testů (Unit testy, integrační atd.), Testovací skripty - určuje testovací skripty, které jsou použity ve scénáři, Kritéria Obecně definuje kritéria, za jakých můžeme prohlásit, že test prošel či nikoliv

22 5. TYPY TESTŮ 5.1 Viditelnost zdrojového kódu Obrázek 3: Rozdělení testů z hlediska zdrojového kódu Zdroj: [11] Vlastní zpracování 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] 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] Grey box Testování šedé skříňky Později vznikl i další typ testu dle přístupu šedá skříňka. Jedná se o střed mezi černou a bílou skříňkou. Tester sleduje chování aplikace, ale má k dispozici i nějakou část

23 zdrojového kódu. Bývá to např. algoritmus výpočtu funkce, matematické principy využité v aplikaci atd. [4] 5.2 Rozdělení dle způsobu Obrázek 4: Rozdělení testů z hlediska způsobu Zdroj: [10] Vlastní zpracování 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] 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] Automatizované testování Tam, kde testování aplikace nevyžaduje významný podíl lidského úsudku a funkčnost se nemění na rozdíl od zadávaných vstupních parametrů, lze použít libovolný nástroj, který zvládne automatizovaně otestovat část aplikace. K tomu je potřeba programově napsat, co se má otestovat, s jakými vstupními parametry a spustit test. Automat projíždí aplikaci a výsledkem je předem definovaný report s chybami, které automat odhalil. Je tedy potřeba mít testovací nástroj, vstupní a výstupní data a hlavně testovanou aplikaci, která podporuje skrze své rozhraní automatizaci procesů. Nejběžnější použití automatizovaných testů je

24 v zátěžových testech, ale dají se v zásadě použít i v jiných oblastech [9]. Automatizované nástroje pro testování nemohou v žádném případě testery softwaru nahradit pouze jim pomáhají odvádět jejich práci snáze a lépe. 5 Výhody AT: Velmi nízké náklady na provoz, Absence lidské chyby, Možnost testovat velké množství vstupů a výstupů, Není zde časový limit (může pracovat celý den), Paralelnost. Nevýhody AT: Vysoké vstupní náklady na pořízení, Potřeba zkušených obsluhujících pracovníků, Tvorba testů je časově náročná 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