MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY. Návrh nového přístupu k řízení kvality při vývoji software DIPLOMOVÁ PRÁCE

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Návrh nového přístupu k řízení kvality při vývoji software DIPLOMOVÁ PRÁCE

Tomáš Míka Brno 2013

Prohlášení:

Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Tomáš Míka

Poděkování: Děkuji vedoucímu své diplomové práce RNDr. Ing. Tomáši Ludíkovi za ochotný a vstřícný přístup při vedení a za jeho cenné rady a připomínky. Dále také děkuji své rodině, přítelkyni, přátelům a všem známým za poskytnutí zázemí a dobrých podmínek pro psaní diplomové práce.

Shrnutí: Práce se zabývá problematikou vývoje softwarových systému, metodikami používanými při vývoji a zaměřuje se na řízení kvality při vývoji. Nejprve popisuje obecně testování, jakožto činnost prováděnou při vývoji, vysvětluje základní pojmy a popisuje různé typy testů. Následně důkladně rozebírá a srovnává různé způsoby řízení kvality pomocí agilních a rigorózních metodik vývoje softwarových systémů. Na základě tohoto rozboru je navržena metodika nová, která určitým způsobem kombinuje agilní a rigorózní přístup a má snahu převzít ty lepší vlastnosti z obou druhů metodik. Použití nově navržené metodiky je demonstrováno na případové studii.

Klíčová slova: Řízení kvality, Testování, Rigorózní metodika, Agilní metodika, Rational Unified Process, Extrémní programování

Obsah 1 Úvod.................................................................................................................1 1.1 Cíle práce...................................................................................................1 1.2 Struktura práce..........................................................................................2 2 Testování SW....................................................................................................3 2.1 Základní pojmy.........................................................................................3 2.2 2.3 2.4 2.5

Vlastnosti testerů.......................................................................................4 Metody testování.......................................................................................6 Typy testů podle fáze vývoje...................................................................10 Základní pravidla testování.....................................................................12

3 Metodiky vývoje SW......................................................................................14 3.1 Vodopádový model..................................................................................15 3.2 Spirálový model......................................................................................16 3.3 Rational Unified Process.........................................................................17 3.3.1 Popis..............................................................................................17 3.3.2 Test workflow................................................................................18 3.4 Agilní metodiky.......................................................................................21 3.4.1 Extrémní programování (XP)........................................................23 3.5 Omezení agilních metodik.......................................................................25 3.6 Shrnutí.....................................................................................................27 4 Návrh nové metodiky.....................................................................................29 4.1 Východiska..............................................................................................29 4.2 Popis........................................................................................................30 4.2.1 Základní principy metodiky...........................................................31 4.2.2 Role...............................................................................................32 4.2.3 Artefakty........................................................................................33 4.2.4 Aktivity..........................................................................................35 4.2.5 Workflow.......................................................................................38 4.3 Srovnání...................................................................................................39

5 Případová studie, verifikace metodiky...........................................................42 5.1 Definice projektu.....................................................................................42 5.1.1 Funkční moduly.............................................................................42 5.1.2 Tým kontroly kvality.....................................................................44 5.1.3 Časové propozice projektu............................................................44 5.2 Implementace dílčích aktivit...................................................................44 5.3 Shrnutí.....................................................................................................49 6 Závěr...............................................................................................................50 6.1 Výstupy práce..........................................................................................50 6.2 Výhled.....................................................................................................51 7 Literatura........................................................................................................52 A Software best practices..................................................................................55 B Principy Agilního manifestu..........................................................................57

1 Úvod O úspěchu či neúspěchu softwarové firmy obvykle rozhodují tři kritéria – čas, kvalita a cena. Zákazník vyžaduje co možná nejkvalitnější software, v co nejkratším čase a za nejnižší možnou cenu. Společnost, která dokáže při vývoji softwaru udržet tyto tři kritéria v rovnováze, tzn. dokáže v krátkém čase a za přijatelnou cenu vyvinout dostatečně kvalitní systém, má obvykle nakročeno k úspěchu. Dosáhnout takového cíle není jednoduché. Aspektů, které vývoj softwaru ovlivňují, existuje veliké množství. Základem je kvalitní vedení společnosti a kvalita procesů, které jsou ve společnosti ustanoveny. Způsobů, jak software vyvíjet, existuje mnoho, ale jen některé z nich vedou k zaručenému úspěchu. Metodiky bývají více či méně formálně popsané – některé důkladně popisují jednotlivé fáze vývoje softwaru, včetně podpůrných programů, které jsou při vývoji používány. Některé naopak představují pouze sadu rad a doporučení, kterými by se měl realizační tým při vývoji řídit a nechávají spoustu prostoru pro improvizaci a využití zkušeností jednotlivců. Výběr metodiky, případně směřování vývoje existujících procesů, záleží na mnoha faktorech. Záleží na osobních zkušenostech lidí na řídících pozicích, kteří budou vybranou metodiku ve společnosti zavádět. Důležitým faktorem je také firemní kultura – pokud má společnost mnohaletou tradici a jsou zde hluboce zakořeněné určité procesy, jen těžko se zavádí nové metodiky, byť by byly sebelepší. S tím úzce souvisí osobní zkušenost a profesionální úroveň jednotlivých lidí, kteří se na vývoji podílí. Svou roli zde v neposlední řadě hraje i charakter vyvíjeného produktu a velikost týmu podílejícího se na vývoji. Jen těžko lze vyvíjet software v malém týmu pomocí metodik obsahujících velké množství odlišných rolí. Pro vývoj složitých a vysoce spolehlivých systémů je zase lepší použít nějakou formální metodiku, kde jsou všechny procesy velice striktně definované a dodržované.

1.1 Cíle práce Cílem práce je navrhnout novou, inovativní metodiku kombinující výhody dvou odlišných směrů metodik tak, aby měla zároveň co nejméně omezení. Práce popisuje a srovnává tyto dva odlišné směry – rigorózní a agilní metodiky, přičemž klade důraz především na řízení kvality při vývoji softwaru. 1

1.2 Struktura práce První kapitola popisuje obecně testování, uvádí základní pojmy používané při testování a rozčleňuje testy prováděné při vývoji podle několika různých kritérií. Zabývá se osobami, které mají testovaní na starost, uvádí jejich základní vlastnosti a některá pravidla, kterými by se měly řídit. Druhá kapitola popisuje způsoby řízení kvality v rigorózních a agilních metodikách a zabývá se jejich srovnáním a vytyčuje omezení agilních metodik. Další kapitola se zabývá návrhem nové metodiky. Použití nově navržené metodiky řízení kvality je poté demonstrováno na zjednodušeném projektu vývoje bankovního systému smyšlenou softwarovou společností středně velké velikosti. Je provedeno srovnání efektivity některých procesů testování vyvíjeného softwaru při použití nové metodiky, oproti klasickým metodikám. Na závěr je nově vzniklá metodika srovnána s klasickými metodikami, ze kterých vychází, je provedeno shrnutí dosažených výsledků, spolu s výhledem na možnost směřování dalšího vývoje metodiky.

2

2 Testování SW Testování je velice široký pojem, zahrnuje mnoho činností, které jsou prováděny v průběhu téměř celého vývojového cyklu, a kterým se věnuje mnoho odlišných rolí zapojených do vývoje – samozřejmě testeři, ale také programátoři a analytici. Pojem testování označuje pouze konkrétní činnosti, prováděné v průběhu vývoje softwaru, ale ne samotný proces, při němž jsou prováděny – tento proces se nazývá řízení jakosti neboli kvality. Tyto dva různé pojmy je potřeba odlišovat. Řízením kvality, a metodikami, které se k tomu používají, se bude zabývat kapitola následující. Cílem testování není prokázat, že vyvíjený software je bez chyby – to je prakticky nemožné, ale odhalit a následně zajistit odstranění co největšího množství chyb tak, aby byl software spolehlivý a použitelný. Ron Patton ve své knize o testování softwaru [Pat02] popisuje cíle testování takto: „Cílem softwarového testera je vyhledávat chyby, vyhledávat je co nejdříve a zajistit jejich nápravu.“

2.1 Základní pojmy Informační technologie jsou exaktní disciplínou, a proto je i při vývoji softwaru potřeba používat přesně zavedené a definované pojmy. Každý člověk má trochu jiné chápaní světa, a toto chápání je třeba v rámci vývoje softwaru co nejvíce sjednotit. Používaní správných pojmů je důležité především při prvotních fázích návrhu systému, kdy se konzultanti a analytici domlouvají se zákazníkem na tom, co chce a co skutečně potřebuje. Na základě toho poté vytváří přesnou specifikaci budoucího chování systému. Na základě specifikace je poté systém navržen, programován a testován. Je tedy důležité, aby specifikací popsanému chování systému rozuměli všichni stejně, včetně testerů. Chyba neboli defekt Chyby by měly být primárním produktem testerské činnosti. Samozřejmě ne jejich vytváření, ale jejich odhalování. Cílem vyvíjeného softwaru je především maximální spokojenost zákazníka, jakékoliv chování či vzhled systému, se kterým bude zákazník nespokojen, lze tedy považovat za chybu. A jelikož je 3

zákazníkem očekávané chování popsáno ve specifikaci systému, je za chybu považováno chování systému odchylující se od specifikace. To ale neplatí vždy, ve specifikaci je obvykle také velké množství chyb, tudíž i chování dle specifikace může být chybné, a je třeba napravit chybnou specifikaci. I sebeobsáhlejší specifikace nikdy nezachytí veškeré možné chování softwaru, chyby se tedy vyskytují i v oblastech, o kterých se specifikace nezmiňuje, například grafické zpracování určitých prvků, výkonnostní vlastnosti software a mnoho dalších vlastností. Kvalitním softwarem se dá nazvat software takový, který dělá přesně to, co dělat má, dělá to očekávaným způsobem, dobře se s ním pracuje, je spolehlivý, bezpečný, rychlý a dobře vypadá. Testovací scénář neboli Test script Testovací scénář [Hla12] je dokument, který popisuje určitý průchod programem a očekávané chování programu v jednotlivých krocích. Nejpodrobnější scénáře mohou jít až na úroveň jednotlivých kliknutí myší a popisují každou hodnotu zadanou do systému a každou jednotlivou akci. Méně podrobné scénáře mohou naopak popisovat jen postup testu za použití komplexnějších akcí a zaměřovat se jen specifické části chování systému. Testovací scénáře obvykle vznikají na základě specifikace chování systému, nebo přímo na základě požadavků zákazníka. K vytvoření použitelného a přesného scénáře je nezbytné se s vyvíjeným systémem alespoň trochu seznámit a udělat si představu o tom, jak bude fungovat, nebo mít zkušenosti s vývojem podobných systémů. Jakmile je testovací scénář napsán a funkcionalita, kterou pokrývá, vytvořena – lze přistoupit k jeho provedení. Každá odchylka od scénáře představuje chybu. Provádění testů je obvykle nutné dokumentovat a vyhodnocovat, aby se mohl kdokoliv podívat, ať už kolega, nadřízený nebo zákazník, jakým způsobem byl test proveden, a hlavně s jakým výsledkem.

2.2 Vlastnosti testerů Někteří lidé si myslí, že testování softwaru je jednoduchá záležitost. Mají za to, že složité je software pouze naprogramovat, a následné používání už je jednoduché – vždyť to zvládají i oni sami. Mezi běžným používáním softwaru a jeho otestováním tak, aby bylo možné říct, že je připraven k úspěšnému použití, je veliký rozdíl. Samotné provedení testů, rozumějme používání 4

softwaru, jednoduché být může, ale složité na tom je vymýšlení způsobu, jakým software používat tak, aby se prověřily všechny jeho možnosti. To vyžaduje silné analytické schopnosti, analytický přístup k řešení problémů a schopnost dekomponovat problémy na menší celky tak, aby je bylo možné efektivně otestovat. Ověřování softwaru musí být systematická a důkladná činnost, s vysokým smyslem pro detail. Testování musí probíhat se zaměřením na zákazníka, je nutné mít přehled, jakým způsobem bude software používán, co by mohlo budoucímu uživateli vadit nebo ho obtěžovat. Tester musí mít zaujetí pro kvalitu a jít do hloubky problému, ale jen do té míry, aby byl schopen do stejné hloubky ověřit celou zkoumanou oblast. Tester musí mít také silné technické vlastnosti. Musí být schopen si vytvořit potřebné testovací prostředí. Kvůli otestování určitých extrémních situací, která by bylo možné jen velice obtížně nasimulovat, je třeba provádět například zásahy do databáze, které běžní uživatelé neprovádí, simulovat komunikaci s externími komponentami systému, která v současné fázi nejsou k dispozici, apod. Automatizované testování samo o sobě vyžaduje programátorské dovednosti. Zajímavý je úryvek z diskuze na téma označení pozice testera mezi vedoucími testování ve firmě Microsoft v knize [PJR09]:

„Všichni souhlasí, že testování softwaru je v zásadě vývojářská činnost. Shodli jsme se na tom, že dobrý tester musí mít technické vzdělání a nejlépe i znalosti z oblasti informatiky. Souhlasíme s tím, že dobrý tester se od programátora v něčem odlišuje. Mají v genech DNA řetězec testera.“

Objevují se dva odlišné přístupy k testování. První přístup napodobuje testování z pohledu zákazníka. Základem je nulová znalost programového kódu a test probíhá pouze za pomocí uživatelsky dostupných prostředků. Tento způsob je nazýván jako testování černé skříňky – tester dovnitř nevidí. Tímto přístupem lze ale jen těžko otestovat všechny situace, které potenciálně mohou nastat a navíc je zde vysoká šance, že bude tester zbytečně ověřovat znovu funkcionality, které jsou sice v softwaru zvlášť a na jiném místě, ale ve skutečnosti používají tu samou část kódu. Tomuto se lze vyhnout pouze v případě, kdy tester má alespoň základní povědomí, jak software funguje uvnitř. Tomuto způsobu se říká testování bílé skříňky. Nevýhodou je, že poté ztrácí nadhled a nevidí software z uživatelského pohledu. 5

Tyto dva přístupy je nezbytné vhodně zkombinovat. Jedním z řešení je rozdělení testů mezi testery, z nich někteří použijí metodu černé skříňky a někteří bílé. Vyšší efektivitu ale přináší použití metody testování šedé skříňky [PJR09]. Testy jsou nejprve navrženy ze zákaznicky orientovaného pohledu, následně je ale využita znalost kódu pro zvýšení efektivity a pro vyšší pokrytí kódu testy. Tímto zkombinováním obou přístupů lze dosáhnout komplexnějšího prověření softwaru ze širší perspektivy. Následující obrázek demonstruje efektivitu testování za použití pouze metody testování černé skříňky.

Obr. 2.1: Efektivita testování černé skříňky [PJR09]

2.3 Metody testování Metod testování existuje velmi mnoho a ještě více existuje různých členění – nejsnáze je lze členit podle způsobů provádění a podle jejich zaměření. Pro každou metodu se hodí jiný typ testera. Tester, který je důkladný, systematický a chce prozkoumat každou možnou situaci, se výborně hodí pro funkční testování. Tester, který je více všímavý, má smysl pro detail, dobře chápe potřeby zákazníka, ví, jakým způsobem bude software používán, a má navíc i grafické cítění, je ideální pro testy použitelnosti a průzkumné testy. Pro zátěžové testy, výkonnostní testy a hlavně pro automatizované testy se hodí testeři, kteří mají lepší technické dovednosti. Chceme-li po provedení všech testů na konci projektu prohlásit, že je software dobře a důkladně otestován, a že s ním bude zákazník spokojen, je nezbytně nutné použít více či méně všechny uvedené metody testů. 6

Funkční testy Funkční testy tvoří největší objem prováděného testování. Základem pro tyto testy jsou vstupy a na jejich základě generované výstupy. Tester předkládá softwaru připravená vstupní data s tím, že dle specifikace předem zná výstupní data, a ověřuje, že software tato výstupní data opravdu vytvořil. Na první pohled se to zdá jednoduché, ale není tomu tak. Záleží totiž také na různých kombinacích vstupních dat. Na různých místech funkce dochází k větvení, podle různých podmínek. Kdo se alespoň trochu vyzná v kombinatorice, ví, že už při malé složitosti je prakticky nemožné postihnout všechny možnosti. Je tedy nutné rozdělit množinu všech potencionálních vstupů na podmnožiny takové, aby se pro každý vstup z této podmnožiny choval software s vysokou mírou pravděpodobnosti podobný způsobem. Z každé této podmnožiny pak lze vybrat reprezentanta, pro tohoto test provést a ověřit výsledek. Tato metoda bývá v některých publikacích nazývána rozdělování do tříd ekvivalence [PJR09]. Tato metoda vyžaduje systematický přístup a analytické myšlení, a má-li být provedena dobře, tak i určitou představu o vnitřním kódu. Každá funkce má obor hodnot a také definiční obor. Obor hodnot tvoří výstupy funkce, které tester na základě vstupních dat ověřuje. Jejich množinu nemůže nijak ovlivnit. To se ale nedá říci o vstupních datech – uživatel může potenciálně jako vstup zadat cokoliv – pokud se omezíme jen na znaky na klávesnici, tak jakýkoliv znak a jakoukoliv jejich kombinaci. Definiční obor funkce určuje, pro která vstupní data lze funkci úspěšně provést a vrátit výsledek. Vstupní data patřící do definičního oboru funkce lze tedy označovat za validní data, ostatní za nevalidní data. Na základě specifikace tedy ověřujeme, zda všechna požadovaná vstupní data jsou opravdu validní, a naopak že všechna ostatní vstupní data jsou nevalidní. Zadávání nevalidních vstupních dat musí software nějakým způsobem řešit. Buďto uživateli tato data vůbec neumožní zadat, nebo zařídí, aby na tato data vůbec nereagoval nebo zobrazil chybové hlášení. Testování validnosti a nevalidnosti dat vůči specifikaci se nazývá pozitivní a negativní testování [SWT12]. Při rozdělování vstupních dat do tříd ekvivalence jednotlivé třídy reprezentují jak validní tak i nevalidní vstupy. Testy použitelnosti Software je sice jedna velká složitá funkce, ale musí mít i pěknou krabičku, do které je zabalen. Testy použitelnosti patří do kategorie nefunkčních testů. Tyto testy mají zajistit, že software bude nejenom pracovat správně, ale zároveň 7

práce s ním bude pro uživatele i příjemná. Na obrázku Obr. 2.2 je zobrazena obrazovka ze staré verze produktu MS Word – takovýto vzhled by v současné konkurenci asi neuspěl.

Obr. 2.2: MS Word 5.5 [Tiš11] Použitelnost softwaru se skládá z několika různých aspektů [Pou09]. Naučitelnost patří mezi nejdůležitější z nich. Ovládání softwaru musí být pro uživatele intuitivní, nesmí ztrácet příliš mnoho času studiem ovládání softwaru, jinak ho přestane používat. S tím úzce souvisí pojem konzistence softwaru. Všechny prvky napříč systémem, mající stejný význam, by měly na všech těchto místech vypadat a chovat se totožně. Pokud se uživatel naučí práce s jednou částí systému, práce s ostatními již pro něj bude snadná. Dalším aspektem správného chování softwaru je jeho předvídatelnost. Je nezbytné, aby se software choval dle očekávání uživatele, jinak může být práce s takovým softwarem frustrující. Předvídatelnost částečně souvisí s konzistencí systému, ale systém musí být předvídatelný nejen v porovnání s ostatními prvky stejného systému, ale i v porovnání s obecně známými a rozšířenými standardy pro chování softwaru podobného typu. Lze uvést triviální případ – křížek v pravém horním rohu v mnoha softwarech značí ikonu pro ukončení programu. Křížek v pravém horním rohu v našem softwaru by měl provést to samé. Posledním z aspektů použitelnosti je efektivita. Práce se softwarem musí být efektivní – uživateli musí být umožněno provést co nejvíce práce v co nejkratším čase. Efektivita softwaru může být v rozporu se snadnou naučitelností. Software, který je snadno naučitelný, nebude nikdy tak efektivní jako software, který je složitý, ale po hlubším prozkoumání umožňuje efektivnější práci. Zde je nutné rozmýšlet, jací uživatele jsou cílovou skupinou, a podle toho zvolit jeden či druhý směr. Testování použitelnosti tedy ověřuje, zda je software konzistentní a práce s ním intuitivní, předvídatelná a efektivní. 8

Zátěžové a výkonnostní testy Software musí nejenom pracovat správně a dobře vypadat, ale musí také pracovat rychle a být spolehlivý. Uživatel sedící u počítače a používající nějaký software rozhodně nebude spokojený, pokud se bude většinu času dívat, jak systém něco načítá nebo zpracovává. Výkonnostní testy sledují odezvy při různých akcích, především pokud jsou v nějaké evidenci prováděny větší výběry dat z databáze nebo jsou zpracovávány náročnější výpočetní operace. Při provádění výkonnostních testů jsou potřebné technologické znalosti softwaru. Pokud něco dlouho trvá, neznamená to nezbytně, že je to špatně. Občas lze ale odhalit skutečné výkonnostní chyby, například neodstraněné programátorské pomůcky – logování běhu určité části systému, apod., což může výkon softwaru značně snížit. Další způsob, jak zvýšit průměrnou výkonnost systému, vychází ze znalosti, jakým způsobem bude systém používán, a která funkcionalita bude používána častěji než jiná. Nelze vytvořit index nade všemi atributy v databázové tabulce, lze ale vybrat ty atributy, pomocí kterých bude výběr prováděn nejčastěji, a zde výběr pomocí indexů zrychlit. Úkolem výkonnostního testera je tyto situace odhalit. Zátěžové testy [Kov12] zkoumají systém z pohledu jeho výkonnosti a stability při zvýšené zátěži. Zvýšená zátěž nastává například v okamžiku, kdy systém zaráz používá velké množství uživatelů. Při takovýchto situacích mohou nastat výpadky funkcionalit, které při běžném provozu nenastanou, snižuje se odezva systému, systém může zcela zkolabovat. Tyto situace se při zátěžovém testování obvykle simulují pomocí podpůrného softwarového vybavení. Bezpečnostní testy Bezpečnostní testy mají za úkol ověřit zabezpečení vyvíjeného softwaru před vnějšími útoky. Účelem je zajištění vyšší bezpečnosti dat a vyšší spolehlivosti systému. U systémů, které pracují s citlivými údaji, spravují peníze (bankovní systémy), nebo řídí provoz (např. letiště), jsou bezpečnostní testy naprostou nutností. Bezpečnostní testy bývají obvykle prováděny externí firmou, která se na tyto testy specializuje. Bezpečnostní tester je v roli hackera, který se snaží různými způsoby proniknout do systému a získat citlivé informace nebo napáchat jiné škody. Tímto způsobem lze odhalit slabá místa systému a proti podobným útokům je lépe zabezpečit. Na závěr těchto testů je obvykle vypracována zpráva a na jejím základě je zajištěna náprava. Tyto testy jsou často nazývány penetračními testy [Web07].

9

Automatizované testy V předchozích odstavcích došlo k rozdělení různých typů testů podle toho, co testujeme a na co se zaměřujeme. Tento odstavec se od tohoto dělení odchýlí a zaměří se na dělení podle toho, jak testujeme. Testovat software lze dvěma způsoby – manuálně a automatizovaně. Manuální testy, aneb ruční klikání v aplikaci není nutné šířeji popisovat. Automatizované testy [Mař07] se od manuálních testů odlišují potřebou technického zázemí pro jejich spouštění a větší náročností na přípravu test scriptů. Bez automatizovaných testů se neobejdeme při zátěžovém testování. Některé způsoby vývoje softwaru používají tyto testy tím způsobem, že si nejprve napíší testy, a až poté píší vlastní program tak, aby těmito testy prošel. Kvůli vyšší náročnosti přípravy automatizovaných testů je nutné zvážit, zda se jejich příprava vyplatí. Pokud bude vyvíjen jednoduchý software, který se bude testovat jen krátkou dobu, posléze bude vývoj ukončen a software už nebude dál udržován, jsou automatizované testy zbytečné. Ale pokud je systém složitý, vyvíjí se dlouho, často se dělají změny a dlouho po dokončení vývoje se ještě udržuje, náročnost na přípravu automatizovaných testů se vyplatí. Test scripty je nutné udržovat v aktuálním stavu a průběžně do nich promítat změny provedené v systému, což vyžaduje určitou režii. Je na vedoucím testů zvážit, zda-li se použití automatizovaných testů vyplatí.

2.4 Typy testů podle fáze vývoje Aby byl výsledný softwarový produkt kvalitní, musí docházet k jeho testování na všech možných úrovních – od chvíle, kdy vzniknou první řádky kódu, až po uvedení softwaru do produkce a následnou údržbu. Podle fáze projektu, ve které jsou testy prováděny, lze testy dělit do těchto kategorií [Hla12]: unit testy, integrační testy, systémové testy, akceptační testy a regresní testy. Jednotlivé úrovně testů odpovídají úrovním specifikace systému – od nejvyšší úrovně obchodního záměru, přes specifikaci požadavků, návrh systému až po návrh nejmenších funkčních jednotek systému. Tyto závislosti znázorňuje tzv. V-model [Zel12, Ski06] – jeho nejnižší úroveň a přechod od specifikace k testování představuje vlastní kódování. V-model je znázorněn na obrázku Obr. 2.3.

10

Obr. 2.3: V-model (obrázek převzatý z [Dev12]) Unit testy Unit testy jsou prováděny programátory přímo při psaní kódu a představují nejnižší úroveň testování. Zaměřují se na nejmenší funkční celky – pokud možno bez závislostí na okolních objektech. Pokud je vytvářeno grafické rozhraní, tak se ověřuje základní vzhled a validita vstupů v jednotlivých datových polích. Unit testy mohou být prováděny manuálně nebo automatizovaně. Provádí se hlavně funkční testy, ale i výkonnostní. Integrační testy Integrační testy jsou již prováděny testery a ověřují funkčnost komunikace mezi různými komponentami, resp. komunikaci s externími komponentami či systémy. Ve V-modelu odpovídají úrovni návrhu systému. Jsou obvykle prováděny při zařazení nové komponenty do systému. Integrační testy představují předstupeň systémových testů a u menších projektů je lze vynechat. Systémové testy Systémové testy tvoří jádro celého testování a je ověřována celková funkcionalita softwaru. Po dokončení těchto testů by měl být systém plně funkční a připraven do produkce. Ve V-modelu odpovídají systémové testy úrovni funkční i nefunkční specifikace systému. Jsou prováděny všechny typy testů, všemi možnými způsoby. Testy jsou již prováděny z pohledu zákazníka a na základě předem připravených testovacích scénářů. Systémové testy bývají obvykle prováděny v několika iteracích. 11

Akceptační testy Obsahově akceptační testy odpovídají testům systémovým, rozdíl je však v tom, že již nejsou prováděny vývojářským týmem, který software vyvíjel, ale testerským týmem zákazníka. Na základě těchto testů a na základě podmínek předem stanovených ve smlouvě je software akceptován a předán zákazníkovi, nebo předán zpět k dokončení vývoje. Ve V-modelu odpovídají akceptační testy úrovni zákaznických požadavků, což nemusí být nutně totéž jako odpovídat specifikaci systému – mohou zde být odhaleny určité rozpory. Regresní testy Regresní testy jsou používány při nasazení nové verze systému, který už zákazník používá. Kromě testů nové funkcionality je nutné ověřit, zda stávající funkcionalita zůstala nedotčena a funguje dále správně. Tyto testy bývají často automatizovány.

2.5 Základní pravidla testování Tato podkapitola slouží jako shrnutí výše uvedených poznatků a předkládá několik základních principů, podle kterých by mělo testování probíhat tak, aby bylo efektivní a aby výsledkem byl kvalitní produkt a spokojený zákazník. Tyto principy jsou důkladněji popsány i v knihách [Pat02, PJR09 a ShW08]. Software nikdy nebude bez chyby Je třeba si uvědomit, že nikdy nelze odstranit všechny chyby a udělat software naprosto dokonalý – vždy nějaká chyba zůstane, byť sebemenší. Zákazník většinou nepotřebuje naprosto dokonalý systém, ale potřebuje ho včas a za rozumné peníze. Proto je potřeba objevit hranici, kdy se ještě danou oblastí zabývat a hledat další chyby, a kdy už danou oblast prohlásit za ověřenou. Cílem je najít rovnováhu mezi úsilím vynaloženým na testování a přínosem, který to bude mít. Dimenze kvality Podle [Hon11] existuje 5 dimenzí kvality softwaru – Funkcionalita, Použitelnost, Spolehlivost, Výkonnost a Podporovatelnost. Chceme-li vyvinout kvalitní software, nestačí zaměřit se jen na některé z těchto dimenzí, ale je třeba software testovat ze všech těchto směrů. Pokud software nebude splňovat kvalitu jen v jedné z těchto dimenzí, nebude úspěšný ani jako celek. 12

Programátor nemá vždy pravdu Někteří programátoři nejsou vždy nadšeni, když se v jejich práci objevuje velké množství chyb, proto mají občas ve zvyku označovat některé chyby za chtěné chování, tzv. jejich „fičuru“ (ze slova feature – anglicky vlastnost), se záměrem ulehčit si práci s opravování chyby. Je třeba zvážit ještě jednou, jedná-li se opravdu o chyby, nebo jen nepatrnou nezávadnou odchylku od navrženého řešení, a pokud ano, nenechat se přesvědčit a trvat na opravě zadané chyby. Ptát se, ptát se a zase se ptát V případě, kdy tester přesně neví, jak daná funkcionalita funguje, nebo naopak jak by fungovat měla, je lepší a efektivnější zeptat se kolegy testera, programátora nebo analytika, kteří se danou problematikou zabývají, než sám nad problémem hodiny přemýšlet bez výsledku. Většinou se stává, že při debatě o problému tester sám na řešení přijde, rozhovor může mít sám o sobě určitý stimulující účinek, aniž by dotyčný cokoliv poradil. Tuto situaci ale nelze zaměňovat se situací, kdy je potřeba nastudovat novou problematiku. Čím dříve, tím lépe Čím dříve tester defekt objeví, tím dříve bude opraven. Pro programátora to bude jednodušší, protože to bude kratší doba, kdy s danou funkcionalitou naposledy pracoval – bude ji mít ještě v hlavě a nebude muset vzpomínat, jak to vlastně fungovalo. Pro testery budou výhodou to, že daná funkcionalita bude dříve funkční – a tím pádem i lépe testovatelná. Průzkumné testy Průzkumné testy značí náhodný nesystematický průchod softwarem za účelem odhalení chyb. Je možné je provádět před započetím důkladných testů nové funkcionality. Tímto způsobem je většinou odhaleno velké množství chyb, které by později bránily v testování a je možné je opravit co nejdříve. Novou funkcionalitu je tudíž dobré nejprve rychle ověřit průzkumnými testy (bez jakékoliv dokumentace) a připravit si cestu pro následné důkladné testování. Náš zákazník, náš pán Software není vyráběn jen tak pro radost – je vyráběn pro zákazníka. Je třeba na to klást důraz a při testování přemýšlet, jakým způsobem bude software reálně používán. Tento princip musí být uplatňován především při testech použitelnosti softwaru. 13

3 Metodiky testování SW Slovem projekt lze označit v podstatě každou netriviální činnost, která má jasně daný začátek a konec, a navíc se skládá z různých fází. Aby mohly být projekty podobného typu opakovatelné a mohlo docházet k jejich vylepšování, jsou vytvářeny popisy projektů a na základě popisů modely, resp. metodiky. Tyto modely jsou na základě zkušeností z předchozích projektů stále vylepšovány. Více či méně formální popis činností, aktivit, vztahů mezi nimi a jejich časových posloupností se nazývá model životního cyklu projektu [Dou04]. Lze popsat několik základních fází životního cyklu projektu, které jsou společné pro projekty v mnoha oblastech, ať už se jedná o vývoj softwaru, psaní odborné publikace, nebo stavbu rodinného domu. Úvodní fáze se vyznačuje shromažďováním informací o tom, co vlastně budeme během projektů vytvářet. Tyto informace jsou zjišťovány od iniciátorů projektů. Představíme si jednotlivé fáze modelu stavby domu a nakonec zjistíme, že pro vývoj softwaru platí totéž. Tedy na úvod architekt zjišťuje od budoucích majitelů domu, co vlastně chtějí postavit a jaké to má mít parametry. Poté architekt navrhne základní koncept nového domu, a pokud ho investor schválí, vypracuje projektovou dokumentaci. Na základě projektové dokumentace je dům postaven, s předem dohodnutými vlastnostmi, specifikovanými v dokumentaci. Během stavby a hlavně po ní jsou stavebním dozorem prováděny revize jednotlivých dílčích činností i stavby jako celku. Poté je dokončená stavba předána majiteli. Tím ale povinnosti stavební firmy nekončí – teprve začala běžet záruční doba a je tedy třeba po určitou dobu provádět údržbu. Stejné je to i s vývojem softwaru a lze definovat několik základních fází: specifikace požadavků (vize), analýza, návrh, implementace, testování, předání a údržba. Ne vždy musí tyto fáze na sebe striktně navazovat – mohou se prolínat, i když jisté závislosti zde vždy zůstanou. Stejně tak i v případě stavebního projektu – pokud bude projektován vysoký mrakodrap, nebudou stavitelé čekat, až bude kompletně dokončena detailní projektová dokumentace horních pater mrakodrapu, ale začnou mezitím již stavět základy a spodní patra. Stejně tak stavební dozor nebude čekat, až bude stavba hotová, ale bude kontrolu provádět hned, jak budou hotová první patra. Zkrátí se tím celková doba stavby a konstrukční nedostatky dolních pater už v horních patrech nebudou opakovány. 14

Modely životního cyklu vývoje softwaru se neustále vyvíjí a inovují. Dále v textu budou nejprve pro úplnost stručně představeny dva vývojové stupně modelů, nyní už spíše méně používané – vodopádový model a spirálový model. Poté bude popsán vysoce formální model, nebo spíše metodika – Rational Unified Process (RUP) – patřící do skupiny rigorózních (precizních) metodik. Jako protipól k RUPu bude popsán agilní způsob vývoje softwaru – tento přístup bude demonstrován na popisu jedné z agilních metodik vývoje softwaru - Extrémní programování. Zkoumání různých metodik bude zaměřeno především na oblast řízení kvality vývoje softwaru.

3.1 Vodopádový model Snad nejznámějším modelem vývoje softwaru, ze kterého ostatní modely vychází, je vodopádový model. Tento přístup spočívá v tom, že každá etapa projektu začíná až tehdy, když je dokončena ta předchozí. Výstupy jedné fáze tedy představují vstupy pro fázi následující. Proto vodopádový model – práce přetéká z jedné fáze do druhé. Model je znázorněn na následujícím obrázku.

Obr. 3.1: Model vodopád Předpokladem pro použití vodopádového modelu je precizní definování požadavků spolu s předpokladem, že se již v průběhu vývoje nebudou měnit. Celý projekt musí být pečlivě naplánován již na začátku – musí být stanoveny milníky mezi jednotlivými etapami. Výhodou tohoto modelu je jednoduché plánování a jednoduché ověřování stavu projektu. Tento model je však značně neflexibilní, což vyplývá už z předpokladů pro jeho použití. Každá změna 15

v požadavcích znamená problém. Z hlediska testování je model naprosto nevýhodný – se započetím testovací fáze se počítá až po dokončení implementace, což je naprosto v rozporu s pravidlem, že chyby je třeba odhalovat co nejdříve. Tento model se hodí spíše pro menší projekty, u kterých se předpokládá hladký průběh.

3.2 Spirálový model Spirálový model byl navržen v roce 1986 Barrym Boehmem [Pat02] a přináší do modelu vývoje softwaru prvek iterativnosti. Na začátku vývoje jsou definovány pouze klíčové prvky celého systému. Na tomto základě je vytvořen jednoduchý prototyp systému, obsahující jen malé množství nejdůležitějších funkcí. Tento prototyp lze vyzkoušet a posoudit jeho použitelnost. Lze jej předvést zákazníkovi a získat od něj připomínky, podle kterých lze dále směřovat vývoj. Tento proces je opakován pořád dokola, až dokud není vytvořen finální produkt. Způsobem, jakým se postupně rozrůstá funkcionalita produktu a jednotlivé fáze se točí pořád dokola, připomíná celý proces vývoje spirálu.

Obr. 3.2: Spirálový model [Hla12] 16

Na obrázku spirálového modelu Obr. 3.2 je vidět rozdělení do čtyř základních fází. Určením cílů, alternativ a omezení celý proces začíná – v každé iteraci jsou určeny cíle pro konkrétní fázi projektu. Následuje fáze Vyhodnocení alternativ, identifikace a řešení rizik. V této fázi je třeba co nejvíce omezit možná rizika a vypracovat krizové plány. Následuje fáze Vývoje a ověřování – v této fázi jsou vyvíjeny a ověřovány funkcionalit naplánované pro tuto iteraci. Tato fáze bývá nejdelší. Nakonec nastává fáze Plánování dalších fází, která zároveň startuje další kolo spirály. Tento model sice staví na modelu vodopádu, ale odstraňuje jeho největší nedostatky. Problémy vzniklé v prvních fázích vývoje lze odhalit už v raných fázích. Z pohledu testů je tento model značným vylepšením. Testuje se již téměř od začátku projektu, chyby jsou tudíž detekovány dříve a je tedy mnohem snazší a levnější je odstranit. Celkově je zmírněno riziko neúspěchu celého projektu.

3.3 Rational Unified Process (RUP) Metodika RUP podrobně popisuje systematický a organizovaný přístup k vývoji softwarových produktů. Je vyvíjena a komerčně prodávána jako produkt společností IBM, spolu s množstvím podpůrných nástrojů ze skupiny Rational Software, které jsou podle této metodiky při vývoji softwaru používány. Cílem této metodiky je podle [Kru00] produkovat, s předvídatelným časovým plánem a rozpočtem, vysoce kvalitní software, který splňuje požadavky jeho koncových uživatelů. Metodika RUP jakožto produkt obsahuje několik tisíc stran textu. Podrobně popisuje jednotlivé fáze životního cyklu vývoje softwaru, definuje všechny role zapojené do procesu, používané artefakty, stanovuje odpovědnosti a popisuje vývojové procesy. Díky vysoké míře detailu a podrobnosti je RUP řazen mezi rigorózní metodiky.

3.3.1 Popis Metodika RUP popisuje základní problémy a příčiny neúspěchu vývojových projektů jako je například nepřesné pochopení potřeb zákazníka, neschopnost vypořádat se se změnami v průběhu projektu, pozdní odhalení zásadních architektonických problémů a mnoho dalších. Za účelem eliminace těchto problému stanovuje RUP několik základních zásad, kterými by se manažeři projektu, pokud chtějí uspět, měli při řízení vývoje řídit – nazývá je osvědčené postupy vývoje softwaru (Software best practices) [Kru00] – více v příloze A. 17

RUP je považován za use-case-driven přístup k vývoji softwaru. Správně vytvořená sada všech use-case popisuje chování velké části systému a závislosti mezi jednotlivými částmi. Use-case model vychází ze zákaznických požadavků a představuje specifikaci vyvíjeného systému. Sada všech use-case představuje dobrý podklad pro vlastní vývoj softwaru – programování a testování, ale i pro manažerské účely. Use-case jsou součásti mnoha procesů definovaných v RUPu. Jak už z názvu vyplývá, RUP je v podstatě proces – popisuje kdo dělá co, jak a kdy. Tyto čtyři části procesu jsou reprezentovány pomocí čtyř základních objektů: role, artefakty, aktivity a workflow, kromě toho je používáno několik dalších elementů. Role představují sadu znalostí a dovedností potřebných k provedení určité aktivity a představují v procesu vývoje jasně danou zodpovědnost. Role říká kdo má danou aktivitu provést. Jednu roli může zastávat mnoho různých osob a zároveň jedna osoba může zastávat více různých rolí. Vstupem a výstupem aktivit prováděných rolemi jsou artefakty. Pokud tedy role v rámci aktivity vytvoří z jednoho artefaktu jiný artefakt, znamená to kdo (role), vyrobil co (artefakt), a jak (aktivita). Výstupem aktivity může být ten samý artefakt jako vstup, pouze s vyšší verzí. Rozměr kdy představuje sada workflow, která seskládává do časových souvislostí jednotlivé aktivity, mezi kterými se pohybují artefakty, a udává zodpovědnosti za provádění jednotlivých aktivity pro různé role. RUP rozlišuje šest základních workflow a podrobně je popisuje: Business modelování, Specifikace, Analýza a návrh, Implementace, Testy a Nasazení [Kru00]. Ostatní používané pomocné objekty představují příručky (např. pro modelování v UML), šablony a manuály k podpůrným nástrojům.

3.3.2 Test workflow Cílem testování podle RUPu není zajistit kvalitní produkt – vytváření kvalitního produktu musí být zodpovědností celého vývojového týmu. Nelze vytvářet nekvalitní produkt a poté do něj kvalitu přidat. Cílem testování je ale průběžně posuzovat kvalitu vyvíjeného produktu a průběžně poskytovat zpětnou vazbu ostatním členům vývojového týmu tak, aby mohli produkovat kvalitnější software. Důležité je poskytovat tuto zpětnou vazbu po celou dobu vývoje. Test workflow podle RUPu se skládá ze sady rolí, aktivit a artefaktů, které jsou mezi sebou ve vzájemných vztazích [IBM05, Kru00].

18

Artefakty • Plán testů (Test plan) – obsahuje informace o účelu a cíli testů během projektu. Udává správnou strategii a popisuje zdroje potřebné pro návrh a vytvoření testů a pro jejich vlastní provedení. • Test model – určuje, co bude testováno a jakým způsobem. Je to sada testovacích scénářů, test procedur, test skriptů a očekávaných výsledků testů, doplněná o poznámky. Udává závislosti mezi jednotlivými testy a vytváří ucelený pohled na pokrytí systému testy. • Testovací scénář (Test case) – je sada testovacích dat, podmínek a očekávaných výsledků, které používá jedna nebo více test procedur, za účelem ověření určité vlastnosti systému. Testovací scénáře jsou odvozovány z se-case modelu, návrhových dokumentů nebo vlastního kódu. • Test procedura – je sada detailních instrukcí pro provedení a vyhodnocení vlastního testu. V rámci jednoho testovacího scénáře může představovat hlavní nebo jeden z alternativních toků. • Test script – obsahově odpovídá test proceduře, ale s tím rozdílem, že je počítačem automaticky zpracovatelný. Sada test scriptů slouží k provádění automatizovaných testů. • Test result – zachycuje provedení testu. Na základě test resultu mohou být testy vyhodnoceny. • Defekt – vzniká během provádění testů ve chvíli, kdy se chování systému odkloní od očekávaného chování. Defekt je třeba zaevidovat. Role •

•

•

Test manažer – zodpovídá za stanovení cílů testování, určuje základní strategii testů a vytváří plán testů. Vyhodnocuje celkový stav testů a je zodpovědný za efektivitu prováděného testování. Koordinuje ostatní testovací role. Test analytik – stanovuje cíle dílčích testů. Určuje, jaké konkrétní testy je třeba provést pro co nejvyšší pokrytí systému, a průběžně toto pokrytí vyhodnocuje. Stanovuje data potřebná pro provedení testů. Test analytik rozvíjí strategii určenou test manažerem do konkrétnějších podob. Návrhář testů (Test designer) – navrhuje a vytváří jednotlivé části Test modelu – vytváří testovací scénáře. Určuje konkrétní techniky pro provedení testů a popisuje prostředí potřebné pro provedení testů. Návrhář testů je také zodpovědný za vytváření, resp. správu prostředí 19

•

pro automatizované testy, vytváří test scripty. Tester – je zodpovědný za vlastní provádění testů, ať už manuálních nebo automatizovaných. Zaznamenává průběh testů a vyhodnocuje výsledek konkrétních testů. Tester zaznamenává nalezené defekty a ověřuje jejich odstranění.

Aktivity • Plánování testů – cílem je identifikovat a popsat, jaké testy bude potřeba připravit a provést. Následuje vytvoření časového harmonogramu testů, stanovení potřebných kapacit a stanovení celkové strategie testování. Na základě test plánu je možné testování řídit a měřit dosažené výsledky oproti vyvinutému úsilí. • Návrh testů – výstupním artefaktem této aktivity je Test model – jsou identifikovány a popsány jednotlivé testovací scénáře. Testy jsou navrhovány tak, aby pokrývaly co největší část systému a zaručili, že bude splňovat všechny požadavky na něj kladené. Návrh testů musí být dobře strukturovaný a dobře organizovaný. Návrh testů vytváří postupy pro testování nejen funkčních požadavků, ale například i zátěžových a podobně – specifikuje tedy, jakým způsobem budou potřebné stavy navozeny. • Implementace testů – výstupem této aktivity jsou test scripty pro automatizované testy. Testy scripty jsou implementovány na základě navržených testovacích scénářů. • Provedení testů integrační fáze – cílem testů je ověřit, že nová funkcionalita funguje správně a splňuje požadavky, a zároveň že správně spolupracuje s ostatními komponentami. Zároveň jsou prováděny regresní testy již dříve testované funkcionality. • Provedení systémových testů – testován je celý systém jako celek, včetně jeho napojení na externí systémy. V jedné iteraci jsou tyto testy prováděny několikrát. • Vyhodnocení tesů – tato aktivita provádí vyhodnocení provedených testů – dle test resultů a objevených defektů – pomocí předem stanovených měřitelných kritérií. Testy jsou hodnoceny jednak z pohledu dosažené kvality vyvíjené aplikace – jako zpětná vazba pro ostatní členy vývojového týmu, ale i z pohledu efektivity vlastního procesu testování – jako zpětná vazba pro role zapojené do testů.

20

Workflow Test workflow je prováděno v každé iteraci procesu vývoje s různým důrazem na jednotlivé aktivity. V různých iteracích mohou jednotlivé role zastávat odlišní lidé. RUP doporučuje používat při testování podpůrné nástroje. Pro podporu celého workflow slouží TestStudio – podpora pro implementaci, provádění a vyhodnocení testů. Pro podporu zátěžového testování slouží PerformanceStudio. Vlastní workflow je zachyceno na následujícím diagramu.

Obr. 3.3: Test workflow

3.4 Agilní metodiky Agilní metodiky kladou důraz na individualitu a možnost seberealizace každého člena týmu. Vývoj softwaru je proces, agilní metodiky ale nepopisují podrobně každý krok tohoto procesu – předkládají pouze sadu praktik, kterými by se měl 21

vývojový tým řídit. Agilní vývoj je tedy jakási filosofie, kterou musí každý člen týmu dobře chápat a řídit se jí, aby byl agilní způsob vývoje efektivní a úspěšný. Agilní metodiky vznikaly postupným odkláněním od dřívěji používaných klasických metodik. Takhle vzniklo několik různých metodik (tehdy se ještě nenazývaly agilní), jejichž autoři se spojili ve společnost Agile Alliance a naformulovali několik základní myšlenek a principů, které měly všechny tyto metodiky společné. Vznikl Manifest agilního vývoje softwaru, který přináší čtyři základní myšlenky [ShW08]. Tyto myšlenky byly dále rozvedeny do dvanácti základních principů - více v příloze B. Autoři dávají přednost: • Individualitám a interakci před procesem a nástroji • Funkčnímu softwaru před obsáhlou dokumentací • Spolupráci se zákazníkem před sjednáváním kontraktu • Reakci na změnu před plněním plánu Agilní metodiky neuznávají klasické členění jednotlivých vývojových fází (analýza, testování, apod.), zvláště ne jejich obvyklé pořadí, ani v rámci jednotlivých iterací. Iterace agilních metodik jsou velice krátké a analýza, návrh, kódování a testování probíhá paralelně. S tím souvisí i menší rozlišitelnost jednotlivých rolí. Každý dělá od všeho trochu. Programátor zároveň testuje a provádí analýzu. Důležitá je spolupráce se zákazníkem – v každém týmu by měl být zástupce zákazníka, se kterým mohou ostatní konzultovat požadované chování systému. Pokud to není možné, musí tuto roli zastávat někdo, kdo alespoň nejlépe rozumí požadavkům zákazníka, a dokáže je před ostatními členy týmu obhajovat. Agilní metodiky kladou důraz na jednoduchost a snaží se maximalizovat objem práce, která nemusí být provedena pro dosažení výsledku. Z toho vyplývá minimální dokumentace práce – ta je nahrazena častými konzultacemi tváří v tvář. Testování je v agilních metodikách součástí celého vývojového cyklu. Kvalitu softwaru určitým způsobem ověřuje každá role zapojená do vývoje. Programátoři testují své dílčí funkcionality hned po jejich vyvinutí, probíhá častá kontrola kódu. Kód musí být velice přehledný, aby v něm byl každý nedostatek snadno odhalitelný. Záměrem je co největší kontrola kvality už v průběhu kódování, tak aby chyby nevznikaly téměř vůbec. Některé agilní metodiky samostatnou roli testera ani neuznávají. Jelikož je funkční software sestavován velmi často a je předváděn zástupcům zákazníkova, jsou možné nedostatky vzhledem k očekávání zákazníků odhaleny brzo a je snadné je 22

odstranit a následně předejít vytváření dalších nedostatků tohoto typu. V agilních metodikách je snaha provádět veškeré testování automatizovaně. Při každém sestavení funkční verze jsou spouštěny automatizované regresní testy. Jelikož je kladen velký důraz na vytváření bezchybného kódu, není prováděno žádné systematické manuální testování, které by pokrývalo větší část funkcionality. Bývají prováděny testy některých kritických částí funkcionality a také průzkumné testy. Každý odhalený defekt je pečlivě analyzován a je odhalena příčina vzniku defektu. Následně jsou zavedena opatření, aby už podobný defekt v budoucnu nevznikl. Agilních metodik existuje velké množství, například Scrum, Dynamic Systems Development Method, Adaptive Software Development, Lean development, Feture-Driven Development, Crystal metodika, Extrémní programování a další, o nichž se více pojednává například v [Buch05, Kad04]. Agilní přístup v oblasti testování bude dále ilustrován na popisu konkrétní vybrané metodiky – Extrémní programování.

3.4.1 Extrémní programování (XP) Kent Beck ve své knize [Bec02] popisuje XP takto: „XP je lehký, účinný, nepříliš rizikový, pružný, předvídatelný, vědecký a zábavný způsob, jak vyvíjet software.“ XP obsahuje většinu základních myšlenek agilního vývoje obecně popsaného výše, jako je používání velmi krátkých iterací za použití inkrementálního způsobu plánování. XP umožňuje pružně měnit priority při určování termínů implementace různých funkcionalit a snadno reaguje na měnící se potřeby zákazníka. Jsou využívání automatizované testy a verbální komunikace je hlavní zdroj informací, samozřejmě kromě samotného zdrojového textu - z toho vyplývá minimum dokumentace. XP se spoléhá na evoluční, průběžný proces vytváření návrhu, úzká spolupráce programátorů je samozřejmostí, je dán prostor pro jejich intuici a je kladen důraz na individualitu. Kvalita softwaru je ověřována během celého cyklu vývoje – a je prováděna především samotnými programátory. Ještě před psaním kódu určité funkcionality jsou vytvořeny unit testy, které tuto funkcionalitu otestují. Poté je psán vlastní kód – kód je vylepšován, až dokud neproběhne vytvořeným testem bez chyby. Tato metoda se nazývá Test-Driven Development (TDD). Psaní kódu, eventuelně i testů, které jej ověřují, probíhá ve dvojici. Jeden z programátorů píše kód a druhý mu kouká přes rameno a kontroluje ho. Protože sám zrovna nic nepíše, má na věc větší nadhled a snadno odhalí 23

nedostatky v kódu. Oba programátoři problém neustále konzultují – odhalují problémy v analýze, návrhu, nebo ve vlastním kódu, respektive v kódu testů. Po dokončení psaní, když testy proběhnou v pořádku, je provedena refaktorizace kódu, kvůli jeho zjednodušení a zpřehlednění. Kód je opět prověřen testy. Pokud vše proběhne v pořádku, je možné přistoupit k integraci. Navržené testy jsou přidány do souhrnné sady všech automatizovaných testů a je provedena cvičná integrace do aktuální verze systému. Poté je spuštěna kompletní sada automatizovaných – integračních testů. Pokud je objeven nějaký defekt, je ihned odstraněn. Až v okamžiku, kdy vše proběhne v pořádku, je nově vytvořená část funkcionality uvolněna do nové verze systému. Používání unit testů je v XP chápáno nejenom jako prostředek pro záruku kvality, ale i jako prostředek ke zvýšení sebedůvěry programátora. To, že všechny testy projdou v pořádku, může mít jakýsi stimulující účinek a dochází ke zvýšení produktivity. To souvisí s pravidlem agilních metodik, že práce musí být zábavná. Podmínkou pro toto je ovšem správné a důsledné psaní testů. Jakmile testy nefungují tak, jak mají, má programátor nasazeny tzv. růžové brýle, a v nejbližší budoucnosti lze očekávat závažné problémy. Výstupem takto prováděného programování by měl být téměř bezchybný software. Nic ovšem není dokonalé. XP předpokládá aktivní spolupráci zákazníka při testování software. Zákazník již netestuje na úrovni unit testů, ale na úrovni výsledné funkcionality systému tak, jak ji bude používat – tzv. příběhy. Cílem je získat důvěru v systém – ověřit, že skutečně dělá to, co dělat má. Ačkoliv v rámci vývojového týmu zastávají největší objem testování programátoři, předpokládá XP v týmu jednoho dedikovaného testera, který má za úkol převádět zákazníkem definované testovací příběhy do automatizovaně spustitelných testů. Okrajově se XP zabývá i zátěžovými testy a negativními testy, ale spíše jen jako doplňkové testování a to v oblastech, kde lze předpokládat problémy v tomto směru. Klasické XP tedy používá pouze automatizované typy testů – manuální testy nejsou používány vůbec. A to včetně automatizovaných akceptačních testů vytvořených na základě příběhů definovaných zákazníkem. Autoři knihy [ShW08] nahrazují tyto automatizované akceptační testy spíše manuálními testy jednotlivých příběhů s tím, že náklady spojené s vytvořením sady takovýchto automatizovaných testů převyšují jejich přínos. Manuálním procházením funkcionality se navíc odhalí i nevyhovující nefunkční vlastnosti systému. 24

Kromě této změny zavádí i průzkumné testy, které provádí tester ve vývojovém týmu. Nemají za úkol odhalovat chyby, ale v lepším případě spíše potvrdit, že software je bezchybný a že prováděné automatizované unit testy a integrační testy spolehlivě fungují. Průzkumné testy tedy fungují jako zpětná vazba pro zlepšení integračních a unit testů.

3.5 Omezení agilních metodik Navzdory své flexibilitě, existuje mnoho důvodů, proč agilní metodiky nelze použít [TFR02, Col09]. Případně by to bylo natolik obtížné, že se to nevyplatí. Je to jakási kompenzace za mnoho jejich dobrých vlastností. Právě tyto omezení jsou důvodem, proč v některých situacích nebývají agilní metodiky použity jako celek, ale jsou aplikovány jen některé dílčí části. Je to tedy hlavní důvod, proč se tato práce zabývá popisem nové metodiky na pomezí rigorózních a agilních metodik. Firemní kultura Možná nejčastějším a nejhůře překonatelným problémem bránícím použití agilní metodiky bývá nevhodná firemní kultura a lidé v ní. Pokud někdo nechce pracovat agilně, je často těžké ho přesvědčit. Pokud takto nechce pracovat jeden člověk, je možné za něj najít náhradu. Pokud takto ale nechce pracovat většina, je to problém. V tomto mají velkou výhodu nové týmy, nebo týmy mladé složené z lidí, kteří se chtějí učit nové věci. Ve firemní kultuře, která už desítky let pracuje stejným způsobem, je těžké provádět inovace ve formě agilního vývoje. Často se lze ale spokojit s částečnými změnami. S firemní kulturou úzce souvisí znalosti a zkušenosti jednotlivců, stejně tak jako jejich morální hodnoty [Lep10]. Agilní metodiky vyžadují kvalitní a zkušené vývojáře, kteří spolu dokáží perfektně spolupracovat. Člen týmu, který nedokáže spolupracovat s ostatními, byť by byl sebechytřejší, nemá v agilním týmu místo. Pokud vývojový tým nemá vhodnou kulturu a schopné členy, je neefektivní používat agilní metodiky. V tomto směru jsou rigorózní metodiky méně náročné, staví spíše na důkladně popsaných procesech. Špatná podpora managementu S kvalitou týmu souvisí i kvalita managementu, resp. jeho otevřenost pro použití agilních přístupů. Management musí agilní přístup aktivně 25

podporovat [ShW08]. Musí vytvořit vhodné pracovní prostředí. Při zavádění agilního přístupu musí mít trpělivost s dočasným snížením produktivity. Je nezbytné dokázat podstoupit určité riziko a důvěřovat svému týmu. Častým problémem bývá pocit ztrácející se kontroly nad projektem. To je způsobeno méně formálním způsobem řízení vývoje a daleko menším objemem vytvářené dokumentace. Ale právě v tom tkví agilita – a pokud toto manažeři nedokáží pochopit, nelze vyvíjet agilně. Nevhodný tým Důležitá je velikost a rozmístění členů týmu. Agilní tým by měl mít kolem osmi až dvanácti členů, rozhodně však ne více než dvacet. Vyšší počet členů (více jak dvanáct) se nedoporučuje méně zkušeným týmům. Počet členů týmu by měl být sudý tak, aby bylo možné pracovat ve dvojicích. Celý tým musí být umístěn co nejblíže u sebe, aby mohli být všichni členové v neustálém kontaktu. Fyzické prostředí týmu musí umožňovat snadné vytvoření dvojic (vhodné stoly, apod.). Agilní způsob vývoje tedy nelze použít, pokud charakter vyvíjeného produktu vyžaduje velké týmy. Stejně tak pokud je tým rozmístěn po různých částech světa (např. při částečném outsourcingu pracovních sil z oblastí s levnější pracovní silou). Nespolupracující zákazník Agilní metodiky spoléhají na přímé účasti zákazníka při vývoji [Bec02], nejlépe pokud je součástí každého týmu. Zákazník přímo během vývoje specifikuje a prioritizuje požadované vlastnosti systému. Pokud zákazník není schopen nebo ochoten poskytnout vývojovému týmu tyto kapacity, nelze použít agilní metodiku. Částečnou náhradou může být člen týmu, který je velice důkladně seznámen s požadavky zákazníka a dokáže předvídat jeho potřeby – účast zákazníka ale nelze plně nahradit. Stejně tak musí zákazník spolupracovat na testování jednotlivých verzí systému už při jeho vývoji. Agilní metodiky vytváří minimum dokumentace, s čímž musí být zákazník seznámen a musí s tím souhlasit. Pokud je zákazník příliš konzervativní a upřednostňuje dokumentaci před včasnou funkčností, je agilita nevhodná. Stejně tak pokud vyžaduje přímo hotový produkt na základě úvodní specifikace. Špatný druh projektu Některé druhy projektů prostě agilně vyvíjet nelze. Pokud je vyvíjena nějaká kritická aplikace, na které mohou záviset životy lidí, je potřeba mít vše důkladně dokumentované a pečlivě otestované. Zákazník takovéhoto softwaru 26

bude vyžadovat kompletní dokumentaci vývoje a bude chtít mít prověřeny všechny možnosti chování aplikace. Pokud nebude možné z jakéhokoliv důvodu podstoupit zvýšené riziko přítomnosti chyby při zkušebním použití prototypu aplikace, ztrácí agilní přístup význam. To samé platí i pro velmi složité či robustní aplikace. Pro vývoj takového softwaru, který nebude možné rozdělit na menší funkční celky, bude potřeba velký tým, což je v rozporu s agilním přístupem. Stejně tak bude prakticky nemožné pokrýt funkcionalitu unit testy (TDD), protože to bude tak složité, až to bude neefektivní. To platí zejména pro systémy, které příliš závisí na databázových datech – používají spíše procedury než funkce. Dalším, technologickým problémem při vývoji složitého systému je dlouhá doba integračního procesu – pokud bude sestavení systému trvat třeba celý den, ztratí vývoj pružnost a pro agilní vývoj potřebnou neustálou zpětnou vazbu [Bec02]. Agilní vývoj nepodporuje znovupoužitelnost komponent. Zakládá totiž na čistém, jednoduchém a přehledném kódu, který obsahuje pouze nezbytné části. Vše ostatní je při refaktorizaci odstraněno. Pokud budeme chtít použít již existující části systému pro nový systém, není agilní způsob vhodný. Příkladem může být vývoj jednoho systému pro více zákazníků – ovšem pro každého zákazníka s menšími či většími obměnami. Každý takovýto systém bude tudíž nezbytně obsahovat fragmenty, které nepotřebuje. Toto nelze provádět za použití agilní metodiky.

3.6 Shrnutí Vodopádový model, jakožto nejstarší z popsaných, ustanovuje elementární fáze vývoje softwaru a jejich přirozenou návaznost, z čehož všechny ostatní modely určitým způsobem vycházejí. Spirálový model přidává prvek iterativnosti, čímž zvyšuje flexibilitu vývoje, snižuje jeho rizikovost a umožňuje časově rovnoměrnější zapojení různých rolí do vývoje. Tento koncept přebírá a velice podrobně rozvádí metodika RUP – velmi podrobně popisuje jednotlivé fáze vývoje a popisuje všechny možné aspekty. Oproti tomu agilní metodiky přebírají koncept spirálového modelu jen částečně – nedodržují pořadí jednotlivých fází, dokonce jednotlivé fáze až tak striktně nerozlišují. Jejich popis není podrobný a spíše ustanovuje filosofii vývoje a doporučené praktiky při vývoji používané. 27

RUP bývá řazen mezi rigorózní metodiky, ale aby mohlo být provedeno v úvodu avizované srovnání rigorózních a agilních metodik, nesmí být pojem rigorózní chápán v pravém smyslu slova. Rigorózní totiž znamená přesný, precizní, což RUP samozřejmě je – ale to může být i agilní metodika (i když většinou nebývá). Pro naše potřeby tedy pojem rigorózní rozšíříme ještě o význam ve smyslu klasický, tzn. dodržující klasické dělení na jednotlivé fáze a jejich pořadí, stanovené vodopádovým modelem, spolu se zachováním všech klasických rolí, které odpovídají jednotlivým fázím. Nyní je možné provést srovnání rigorózních metodik zastoupených RUPem a agilních metodik zastoupených XP. Metodiky budou srovnány z hlediska testů. Oba přístupy, agilní i rigorózní, kladou důraz na průběžné ověřování kvality v celém životním cyklu vývoje. Rigorózní přístup ale definuje pro testování v jednotlivých fázích vývoje samostatné, podrobně popsané procesy, zatímco agilní přístup kvalitu ověřuje v rámci jiných procesů, jakožto jejich součást. S tím souvisí i role, které se ověřováním kvality zabývají. Rigorózní přístup definuje širokou škálu rolí, zatímco agilní samostatnou roli testera vůbec neuvažuje, nebo jen okrajově – jako doplňkové ověření kvality. Oba přístupy kladou vytváření kvality za úkol všem zúčastněným a testování považují spíše za zpětnou vazbu pro posouzení kvality. Agilní přístup na rozdíl od rigorózního klade vysoké nároky na zapojení zákazníka do procesu ověřování kvality. Agilní metodiky se snaží produkovat hned od začátku co nejvíce bezchybný kód, tak aby již následné opravy nebyly potřeba. Rigorózní naopak produkují kód s potencionálně mnoha chybami, které jsou v rámci důkladných testů odhaleny a opraveny. Agilní metodiky vytváří minimum dokumentace, zatímco rigorózní dokumentují vše. Oproti tomu je postavena potřeba neustále ústní komunikace v agilních metodikách, zatímco v rigorózních je většina komunikace prováděna prostřednictvím dokumentace. Rigorózní přístup klade vysoké nároky na samotný proces, tedy na toho, kdo daný proces definuje. Agilní metodiky naopak kladou důraz na jednotlivce a jejich kvality. Z toho vyplývá, že pro správné fungování agilního vývoje softwaru jsou potřeba kvalifikovanější lidé. Stejně tak integrace nového člena týmu může být v agilním vývoji složitější. Stávající členové týmu v agilním vývoji jsou tedy méně nahraditelní a jejich odchod může znamenat větší problém než v projektu založeném na rigorózní metodice. Celkově se tedy dá konstatovat, že rigorózní metodiky jsou založeny na procesu, zatímco agilní metodiky jsou postaveny na lidech zapojených do procesu. 28

4 Návrh nové metodiky řízení kvality Většina metodik nikdy striktně nestanovuje, že musí být do posledního detailu uplatněny všechny jejich části a pravidla. Spíše představují jakýsi koncept, ze kterého se dá vycházet a upravit ho podle svých potřeb, případně využít pouze některé části. Při používání metodiky totiž vždy záleží na mnoha faktorech, obzvláště na firemní kultuře – na lidech, jejich vlastnostech a dovednostech, záleží také na druhu projektu, který má být řízen a také na zákazníkovi. Metodika RUP je považována, jak píše autor knihy [Kru00] hned v úvodních kapitolách, především za procesní framework, který si musí každá organizace upravit a přizpůsobit svým potřebám. Stejně tak i agilní metodiky nejsou určeny k plnému použití ve všech svých detailech. A to tím spíše, že představují jen jakousi sadu rad a doporučení, ze kterých je možno si vybrat, co bude vyhovující.

4.1 Východiska Při zavádění jakékoliv nové metodiky do již fungující organizace nelze nikdy okamžitě, nárazově změnit celý proces vývoje. Takto by celý vývoj okamžitě zkolaboval. Jen nutné vše dobře naplánovat a novou metodiku zavádět postupně po jednotlivých částech. Začíná se částmi, ve kterých jsou v současném stavu největší problémy, a ve kterých tudíž změna bude mít největší přínos. Tento postup se nazývá reengineering procesu vývoje softwaru. Nová metodika popsaná v této kapitole bude vycházet z metodiky RUP a budou do ní doplněny některé prvky agilních metodik. Takovouto metodiku si lze tedy představit jako metodiku, která je zrovna v procesu postupného reengineeringu RUPu směrem k agilnímu vývoji. Výsledná metodika tedy představuje určitou fázi tohoto reengeneeringu, ve které se však tento proces ještě před jeho dokončením zastavil a dál již nepokračuje. Jedná se o fázi spíše blíže počátku procesu reengineeringu, protože výsledná metodika obsahuje více prvků z RUPu než z metodik agilních. Důvodů pro vytvoření a používání takovéto metodiky je několik. Agilní metodiky mají oproti RUPu mnoho výhod a lepších vlastností, jako je vyšší flexibilita, lepší efektivita práce, spokojenější a motivovanější zaměstnanci, a mnoho jiných. Nejsou ovšem použitelné ve všech situacích a při jejich 29

zavádění lze narazit na mnoho nepřekonatelných překážek (podrobněji bylo popsáno v předešlé kapitole). Oproti tomu RUP je mnohem šířeji použitelný a představuje klasičtější pojetí vývoje softwaru. Mnohem častěji probíhá přechod z metodiky na bázi RUPu na agilní metodiku, než naopak. Nepřekonatelné problémy při zavádění metodiky RUP, zmiňované při zavádění agilního přístupu, jsou v tomto opačném směru tedy spíše bezpředmětné. Nově navrženou metodiku lze tedy chápat jako mezistupeň mezi RUPem a agilním přístupem. Cílem je najít hranici, kdy ještě bude metodika široce použitelná a bude snadné ji zavést, ale navíc bude využívat co nejvíce výhod agilních přístupů. Tato myšlenka samozřejmě není nikterak převratná. Autorka publikace [Buch05] dokonce uvádí, že zavádění agilních prvků do metodiky RUP představuje současný trend vývoje této metodiky. Autor článku [Kro01] popisuje podstatu základních principů RUPu, a i když to není napsáno přímo, je zde zahrnuto vícero agilních prvků, jako je časté sestavování softwaru, velmi úzká spolupráce všech rolí v rámci jednoho týmu, apod., které v klasickém RUPu nejsou tolik akcentovány. Metodika Agilní modelování [Amb12] představuje agilní způsob modelování a dokumentace, který byl vyvinut jako náhrada za klasické způsoby, které používá např. i RUP – přináší tedy částečnou agilitu do specifické oblasti vývoje. Metodika Feature-Driven Development je v článku [Buc05] dokonce označována za mezistupeň mezi agilními a rigorózními metodikami. Článek se zabývá právě kombinováním těchto dvou přístupů. Ačkoliv bývají RUP a agilní metodiky považovány za dva protichůdné přístupy, není tomu tak – tyto odlišné způsoby lze vhodným způsobem kombinovat. Výše uvedené příklady to jen potvrzují.

4.2 Popis Nová metodika (dále jen metodika) popisuje pouze procesy zabývající se řízením a ověřováním kvality, spolu s napojením na procesy, se kterými souvisí. Je reprezentována jako sada rolí, artefaktů, činností a workflow. Tento koncept je převzat z metodiky RUP. Jednotlivé prvky - především vlastní workflow jsou však upraveny a je zde zakomponována sada agilních prvků a praktik. Výsledná metodika představuje konzistentní a prakticky použitelný způsob vývoje softwaru. Na závěr této kapitoly bude provedeno srovnání jednotlivých prvků metodiky s rigorózními a agilními přístupy obecně. 30

4.2.1 Základní principy metodiky Na úvod je představeno několik základních principů metodiky, které jsou v dalších podkapitolách podrobněji rozebrány. Vstupem do celého procesu testování je use-case specifikace systému. Z tohoto vstupu jsou vytvářeny návrhy testů a následně Testovací scénáře. Metodika dbá na to, aby se jedním požadavkem při obou aktivitách zabývala totožná osoba, je-li to možné. Jedním z klíčových prvků metodiky jsou aktivity prováděné na začátku každé iterace – a to Předání požadavků k testům a Testy při sestavení iterace. Následuje samotné testování a vytváření Test resultů. Iterace se v průběhu celého projektu zkracují. Pro požadavky testované napříč více iteracemi nevzniká více Test resultů, ale pouze jeden, který se aktualizuje. Menší objem dokumentace je nahrazen častější konzultací jak s analytiky, tak s programátory. Tyto principy, se kterými metodika dále pracuje, jsou schematicky znázorněny na obrázku Obr. 4.1.

Obr. 4.1: Základní principy metodiky 31

4.2.2 Role Metodika rozlišuje čtyři základní role, které se zabývají přímo testováním nebo tento proces řídí a koordinují. Dále popisuje další dvě role, které se ověřováním kvality zabývají okrajově mimo své hlavní procesy. Jednotlivé fyzické osoby mohou a také obvykle zastávají v procesu testování více různých rolí. Je dokonce žádoucí, aby se jedna osoba v průběhu procesu testování zabývala jedním zákaznickým požadavkem ve více různých rolích. Může totiž využít dřívěji získané poznatky v návazných aktivitách. Test manažer Hlavním úkolem Test manažera je koordinovat a plánovat práci ostatních členů týmu, zadává dílčí úkoly. Je zodpovědný za sledování a reportování aktuálního stavu provedených testů, pokrytí kódu testy a obecně za stav projektu z hlediska testování. Komunikuje s vedoucími projektu. Test manažer vytváří statistiky provedeného testování, vyhodnocuje je, sleduje efektivitu prováděné práce a přijímá podněty na zlepšení testovacích procesů od ostatních rolí. Na základě těchto informací se snaží proces testování neustále zlepšovat. Test analytik Role stanovuje, jakým způsobem bude software testován, identifikuje dílčí testy a rámcově je popisuje, určuje druhy testů, které budou použity. Na základě rámcového popisu odhaduje pracnost dílčích testů pro účely plánování. Test analytik stanovuje požadavky na prostředí pro testy, které zajišťuje a spravuje. Píše testovací scénáře pro dílčí testy, tyto scénáře udržuje aktuální a nese zodpovědnost za pokrytí kódu v dané oblasti zahrnuté v testovacím scénáři. Správce automatizovaných testů Tato role navrhuje, vytváří a spravuje prostředí pro psaní a spouštění automatizovaných testů. Vytváří test scripty a udržuje je aktuální. Nese primární zodpovědnost za spouštění automatizovaných testů a za vykazování jejich výsledků. Tato role se dále zabývá návrhem a prováděním zátěžových testů a automatizovaných výkonnostních testů. Tester Primárním úkolem této role je provádění manuálního testování na základě testovacích scénářů. Tyto testy jsou zaznamenávány a vyhodnocovány. Testovací scénáře jsou v jednotlivých iteracích prováděny opakovaně 32

a výsledek testů je aktualizován. Tester zaznamenává odhalené chyby a dohlíží na jejich odstranění. Často provádí lokalizaci objevených chyb a hledá jejich příčinu. Programátor Kromě své hlavní činnosti provádí unit testy a základní integrační testy. Tyto testy bývají manuální – účelem je ověření základní funkčnosti vytvořené části kódu a jednoduché ověření interakce s okolím. Programátor také předává vytvořenou funkcionalitu k testům, respektive její dílčí části. Upozorňuje na problematická místa, vysvětluje očekávané fungování dané funkcionality. Analytik Reviduje vytvořené řešení a ověřuje, zda odpovídá jeho očekávání – tedy zda byl správně pochopen jeho návrh řešení. Taktéž předává analytický pohled na celou věc a vysvětluje, jakým způsobem má být daná funkcionalita používána – specifikuje zákazníkova očekávání. Jeho úkolem je popsat danou funkcionalitu z byznys pohledu.

4.2.3 Artefakty Metodika používá use-case-driven přístup. Sada use-case tedy představuje primární vstupní artefakt do celého testovacího workflow. Dále je rozlišováno pět základních artefaktů, týkajících se pouze testování. Kromě toho metodika předpokládá existenci dokumentů, které standardizují vzhled (grafické vyjádření) a další obecné vlastnosti vyvíjeného softwaru. V souladu s nimi je software nejenom vyvíjen, ale tento soulad je i ověřován jako nedílná součást každého (manuálního) testu. Návrh testů Návrh testů je dokument velmi stručně popisující obsah a způsob provedení jednoho dílčího testu, nebo sady několika provázaných testů. Stanovuje také odhady pracnosti na provedení testů, včetně vytvoření Testovacího scénáře nebo Test scriptu. Návrhy testů slouží jako podklad pro plánování, jejich kompletní sada by měla zahrnovat veškeré plánované testy (funkční i nefunkční). Pokud už existuje sada use-case pro danou oblast, jsou návrhy testů vytvářeny podle nich, v opačném případě mohou být vytvářeny přímo na základě zákaznických požadavků – v tomto případě je obvykle nutné Návrh testů později zrevidovat. Za vytváření těchto dokumentů zodpovídá Test analytik. 33

Testovací scénář Testovací scénář důkladně popisuje postup provedení testů, které byly rámcově definovány v Návrhu testů. Vzniká na základě sady use-case, které popisují danou oblast. Za tvorbu těchto dokumentů je zodpovědný Test analytik. Testovací scénář popisuje nejen funkční vlastnosti systému, ale i postupy ověření výkonnostních či zátěžových vlastností systému. Jen ve výjimečných případech popisuje testy použitelnosti. Tyto vlastnosti bývají obvykle popsány v samostatném dokumentu standardizujícím tyto vlastnosti a v Testovacím scénáři obvykle nebývají explicitně zahrnuty. Test script Test script je co do obsahu obdobou Testovacího scénáře, je však psán strojově čitelným jazykem. Obvykle popisuje základní průchody určitou funkcionalitou bez velkých detailů. Ověřuje funkční, zátěžové a výkonnostní vlastnosti systému. Sadu test scriptů udržuje Správce automatizovaných testů. Test result Test result vytváří Tester a představuje záznam provedeného testu a jeho vyhodnocení. V případě automatizovaných testů může být automaticky generován nástrojem pro provádění těchto testů. Záznam o chybě Tyto záznamy vznikají při provádění testů. Kromě samotného popisu chyby obsahují několik dalších atributů, jako je závažnost, priorita či stav záznamu. Jakmile je záznam vytvořen, je ve stavu zadaný, jakmile je odhalena příčina chyby, přechází do stavu lokalizovaný, po provedení opravy přechází do stavu opravený. Následuje ověření, je-li chyba skutečně odstraněna, pokud ano, záznam získá stav uzavřený. Pokud je totožná chyba zadána již v rámci nějaké jiné, získává záznam stav duplikovaný. Metodika se nezabývá vytvářením žádných komplexních plánu testů či strategií ve formě dokumentů. Tyto informace jsou zjišťovány přímo ze sady Návrhů testů. Stejně tak neudržuje speciální dokument popisující stav provedených testů (celkovou prověřenost systému). Testování určité oblasti se považuje za ukončené, jsou-li úspěšně ukončeny všechny dílčí testy. Tímto způsobem je přesunuta vyšší míra zodpovědnosti na role spravující výsledky jednotlivých testů.

34

4.2.4 Aktivity Z jednotlivých aktivit je sestaveno výsledné testovací workflow. Nebudou popisovány triviální aktivity, nebo aktivity převzaté kompletně z RUPu. Naopak budou důkladně popsány aktivity, které odlišují tuto metodika a přináší očekávané výhody. Plánování testů Nedílnou součástí plánování testů je i odhadování kapacit potřebných pro jejich vykonání. Pro odhadnutí pracnosti je nezbytné se s daným požadavkem (funkcionalitou) blíže seznámit a velmi hrubě popsat kroky nutné pro otestování. Tato aktivita je prováděna rolemi, které se budou následně zabývat podrobnějším popisem dané funkcionality, mohou tedy později využít poznatky získané při odhadování pracnosti. Psaní Testovacích scénářů a Test scriptů Tato aktivita probíhá průběžně mezi plánováním testů a samotným testováním. Je žádoucí, aby Testovací scénář byl napsán ještě před předáním dané funkcionality k testům. Test scripty je možné vytvářet až průběžně s průzkumným testování dané funkcionality, ale tak, aby byly hotové před další iterací, a bylo možné je použít pro integrační testy. Předání funkcionality k testům Na začátku každé iterace dochází k předávání nově dokončených funkčních celků k testům. Programátor interaktivně předvádí novou funkcionalitu. Přítomni jsou kromě testovacích rolí také analytici, kteří danou oblast navrhovali. Je nezbytné, aby test analytik již byl s danou oblastí přiměřeně seznámen, ideálně má již vytvořené testovací scénáře. Dochází zde k interakci tří vrstev ve vývoji – analýza, programování a testování. Programátor získá okamžitou zpětnou vazbu, analytik si ověří, že bylo vše vytvořeno tak, jak očekával. Test analytik si urovná nejasnosti, které vznikly při psaní testovacích scénářů. Výsledkem takovéto diskuze bývá obvykle seznam chyb, které je potřeba opravit. Programátor upozorňuje na slabá místa systému, ve kterých je vysoká šance na výskyt chyby, naopak na části funkcionality, která se na více místech opakuje a není tedy potřeba ji vícekrát podrobně prověřovat. Důležitým přínosem této aktivity je velmi brzské odhalení některých chyb. Test analytik a samotný tester získá lepší představu, jak má být tato funkcionalita testována, a na co se zaměřit, aby byla efektivita co nejvyšší. 35

Obr. 4.2: Předání funkcionality k testům Testy při sestavení iterace Při každém sestavení nové iterace dochází ke spuštění kompletní sady automatizovaných testů. Dojde tak k odhalení chyb vzniklých při integraci nové funkcionality. Tyto chyby musí být okamžitě odstraněny a dochází k opětovnému sestavení iterace. Iterace se považuje za předanou k testům až tehdy, projde-li sadou automatizovaných testů bez chyby. Průzkumné testování Před započetím důkladného testování určité funkcionality – provádění testovacího scénáře – jsou provedeny průzkumné testy. Tester ověřuje funkcionalitu do šířky místo do hloubky. Cílem je projít celou funkcionalitu bez zkoumání detailů v co nejkratším čase, tak aby se okamžitě odhalilo co možná nejvíce chyb, které by později mohly bránit v dalších testech. Toto je důležité především u větších funkčních celků. Čím dříve je chyba odhalena, tím dříve a snadněji je opravena. Tímto způsobem je možné se vyhnout situacím, kdy je na začátku iterace objevena chyba, které zastaví testy po dobu celé iterace, a přitom mohla být odhalena už v té předchozí. Testování a vytváření Test resultů Podrobné testování spolu s vytvářením Test resultů probíhá až po provedení průzkumných testů. V každé iteraci se nevytváří nové Test resulty – pouze dochází k jejich aktualizaci. Během testů je v Test resultu průběžně evidován 36

stav provedených testů dané oblasti – procentuální odhad dokončených testů spolu s počtem nevyřešených chyb zaevidovaných při testech dané oblasti. Konzultace s analytiky, resp. programátory Konzultace probíhají často v průběhu celého vývojového cyklu, kdykoliv se vyskytne nějaká nejasnost, např. v use-case modelu. Test analytik konzultuje s analytikem správné chování systému při psaní Testovacích scénářů. Tester konzultuje při provádění testů – a to buď s analytikem nebo s programátorem, na základě charakteru nejasnosti. Dochází tak k neustále zpětné vazbě pro analytiky (programátory) a eliminují se neodhalené chyby vzniklé špatným chápáním problematiky. Zaevidování chyby Při detekování chyby, ještě než je zaevidována a odeslána programátorovi na opravu, provádí tester její lokalizaci. Je v dané chvíli – na rozdíl od programátora – seznámen s konkrétní situací a může proto pro něj být daleko snazší příčinu odhalit. Pokud chybu úspěšně lokalizuje, ušetří tím mnoho času při její opravě, ale hlavně poté dokáže efektivněji ověřit její odstranění. Při hledání příčiny tester mnohdy dojde k závěru, že se o chybu nejedná, ale jedná se pouze o chybné nastavení aplikace nebo špatně připravená data. Tímto ušetří čas sobě, ale hlavně dalším, kteří by se chybou zbytečně zabývali. Tento subproces je znázorněn na obrázku níže.

Obr. 4.3: Subproces detekce chyby 37

Zkracování iterací V průběhu vývoje dochází k postupnému zkracování iterací. Podle rozsahu projektu, úvodní iterace mohou trvat i jednotky měsíců, závěrečné iterace však maximálně jednotky dnů. Z pohledu testů dochází v úvodních iteracích spíše ke psaní Testovacích scénářů, zároveň se vyvíjí největší funkční celky, které nelze dělit na menší části. V pozdějších částech objem testů přibývá a je potřeba opravovat chyby rychleji, aby mohly testy pokračovat. Automatizované testy součástí manuálního testování Metodika využívá automatizované testy nejen jako sadu integračních testů, ale i jako pomůcku při manuálních testech. Často je potřeba pro provedení manuálního testu předem připravit sadu vstupních dat uložených v databázi. Manuální vytvoření těchto dat bývá náročné. Pokud existuje automatizovaný test ověřující funkcionalitu zabývající se vytvářením těchto dat, je možné jej opakovaně spustit – ne za účelem ověření procesu tvorby dat, ale kvůli datům samotným, které lze poté použit pro manuální testy. Tuto aktivitu lze použít pouze v případě, kdy je vyvíjena aplikace používající databázová data. Reportování stavu testů Celkový stav dokončených testů je určován z kompletní sady Testovacích scénářů. Z Návrhu testů je zjištěn celkový odhad trvání dílčího testu a z Test resultu aktuální stav testu. Takhle jsou pro jednotlivé Testovací scénáře zjištěny kapacity potřebné pro dokončení. 4.2.5 Workflow Sled dílčích aktivit je znázorněn na obrázku workflow níže. Celý proces začíná návrhem dílčích testů a jejich plánováním (odhadováním potřebných kapacit). Pak následuje psaní testovacích scénářů a test scriptů. Posloupnosti jednotlivých aktivit nejsou striktní, slouží spíše pro názornost. Psaní scriptů a scénářů probíhá částečně už při plánování testů a pokračuje ještě dlouho poté, co byly započaty testy. Každá iterace začíná integračními testy – další testy nepokračují, dokud integrační testy neprojdou bez chyby. Zároveň probíhá předávání nové funkcionality k testům. Následují průzkumné testy a poté důkladné testy spolu s vytvářením Test resultů. Poté následuje další iterace – dochází k jejich postupnému zkracování. V průběhu celého procesu jsou prováděny časté konzultace s analytiky a programátory. Průběžný stav testů je neustále vyhodnocován a reportován. 38

Obr. 4.4: Testovací workflow

4.3 Srovnání Na obrázku Obr. 4.5 jsou znázorněny jednotlivé aspekty metodiky – část z nich vychází z principů rigorózních metodik a druhá část posouvá metodiku směrem k metodikám agilním. Metodika si zachovává klasické členění na role odpovídající jednotlivým fázím projektu. Na rozdíl od rigorózních metodik je nezbytný kvalifikovanější tým, na jednotlivé členy je kladena vyšší zodpovědnost. Jednotlivý členové týmu musí být v rámci jednoho požadavku schopni zastávat více různých testovacích rolí, což přináší vyšší efektivitu práce (odpadá nutnost nastudování požadavku v návazných aktivitách). Práce je různorodější a tedy i zábavnější – zaměstnanci jsou více motivovaní. Důsledkem je i menší potřeba objemné dokumentace, i když vytváření Testovacích scénářů a Test resultů stále přetrvává – testování je tedy vůči zákazníkovi zdokumentované. Stejně jako v RUPu je základní popis systému 39

proveden sadou use-case. Využívání metodiky není podmíněno přímou účastí zákazníka na projektu. Menší objem dokumentace je kompenzován intenzivnější komunikací nejen v rámci týmu, ale i napříč celým spektrem rolí (analytici, programátoři). Z této spolupráce vyplývá lepší pochopení problému a tedy i efektivnější a rychlejší odhalování chyb. Tomu napomáhá i dynamické zkracování iterací směrem ke konci projektu. Ačkoliv manuální testování zůstává stěžejním, velký objem testů je prováděn automatizovaně, především při sestavení iterace, což opět napomáhá brzskému odhalení chyb.

Obr. 4.5: Porovnání metodiky Metodika zůstává použitelná pro široké spektrum firemních kultur a druhů projektů. Omezení agilních metodik popsaná v předešlé kapitole zde neplatí. Pokud jsou v organizaci zavedené klasické (rigorózní) procesy, není třeba firemní kulturu žádným zásadním způsobem měnit, spíše po malých krocích přizpůsobovat. I přes menší objem organizační dokumentace má management stále plnou kontrolu nad projektem. Určitým omezení je zde pouze 40

potřeba kvalifikovanějších zaměstnanců. Nejsou kladena žádná omezení na velikost ani strukturu týmu, tak jako v agilních metodikách. Stejně tak není nezbytná přímá účast zákazníka. Vzhledem k existující dokumentaci všech provedených testů a vzhledem k systematickému přístupu k jejich provádění je metodika uplatnitelná i na komplexní a kritické systémy.

41

5 Případová studie, verifikace metodiky V následujícím textu je představen fiktivní, velice zjednodušený projekt vývoje informačního systému z oblasti bankovnictví. Popis je omezen pouze na činnosti týkající se řízení kvality v rámci tohoto projektu. Nejprve je demonstrováno využití nově navržené metodiky a jsou odhadnuty doby trvání některých dílčích aktivit. Následně je provedeno srovnání s odhady dob trvání ekvivalentních aktivit v situaci, kdy by byla použita klasická rigorózní metodika. Pro zjednodušení je srovnání provedeno s metodikou RUP. Cílem této konfrontace je poskytnout důkaz, že nově navržená metodika skutečně přináší zvýšení efektivity při vývoji softwaru v oblasti řízení kvality. Přínos některých dílčích aktivit je prokázán i údaji z reálných projektů, kde byly tyto aktivity použity.

5.1 Definice projektu Zadavatelem projektu je finanční instituce střední velikosti, která potřebuje vytvořit informační systém pro správu svých klientů a jejich finančních produktů. Systém bude dále provádět veškeré účetnictví týkající se správy produktů a také podporovat platební styk jednak v rámci instituce, ale také mezi ostatními finančními institucemi, včetně zahraničního platebního styku. Součástí systému je správa uživatelů umožňující definovat jednotlivé uživatelské role a skupiny.

5.1.1 Funkční moduly Celý systém je rozdělen na menší funkční celky definující specifické oblasti. Jednotlivé funkční moduly jsou ve fázi specifikace dekomponovány na ještě menší části odpovídající dílčím požadavkům. Pro jednoduchost v rámci této práce zůstaneme na úrovni celých funkčních modulů a další dělení bude jen nastíněno. Tato dekompozice na dílčí požadavky umožňuje systém vyvíjet iterativním způsobem. Dále budou stručně popsány jednotlivé funkční moduly. Evidence osob Funkcionalita umožňuje evidovat veškeré osoby, které jsou v nějakém vztahu k finanční instituci. Jsou evidovány jejich komunikační kanály, doklady, vztahy 42

mezi osobami, informace o důvěryhodnosti, apod. Součástí je i kartotéka provedených změn osob. Tato funkcionalita je dále dělena na fyzické a právnické osoby. Evidence produktů Zde jsou evidovány finanční produkty, které mají klienti u této instituce vedené. Tato funkcionalita je dělena na produkty spořící a úvěrové. Jednotlivé produkty se mohou nacházet v různých stavech a lze nad nimi provádět mnoho různých akcí. Evidence rolí Tato evidence vyjadřuje vztahy osob z Evidence osob k produktům. Představuje role osob k jednotlivým produktům jako je majitel, zákonný zástupce, disponent, ručitel, přistupitel, apod. Jsou zde definovány například korespondenční adresy jednotlivých osob pro různé produkty. Platební styk Tato funkcionalita umožňuje přesouvat finanční prostředky v rámci instituce (vnitřní platební styk) a mezi institucí a vnějším světem (vnější platební styk) – příjem a výdej prostředků na pokladně a platební styk mezi různými institucemi prostřednictvím České národní banky. Veškerý pohyb finančních prostředků je evidován a archivován. Jsou umožněny různé druhy platebního styku (jednorázový příkaz, inkaso, trvalý příkaz, SIPO, apod.) Účetnictví Funkcionalita účetnictví bude rozdělena především na finanční účetnictví a klientské účetnictví. Klientské účetnictví bude umožňovat správu bankovních kont a subkont pro jednotlivé produkty a úročení prostředků na nich uložených v čase s následným připisováním, resp. účtováním úroků. Finanční účetnictví bude umožňovat mapování těchto kont na finanční účty, což umožní lepší sledování obratů finančních prostředků, reportování a exportování účetních dat do externích účetních systému za účelem vykazování zisků. Správa uživatelů Funkcionalita umožňuje správu oprávnění pro jednotlivé úlohy a funkce sytému. Umožňuje definovat skupiny a přiřazovat jim sady těchto oprávnění. Dále umožňuje vytvářet uživatele různých typů a zařazovat je do různých skupin, čímž bude plně definována možnost jejich přístupu k systému. 43

5.1.2 Tým kontroly kvality Tým testerů zabývající se řešením tohoto projektu se skládá z deseti osob rozdělených do dvou skupin. Obě skupiny mají jednu osobu v roli Test manažer a jednu osobu v roli Správce automatizovaných testů. V rolích Test analytik a Tester jsou alespoň částečně všechny osoby v týmu. Rozdíl je pouze v tom, na kterou z těchto rolí je kladen větší důraz. Obě skupiny mají alespoň dvě zkušenější osoby, které kladou větší důraz na roli Test analytik (zde patří vždy i osoba v roli Test manažer). Zbývající méně zkušené osoby jsou více vytěžovány v roli Tester.

5.1.3 Časové propozice projektu Řešení projekt je naplánováno na dobu deseti měsíců. První dva měsíce jsou věnovány především specifikaci požadavků a návrhům architektury, apod. Od třetího měsíce se začínají vytvářet již první Návrhy testů. Souběžně s tím vzniká use-case model systému a je možné začít vytvářet první Testovací scénáře. První funkční prototyp je naplánován do konce čtvrtého měsíce. Začínají vznikat Test skripty a provádí se první průzkumné testy a vznikají první verze Test resultů. Zaznamenávají se odhalené chyby. První dvě iterace jsou měsíční, od sedmého měsíce jsou čtrnáctidenní a od devátého měsíce týdenní, přičemž zde už mohou vznikat i mimořádné iterace v případě potřeby. Jednotlivé funkční moduly jsou vytvářeny přibližně v pořadí, v jakém byly popsány, přičemž jejich vytváření se samozřejmě prolíná.

5.2 Implementace dílčích aktivit Pro účely ověření efektivity nové metodiky nebude průběh projektu popsán jako celek od začátku do konce, ale budou vyjmuty dílčí fragmenty odpovídající aktivitám navržené metodiky. Metodika pokrývá svými aktivitami veškeré podstatné procesy řízení kvality, lze tedy tvrdit, že v popise průběhu projektu nejsou vynechány žádné neefektivní nebo nedomyšlené části. Odhady trvání dílčích aktivit jsou smyšlené a slouží hlavně pro srovnání se situacemi, kdy by aktivity z navržené metodiky nebyly použity. Počty použití dané aktivity v uvedených případech slouží k tomu, aby bylo možné pracovat s průměrnou dobou trvání této aktivity, a nemusí odpovídat skutečné četnosti použití aktivity v rámci projektu. 44

Návrhy testů a psaní Testovacích scénářů Návrhy testů dílčích požadavků spolu s odhadováním potřebných kapacit jsou vytvářeny od třetího měsíce projektu. Touto aktivitou se zabývají v obou týmech tři osoby – Test manažer a další dva zkušenější testeři. Je třeba vytvořit návrhy testů pro sto požadavků, přičemž průměrná doba trvání této aktivity jsou čtyři hodiny. Z toho dvě hodiny připadají na seznámení se s požadavkem a další dvě hodiny na vlastní návrh testů a odhad potřebných kapacit. Pro těchto sto požadavků je následně potřeba napsat Testovací scénáře. Tato aktivita je zahájena od čtvrtého měsíce a zabývají se jí všichni členové týmu. Průměrná doba potřebná na vytvoření Testovacího scénáře je osm hodin, z toho dvě hodiny připadnou na seznámení se s požadavkem. Prioritně píší konkrétní scénáře osoby, které se předtím zabývaly návrhem testů daného požadavku. Výhodou je to, že se nemusí již s požadavkem seznamovat. Z kapacitních důvodů je nutné pro psaní Testovacích scénářů využít i členy týmu, kteří návrhy testů nevytvářeli, návrh testů i scénář tedy bude vytvářet tatáž osoba pouze v šedesáti procentech případů. Celkové potřebné kapacity pro tyto dvě aktivity shrnuje tabulka Tab. 5.1. Stejné osoby (60%) Odlišné osoby (40%) Celkem Návrhy testů 60*4 = 240 h 40*4 = 160 h 400 h Testovací scénáře 60*6 = 360 h 40*8 = 320 h 680 h Celkem 600 h 480 h 1080 h Tab. 5.1: Kapacity návrhu testů a psaní Testovacích scénářů Tímto způsobem jsou v šedesáti procentech případů ušetřeny dvě hodiny potřebné pro seznámení se s požadavkem před vlastním psaním testovacího scénáře. Oproti situaci, kdy by na návaznost těchto dvou aktivit vzhledem k osobám, které je provádí, vůbec nebylo dbáno, je tímto způsobem ušetřeno 120 hodin času. Předání k testům Vždy před zahájením každé nové iterace jsou předávány nově naimplementované požadavky k testům. Nejsou předávány požadavky triviálního charakteru – průměrně je předáváno šedesát procent požadavku z celkového objemu dokončených, zbývající není třeba předávat. Předávání jednoho požadavku trvá průměrně půl hodiny a účastní se ho analytik, programátor a jeden až dva testeři, v závislosti na rozsáhlosti požadavku. Průměrně ušetří toto předání přibližně patnáct procent času potřebného 45

na testování a také na opravu chyb. V mnoha případech totiž odpadá následná potřeba vyjasňovat určité detaily s analytikem – je vyřešeno na místě. Při průměrné době testování požadavku ve výši dvaceti hodin s připočtením pěti hodin následných oprav chyb jsou ušetřeny necelé čtyři hodiny. Oproti celkové hodině a půl času všech zúčastněných zde nastává zvýšení efektivity.

Obr. 5.1: Využité kapacity oproti naplánovaným Na obrázku Obr. 5.1 lze pozorovat procentuální poměr skutečně využitých kapacit oproti naplánovaným v reálném projektu v době, kdy se začínala používat aktivita předání k testům. V rámci projektu tedy některé požadavky předány nebyly, i když by dle popisované aktivity bylo vhodné je předat, a některé požadavky předány byly. Procentuální hodnoty představují průměrné množství spotřebovaných kapacit oproti naplánovaným na vzorku asi padesáti předaných a stejném počtu nepředaných požadavků. Lze pozorovat dosti výrazný pokles spotřebovaného času oproti naplánovanému. Určitou negativní kompenzaci představují kapacity spotřebované na samotné předávání. Samozřejmě je podstatné, jaká pracnost byla pro daný požadavek odhadnuta – byla-li pracnost odhadnuta optimisticky či pesimisticky. Výsledek ovšem vychází z relativně velkého vzorku požadavků, dá se tedy tvrdit, že pokles spotřebovaných kapacit není způsoben chybnými odhady pracnosti. Výhledově se dá ovšem předpokládat, že procento spotřebovaných kapacit bude opět růst, protože odhadované kapacity budou určovány v budoucnu přesněji, s ohledem na výhody aktivity předání. 46

Testy při sestavení iterace Automatizované testy se začínají vytvářet od pátého měsíce vždy pro dílčí funkční celky ihned po jejich vytvoření. Při sestavení každé nové iterace je spuštěna sada automatizovaných testů. Automatizované testy simulují pouze základní průchod aplikací, nezabývají se detaily. Jsou proto odhalovány především zásadní problémy, které by bránily testování. Tyto problémy jsou ihned odstraněny, ještě před předáním iterace k testům.

Obr. 5.2: Počty chyb odhalených testery Na obrázku Obr. 5.2 je vidět graf znázorňující celkové počty chyb odhalené v letech 2009 až 2012, kdy bylo v reálné firmě zabývající se vývojem software zaváděno používání automatizovaných testů při sestavování nových iterací. Chyby jsou barevně rozlišené podle jejich závažnosti. Chyby typu A jsou závažné a brání dalšímu testování dané oblasti. Chyby typu C naopak nebrání testování ani používání aplikace a představují pouze drobné nedostatky, s jejichž přítomností může aplikace fungovat. Lze vidět, že se zvětšujícím se objemem prováděných automatizovaných testů od roku 2009 ubývají testery odhalené chyby typu A. Důvodem je to, že se k testům ani nedostaly a byly odstraněny ještě před předáním iterace k testům. Díky tomu bylo více času na testování aplikace více do hloubky a testování větších detailů. O tom svědčí nárůst počtu chyb typu C. Aplikace je tedy podstatně lépe otestována a jsou 47

odstraněny i drobnější chyby, které by jinak byly uvedeny do provozu. Lze tedy tvrdit, že celková kvalita produkovaného softwaru vzrostla. Průzkumné testy Průzkumné testy jsou prováděny pro všechny nově dokončené požadavky co nejdříve po sestavení iterace, výsledky těchto testů nejsou nijak dokumentovány, výstupem jsou pouze defekty. Průměrná doba trvání průzkumného testu pro jeden požadavek jsou dvě hodiny. Výsledkem průzkumného testu jsou průměrně dvě chyby kategorie A, které by jinak byly odhaleny až v další iteraci, ve které by bránily dalšímu testování požadavku. Při čtrnáctidenní iteraci jsou dvě hodiny věnované průzkumným testům zanedbatelnou položkou oproti zpoždění testování požadavku o čtrnáct dní, pokud by byla objevena chyba na začátku iterace bránící dalšímu testování. Evidování chyb a následná kontrola provedené opravy Pro ukázku této aktivity budeme uvažovat reprezentativní vzorek potenciálních chyb v počtu jednoho tisíce. Okamžitě poté co tester chybu odhalí, provádí její lokalizaci, která trvá průměrně dvacet minut. V třiceti procentech je při lokalizaci zjištěno, že se ve skutečnosti o chybu nejedná a dále se s ní tedy nepracuje. Zbývajících sedmdesát procent, úspěšně či neúspěšně lokalizovaných, je předáno k opravě. Díky provedené lokalizaci testerem je další lokalizace chyby zkrácená průměrně z půl hodiny na dvacet minut. Poté, co je chyba opravena, je nutné opravu zkontrolovat. Díky informacím zjištěným při lokalizaci je průměrná doba této kontroly zkrácena z půl hodiny na patnáct minut. V následující tabulce Tab. 5.2 je vidět rozdíl mezi situacemi, kdy je lokalizace testerem prováděna, a kdy není. Je chyba (70%) Není chyba (30%) S lokalizací: Lokalizace – testy 700*1/3 = 233 h 300*1/3 = 100 h Lokalizace - oprava 700*1/3 = 233 h 0h Kontrola opravy 700*1/4 = 175 h 0h Celkem 641 h 100 h Bez lokalizace: Lokalizace – testy 0h 0h Lokalizace - oprava 700*1/2 = 350 h 300*1/2 = 150 h Kontrola opravy 700*1/2 = 350 h 0h Celkem 700 h 150 h Tab. 5.2: Evidování chyb s lokalizací a bez lokalizace

Celkem 333 h 233 h 175 h 741 h 0h 500 h 350 h 850 h

48

5.3 Shrnutí Efektivita řízení kvality pomocí nově navržené metodiky byla prokázána v rámci jejích dílčích aktivit částečně údaji z reálných projektů a částečně pouhými odhady. Statistické údaje z reálných projektů po zavedení vylepšených procesů řízení kvality prokazatelně ukazují, že opravdu došlo ke zlepšení efektivity. Důvodem, proč bylo zvýšení efektivity u ostatních aktivit prokázáno pouhými odhady, je nedostupnost reálných statistických dat toto zlepšení prokazujících. Nicméně veškeré odhady jsou postaveny na reálných podkladech získaných při používání těchto aktivit ve skutečných situacích. Některé podpůrné aktivity jako je Reportování, Zkracování iterací, Konzultace, apod. nejsou v případové studii zmíněny, jelikož není možné prokazovat jejich efektivitu samostatně, ale pouze jako součást celku.

49

6 Závěr Cílem práce bylo navrhnout novou metodiku řízení kvality při vývoji softwarových systémů, která bude založena sice na principech klasických rigorózních metodik, ale bude využívat množství agilních prvků. Záměrem bylo, aby metodika využívala co nejvíce pozitivních jevů agilního vývoje, ale zároveň neobsahovala omezení platící pro ryze agilní metodiky. Úvodní kapitola pojednává o testování jakožto o disciplíně vývoje softwarových systémů, popisuje typy testům dle různých kritérií, rozebírá odlišné způsoby testování a přináší sadu doporučení pro co nejvyšší efektivitu a účinnost prováděných testů. Následující kapitola popisuje a srovnává různé přístupy řízení testovacího procesu. Nejprve jsou pro úplnost představeny historické způsoby vývoje, z kterých pak vychází dva odlišné směry – agilní a rigorózní metodiky. Tyto dva směry jsou popsány a srovnány na konkrétních příkladech metodik. V závěru kapitoly jsou identifikovány a rozebrány omezení platící pro agilní způsoby vývoje.

6.1 Výstupy práce Hlavním výstupem celé práce je návrh a podrobný popis nové metodiky splňující všechny stanovené cíle. Úvodem bylo konstatováno a doloženo, že zavádění agilních prvků do klasických metodik obecně je současným trendem, nicméně pouze lokálně vždy jen v rámci několika málo činností. Navržená metodika oproti tomu přináší sadu agilních prvků komplexně do celé oblasti řízení kvality. Je provedeno srovnání dílčích prvků navržené metodiky s agilním a rigorózním přístupem. Následně je zdůvodněno, proč pro metodiku neplatí omezení agilních metodik. Použití metodiky je demonstrováno na projektu vývoje informačního systému, který je sice fiktivní, ale vychází z reálných údajů. Efektivita několika nových aktivit byla doložena daty z reálných projektů firmy, ve které došlo k zavedení těchto dílčích procesů. V těchto případech lze konstatovat nárůst efektivity. Pro zbývající aktivity jsou provedeny odhady průměrné pracnosti těchto činností, které jsou konfrontovány se situacemi, kdy tato vylepšení využita nejsou. V rámci těchto odhadů lze taktéž konstatovat nárůst efektivity. 50

6.2 Výhled Směry dalšího výzkumu v této oblasti jsou dva. Prvním z nich je zavedení zbývajících aktivit, u nichž byla efektivita prokázána pouhým odhadem, do reálného provozu a sesbírání reálných dat prokazujících skutečné navýšení efektivity. Dalším směrem, kterým by se mohla tato práce vyvíjet, je prozkoumání možností zavedení agilních prvků do zbývajících disciplín vývoje softwarových systému a rozšíření metodiky tímto směrem.

51

7 Citovaná literatura [Amb12] AMBLER, Scott. Agile Modeling and the Unified Process [on-line]. [cit. únor 2013]. Dostupný na WWW: [Bec02] BECK, Kent. Extrémní programování. 1. vyd. Praha: Grada Publishing, 2002. 158 s. ISBN: 80-247-0300-9. [BJR99] BOOCH, Grady, JACOBSON, Ivar, RUMBAUGH, James. The Unified Modeling Language User Guide. Addison Wesley Longman, Inc., 1999. [Buc05] BUCHALCEVOVÁ, Alena. Metodika Feature-Driven Development neopouští modelování a procesy, a přesto přináší výhody agilního vývoje. In: Tvorba softwaru 2005. Ostrava: Tanger, 2005, s. 25–30. ISBN 80-86840-14-X. [Buch05] BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 1. vyd. Praha: Grada, 2005. 163 s. Management v informační společnosti. ISBN 80-247-1075-7. [Col09] COLLET, Bruno. Limitations of Agile Software Development [on-line]. [cit. únor 2013]. Dostupné na WWW: [Dev12] DEVASHISH, Jain. Software Testing Models [on-line]. [cit. únor 2013]. Dostupné na WWW: . [Dou04] DOUCEK, Petr. Řízení projektů informačních systémů. 1. vyd. Praha: Professional publishing, 2004. 168 s. ISBN: 80-86419-71-1. [Hla12] HLAVA, Tomáš. Testování softwaru [on-line]. [cit. leden 2013]. Dostupné na WWW: .

52

[Hon11] HÖNIGSCHMIED, Pavel. 3 pilíře strategie testování. Komix noviny. Praha: Komix s.r.o., 2011, roč. 2011/2012, s. 3-5. [IBM05] IBM Rational Software. Principles of Software Testing for Testers: Student Guide: Volume 1 & 2: Version 2002.05.00. Rational University, 2005. [Kad04] KADLEC, Václav. Agilní programování – Metodiky efektivního vývoje softwaru. 1. vyd. Brno: Computer Press, 2004. 278 s. ISBN: 80-251-0342-0. [Kov12] KOVANIC, Jan. Zátěžové testování. Brno: Komix s.r.o., 2012. [Kro01] KROLL, Per. The Rational Edge: The Spirit of the RUP [on-line]. [cit. únor 2013]. Dostupný na WWW: [Kru00] KRUCHTEN, Philippe. The Rational Unified Process An Introduction. 2nd edition. Boston: Addison-Wesley, 2000. 298 s. ISBN: 0-201-70710-1. [Lep10] LEPKA, Jaroslav. Metody řízení projektů – cesta k efektivitě a úspěchu. Brno: Ústav automatizace a měřící techniky – VUT, 2010. [Mař07] MAŘÍK, Radek. Automatizace testování [on-line]. [cit. únor 2013]. Dostupné na WWW: . [PJR09] PAGE, Alan, JOHNSTON, Ken, ROLLISON, Bj. Jak testuje software Microsoft. 1. vyd. Brno: Computer Press, 2009. 384 s. ISBN: 978-80-251-2869-5. [Pat02]

PATTON, Ron. Testování softwaru. 1. vyd. Praha: Computer Press, 2002. 314 s. ISBN: 80-7226-636-5.

[Pou09] POULOVÁ, Ivana. Metody testování použitelnosti aplikací. Brno, 2009. Diplomová práce. Masarykova universita, Fakulta informatiky. 53

[ShW08] SHORE, James, WARDEN, Shane. The Art of Agile Development. 1st edititon. Sebastopol: O'Reilly Media, 2008. 415 s. ISBN: 978-0-596-52767-9. [Ski06]

SKIDMORE, Steve. Developing systems: The V model [on-line]. [cit. únor 2013]. Dostupné na WWW: .

[SWT12] SW Testování [on-line]. [cit. leden 2013]. Dostupné na WWW: . [TFR02] TUR, Dan, FRANCE, Robert, RUMPE, Bernhard. Limitations of Agile Software Process. In: Third International Conference on Extreme Programming and Flexible Processes in Software Engineering, XP2002, Alghero, Italy, 2002, s. 43 - 46. [Tiš11] TIŠNOVSKÝ, Pavel. Historie vývoje GUI: Textový procesor Microsoft Word pro DOS [on-line]. [cit. leden 2013]. Dostupné na WWW: . [Web07] WEBER, Filip. Penetrační testy v bezpečnostní analýze informačního systému [on-line]. [cit. únor 2013]. Dostupné na WWW: . [Zel12]

ZELENKA, Ivo. Základy Quality Assurance. Brno: Komix s.r.o., 2012.

54

A Software best practises Iteartivní vývoj softwaru Autoři RUPu vidí zásadní problém vodopádového modelu v tom, že chyby vzniklé v raných fázích projektu – při vytváření architektury a návrhu systému mohou být v tomto modelu detekovány až v pozdních fázích projektu. Jejich odstranění poté může vyžadovat velké změny v systému a bude časově náročné a drahé. Důsledkem může být zrušení celého projektu. Východiskem se jeví použití principů spirálového modelu, který tato rizika značně snižuje. Tento přístup zaručuje, že veškerá nedorozumění se zákazníkem budou odhalena brzy a bude snadné na ně reagovat. Další výhodou je časově rovnoměrnější zapojení jednotlivých rolí do procesu vývoje (testeři nepřijdou na řadu až na závěr projektu, kdy potom nebudou stíhat). Správa požadavků Požadavky zákazníků jsou dynamické a v průběhu životního cyklu vývoje se často mění. Je potřeba tyto změny evidovat, neustále vyhodnocovat a odvozovat z nich skutečně požadované chování systému. Požadavky je třeba prioritizovat a sledovat jejich naplňování. RUP doporučuje ke správě požadavků použít vhodný podpůrný nástroj. Architektura složená z komponent Vývoj softwaru založeného na komponentách přináší vyšší přehlednost systému - ve všech fázích systému a pro všechny zúčastněné. Tento přístup umožňuje použít již existující komponenty, ať už komponenty vyvinuté v předešlých projektech nebo z komerčně dostupných zdrojů, stejně tak je možné v budoucnu znovupoužít nyní vyvinuté komponenty. Tento přístup umožňuje snadnější rozdělení práce mezi vývojáře, zlepšuje spravovatelnost vyvíjeného systému a celkově zvyšuje odolnost systému vůči změnám. Vizuální modelování softwaru Model softwaru představuje zjednodušené zachycení reality popisující software z mnoha různých pohledů, což zjednodušuje pochopení celého systému. Takovýto model umožňuje najít společnou řeč mezi všemi osobami zapojenými do procesu vývoje, zvláště je-li použit některý standardizovaný modelovací jazyk. Vývoj systému na základě modelu zvyšuje konzistenci celého systému. RUP doporučuje použití UML (Unified Modeling Languague) [BJR99]. 55

Průběžné ověřování kvality softwaru Tato zásada úzce souvisí se zásadou o iterativnosti vývoje. RUP doporučuje provádět testování v každé iteraci a ověřovat kvalitu systému z různých pohledů, nejen z funkčního pohledu. Výhodou je, že aktuální kvalita softwaru může být objektivně posouzena na základě objemu provedených testů (pokrytí funkcionality) a jejich výsledků. Kontrola změn v softwaru Vývoj softwaru musí být kontrolovaný a jednotlivé aktivity a artefakty musí být evidovány. Každá provedená změna v softwaru musí být zaznamenána tak, aby vždy byly dohledatelné důsledky této změny. Kontrola změn je důležitá zvláště při práci ve více týmech na různých místech. Výhodou je možnost sledovat změny provedené v rámci jednotlivých iterací.

56

B Principy Agilního manifestu •

Naší nejvyšší prioritou je uspokojovat a průběžnými dodávkami kvalitního softwaru.

zákazníka

•

Vítáme požadavky na změnu – i v pozdních fázích vývoje. Agilní proces využívá změny jako možnost přinést zákazníkovi výhodu v konkurenčním prostředí.

•

Dodáváme fungující software často, v intervalech od několika týdnů až do několika měsíců – preferujme však kratší intervaly.

•

Lidé z obchodu a vývojáři musí spolupracovat na projektu každý den.

•

Projekty stavíme na motivovaných jednotlivcích. Dáme jim prostředí, potřebnou podporu a věříme jim, že odvedou svou práci.

•

Nejefektivnější způsob přenosu informací ve vývojovém týmu je přímá komunikace mezi lidmi.

•

Funkční software je primární míra pokroku.

•

Agilní přístup podporuje udržitelný vývoj. Investoři, vývojáři i uživatelé by měli být schopni udržet stejné tempo dlouhodobě.

•

Průběžný důraz na technickou dokonalost a kvalitu návrhu podporuje agilitu.

•

Zásadní je jednoduchost – umění maximalizovat množství neudělané práce.

•

Nejlepší architektura, specifikace od samo-organizovaných týmů.

•

V pravidelných intervalech se tým snaží zlepšit svou efektivitu.

požadavků

a

brzskými

návrh

pochází

57