Bakalářská práce. Redesign procesu testů a test management. Redesign of Test and Test Management Processes. Kateřina Urbanová

Transkript

1 Bakalářská práce Redesign prcesu testů a test management Redesign f Test and Test Management Prcesses Kateřina Urbanvá

2 Unicrn Cllege 2010 Unicrn Cllege, V Kapslvně 2767/2, Praha 3, Název práce v ČJ: Název práce v AJ: Autr: Redesign prcesu testů a test management Redesign f test and test management prcess Kateřina Urbanvá Akademický rk: 2009/2010 Kntakt: urbanva.katy@gmail.cm Tel: (+420)

3 1. Zadání 3

4 2. Abstrakt Budu psát fiktivní splečnsti na základě mých zkušenstí ze sučasnéh a minuléh zaměstnání. Tat splečnst má prblémy s kvalitu prduktu, které jsu způsbeny zejména nedstatečně rzvinutým prcesem testvání a test managementu. SW prdukt tét splečnsti je dcházkvý systém, který ddává vstupy pr výpčet mezd. Cílem práce bude navrhnut řešení na zefektivnění testvacích prcesů, eliminvat rizika spjená s nedstatečným testváním a tím zvýšit kvalitu výslednéh prduktu. Navrhnu metdiku testvání přím na tent specifický prjekt. Klíčvá slva: Testvání, metdika, testvací scénáře, autmatizvané testy, analytik, veducí prjektu, tester, vývjář 4

5 3. Abstract I will write abut a fictitius cmpany based n my experience f current and past emplyment. This cmpany has prblems with prduct quality, which are mainly due t an underdevelped testing prcess and test management. Sftware prduct that the cmpany is an attendance system that prvides inputs fr the calculatin f wages. The aim f the wrk will prpse slutins t streamline the testing prcess, eliminating the risks assciated with inadequate testing and thereby increase the quality f final prduct. I will prpse a methdlgy fr testing directly n this specific prject. Keywrds: Testing, methdlgy, test scenaris, autmated tests, Analyst, Prject team leader, Tester, Develper 5

6 4. Prhlášení Prhlašuji, že svu bakalářsku práci na téma Redesign prcesu testů a test management jsem vypracval samstatně pd vedením veducíh bakalářské práce a dbrným knzultantem, s pužitím dbrné literatury a dalších infrmačních zdrjů, které jsu v práci citvány a jsu též uvedeny v seznamu literatury a pužitých zdrjů. Jak autr uvedené bakalářské práce dále prhlašuji, že v suvislsti s vytvřením tét bakalářské práce jsem neprušil autrská práva třetích sb, zejména jsem nezasáhl nedvleným způsbem d cizích autrských práv sbnstních a jsem si plně vědm následků prušení ustanvení 11 a následujících autrskéh zákna č. 121/2000 Sb. V Praze dne Kateřina Urbanvá 6

7 5. Pděkvání Děkuji veducímu bakalářské práce Petru Hájkvi PhD za účinnu metdicku, pedaggicku a dbrnu pmc a další cenné rady při zpracvání mé bakalářské práce. 7

8 6. Obsah 1. Zadání Abstrakt Abstract Prhlášení Pděkvání Obsah Úvd O splečnsti IT ddělení Prjekt Dcházka a výkny Prces rzvje Identifikace prblémů IT ddělení splečnsti Návrh hřešení metdika testvání Prces testvání Plánvání testů Odhad nárčnsti testvání Naplánvání testů Specifikace testů Stanvení akceptačních kritérií Příprava testů Příprava analýzy pžadavků pr testvání Vytváření testvacích pžadavků Vytváření testvacích scénářů/skriptů Vytváření testvacích sestav Příprava testvacích dat Identifikace pžadavků na testvací prstředí Prvedení testů Prvedení/spuštění testů Vyhdncení testů Vytváření reprtů Správa chyb Zaznamenání chyb Sledvání zaznamenaných chyb Řízení testů Krdinace aktivit a mnitrvání testů Kmpletace specifikace testů Kmpletace akceptačních kritérií Řízení akceptace

9 10.2 Organizační struktura Analytik Test krdinátr Test analytik Tester Zařazení rlí d rganizační struktury splečnsti Autmatizvané testvání Testvací nástrje pr autmatizvané testvání Testvací scénáře Závěr Cnclusin Seznam pužité literatury Seznam brázků

10 7. Úvd Tat bakalářská práce je zaměřena na návrh řešení a zefektivnění testvacích prcesů fiktivní splečnsti. Tat fiktivní splečnst bude služit jak mdelvý příklad splečnsti se špatnu kvalitu výstupů. V některých blastech jsem se inspirvala splečnstí, ve které mmentálně pracuji. Především se v tét fiktivní splečnsti zaměřím na jeden knkrétní prjekt Dcházka a výkny. V kapitle O splečnsti přiblížím fiktivní splečnst, její prcesy, rganizační strukturu, kde se detailněji zaměřím na prjekt Dcházka a výkny. V další kapitle Identifikace prblémů IT ddělení ppíši výhdy a nevýhdy prcesů prjektu, knkrétně se zaměřím na vedení prjektu, analýzu, vývj a testy. V kapitle Návrh řešení metdika testvání redesignuji puze testvací prcesy. Tent návrh není myšlen jak všebecná metdika testvání, ale snažila jsem se tut metdiku navrhnut přím pr tent specifický prjekt fiktivní splečnsti. Při vytváření návrhu řešení jsem vycházela z metdiky Ratinal Unified Prcess splečnsti IBM Ratinal Sftware Crpratin. V práci se zaměřím i na mžnst využití nástrjů pr autmatizvané testvání. 10

11 8. O splečnsti Splečnst XYZ spl. s r.. vznikla v rce Má 7 pbček p celé České republice se sídlem v Praze. V pražské centrále je přím majitel splečnsti, který vydává nařízení pr pbčky v Čechách a Evrpě. Centrála zajišťuje bchd, utsurcing, vývj, servis a zákaznicku pdpru. Pbčky v Čechách a v evrpských zemích zajišťují puze utsurcing a bchd. Půvdně se splečnst zaměřvala na vývj a implementaci mzdvéh a HR sftwaru s česku a slvensku legislativu, p té rzšířila svu půsbnst i na pskytvání mzdvéh utsurcingu, který pskytuje i v něklika evrpských zemích: Bulharsk, Maďarsk, Plsk, Rakusk, Rumunsk, Rusk, Slvensk a Ukrajina. Obr. 1 Organizační struktura sídla v Praze Maijtel / Jednatel Prvzní asistentka Ředitel splečnsti Persnální ddělení Technické ddělení Oddělení zákaznické pdpry Helpdesk Oddělení utsurcingu Obchdní ddělení IT ddělení Mzdvý utsurcing, který pskytuje splečnst XYZ, je služba, kdy splečnst převezme agendu výpčtu mezd, včetně pvinnstí s tím spjených a dpvědnsti za vypčítaná data za klienta. Klient puze ddává pdklady ptřebné pr výpčet mezd (dcházka zaměstnanců, dvlené, neschpenky). Službu mzdvý utsurcing prvzuje na vlastním sftwaru, který vyvíjí a implementuje u klientů. 8.1 IT ddělení IT ddělení vyvíjí systém pr řízení lidských zdrjů, který pdpruje především mzdvé a persnální prcesy. Jedná se především rzvj sftwaru. Tent systém se knkrétně skládá ze základníh a nástavbvéh mdulu: 11

12 1. Základní mduly: Systémvý mdul Typickým uživatelem tht mdulu je administrátr aplikace, definuje uživatele a vytváří uživatelská připjení k aplikaci a databázi; knfiguraci přístupvých práv uživatelů k jedntlivým bjektům systému a knfiguraci parametrů systému. Analýza práce S tímt mdulem pracuje rganizační neb persnální útvar, evidence základních údajů druzích práce, funkcích a činnstech; definice dalších údajů - lékařské vyšetření stanvené předpisy, dbrná přezkušení a jejich peridicita, dpvědnsti, pravmci; analýza práce pmcí analytické bdvací metdy ILO. Pracvní místa S tímt mdulem pracuje rganizační neb persnální útvar, evidence rganizační struktury splečnsti včetně její verzvání; evidence pracvních míst včetně tarifníh zařazení; vymezení knkrétních nárků na pracvní způsbilst a sciální kmpetence zaměstnance na daném pracvním místě (upřesnění pžadavků vyplývajících z funkce, přiřazené danému pracvnímu místu); průřezvé sledvání bsazení pracvníh místa; sledvání limitů přesčasvé práce, definici kruhů tázek pr hdncení zaměstnance; evidenci vztahů mezi pracvními místy. Persnální evidence S tímt mdulem pracuje rganizační neb persnální útvar, evidence sbních a jiných údajů zaměstnanci; včetně údajů jeh rdinných příslušnících; adresách, předchzích zaměstnavatelích, praxi, pbíraných důchdech, změněné pracvní schpnsti apd.; sepsání pracvní smluvy; mzdvéh výměru, uknčení právníh vztahu, sledvání průběhu zaměstnání v rganizaci; sledvání nárků a čerpání dvlené; evidenci přihlášení ke zdravtní pjišťvně. Mzdy a platy S tímt mdulem pracuje mzdvý neb persnální útvar, Zadávání pdkladů pr výpčet mezd a výpčet mzdy; navázání na sdružené persnální mduly, práci s údaji, které sdílí s persnální evidencí; práci s kalendáři; práci s vlastními slžkami mezd (definvanými uživatelem); čerpání dat z dcházky, výknů resp. jinak zadaných mzdvých údajů. 12

13 2. Nadstavbvé mduly: Dcházka a výkny S tímt mdulem pracují liniví manažeři na nejnižším stupni rganizační struktury, persnální útvar a mzdvá účtárna, umžňuje ze sledvání dcházky a výknů, připravvat vstupy d mdulu mezd a platů pr výpčet mezd a platů a pr rzbrvu činnst; měsíční sledvání dcházky a výknů, které shrnuje data za jedntlivé dny měsíce; kntrlu pdkladů pr zúčtvání mezd, vlitelně naplňvat data přím v měsíční dcházce, neb z autmatizvanéh sledvání (například frmu magnetických karet); přerzdělvání dměn; autmatické genervání slžek mezd pdle výknů (příplatky za směnnst, prstředí. Obr. 2 Využití mdulů aplikace Organizační útvar Persnální útvar Mzdvý útvar Liniví manažeři Administrátr Analýza práce Systémvý mdul Pracvní místa Persnální evidence Mzdy a platy Dcházka a výkny Oddělení vede ředitel, který krdinuje 3 prjekty: prjekt Mzdy a Persnální evidence, prjekt Dcházka a výkny. Jedntlivé prjekty řídí veducí, kteří jsu zárveň hlavní analytici. Každý prjekt má k dispzici 2-3 vývjáře a 2-3 testery. Většina testerů jsu bývalé mzdvé účetní. 13

14 Obr. 3 Prjekty splečnsti IT ddělení Prjekt Mzdy Prjekt Persnální evidence Prjekt dcházka a výkny Obr.4 Persnální slžení prjektu Veducí a analytik Vývjáři Testeři Prjekt Dcházka a výkny Prjekt dcházka a výkny rzvíjí nástavbvý mdul pdle pžadavků klienta, řeší změnvé a chybvé pžadavky. Mdul dcházky se skládá ze systémvéh mdulu, tlustéh a tenkéh klienta. Systémvý mdul je určen pr knfiguraci a pracuje na bázi lkální aplikace, viz kapitla 8.1 IT ddělení. Tlustý klient je lkální aplikace s knektivitu na server, kde se upravují číselníky aplikace, vytváří struktura splečnsti, tvírají / zavírají jedntlivá bdbí a řídí samtná dcházka zaměstnanců. Systémvý mdul a tlustý klient dcházky pužívá na databázi Oracle. Tyt aplikace jsu vyvíjeny na platfrmě PwerBuilder. Tenký klient představuje aplikaci na bázi webvéh rzhraní, kde se puze řídí dcházka zaměstnanců. Servervá část tenkéh klienta je vyvíjena v bjektvém prgramvacím jazyku Java. C se týče persnálníh bsazení, tak prjekt řídí veducí prjektu, který je zárveň hlavní a jediný analytik, 2 vývjáři, 2 testeři, z th jeden na plviční úvazek. Veducí prjektu má za úkl krdinvat a řídit veškeré aktivity, které se dehrávají v rámci release či prjektu. Má na starsti IT analýzu, business analýzu. Také priritizuje příchzí pžadavky a prvádí analýzu jejich dpadu. Veducí se částečně pdílí i na rzvji tlustéh klienta a spravuje databázi prjektu. Pdřízení vývjáři rzvíjí především tenkéh klienta, nasazují nvé verze a patche. Testeři věřují správnst fungvání implementvané funkcinality, tedy zda dpvídá zadaným pžadavkům. 14

15 Prces rzvje P dluhleté zkušensti s vývjem sftwaru a pdle charakteru prjektu se splečnst víceméně přiblížila k mdelu Prgramuj a pravuj. Tent mdel zpravidla pužívají prjektvé týmy, který se nikterak nesnaží žádný jiný mdel. Tým, který se drží tht pstupu, začíná bvykle hrubu představu výslednéh prduktu, udělá si nějaký jednduchý návrh a pté vstupí d dluhéh, neustále se pakujícíh cyklu kódvání (prgramvání), testvání a pravvání chyb. 1 U th t mdelu je zpravidla nefrmální plánvání a analýza pžadavků, takže prjektvý tým vykazuje kamžité výsledky. Tester prakticky každý den testuje nvu neb aktualizvanu verzi sftwaru, kteru musí testvat. Prvede všechny ptřebné testy a kamžitě zaznamená chyby. 1 Obr. 5 Mdel Prgramuj a pravuj Prgramuj a pravuj Nefrmální analýza pžadavků Prgramvání Výsledný prdukt Opravvání Prces rzvje začíná správu pžadavků. Pžadavky představují nahlášené změny zadání a zjištěné chyby klientem, které psílá frmu u na Helpdesk. Ten pak zajišťuje jejich evidenci a písemnu kmunikaci s klientem. Z přijatých pžadavků se vytvří zadání pr release, tj. vyberu se pžadavky, které se budu v daném patchi neb verzi řešit a následně nasazvat u klienta. Pak prběhne vývj pdle zadání a jeh průběžné testvání. P dknčení všech testů se release nasazuje u klienta. Patch se vydává pravidelně každý měsíc neb i častěji v závislsti na závažnsti nalezených chyb v dané aplikaci. Verze se vydává 2x d rka a tvří ji všechny vydané patche d pslední vydané verze. 1 PATTON, Rn. Testvání sftwaru. s

16 Obr. 6 Prces rzvje Prces rzvje Řízení prjektu Správa pžadavků Analýza zadání Vývj Testvání Nasazení Jak nástrj pr sledvání a správu chyb (nebli bug-trackingvý nástrj) se na prjektu Dcházka a výkny pužívá aplikace, která byla splečnstí vyvinuta pr tyt účely. Pracuje na principu nastavení stavu řešení chyby jak u běžných bug-trackingvých nástrjů. Na každý pžadavek d klienta se v tét aplikaci zalží tzv. záznam chybě neb změně zadání. Záznamy jsu vždy prvázány s knkrétním pžadavkem d klienta. Veducí prjektu / analytik zdpvídá za jejich prvázanst. Tent bug-trackingvý nástrj služí jak hlavní kmunikační prstředek mezi vývjáři a testery. Na tmt prjektu se pužívá těcht 8 stavů, které jsu v aplikaci rzlišeny barvami pr lepší rientaci: 1. Vytvřený Záznam chybě vytváří buď analytik na základě změnvých pžadavků neb tester na základě nalezené chyby při testvání aplikace. 2. Přiřazený k řešení Analytik pak zhdntí závažnst chyby, ppřípadě dplní základní zadání pr vývjáře a h zařadí d příslušné verze neb patche. Ke každému záznamu přiřazuje knkrétníh vývjáře i testera, kteří budu záznam řešit. 3. Řešený Tent stav nastavuje vývjář ve chvíli, kdy na záznamu začíná pracvat. Veducí prjektu pak může sledvat, jaké záznamy jsu rzpracvané a který vývjář jej řeší. 16

17 4. Vyřešený k překladu Vývjář nastavuje tent stav, když je záznam vyřešen a připraven k překladu na testvací databázi. 5. K testvání Analytik tent stav nastaví p překladu záznamu na testvací databázi. 6. Vrácen k pravě Když pžadavek, na který byl záznam vytvřen, není správně naprgramván neb praven, tak tester vrací tímt stavem záznam vývjáři s ppisem chvání, který znvu musí tent záznam vyřešit. 7. Uzavřený Když tester věří správné chvání pžadavku, tak záznam se uzavírá. Analytik tent záznam průběžně zařadí kmentářů k verzi pr klienta. 8. Odlžený Když vedení prjektu rzhdne, že záznam se bude řešit v jednm z dalších patchů a zatím není zařazen d nějakéh knkrétníh patche. Obr. 7a Stavy záznamu chrnlgicky rzdělené pdle rlí Analytik Vytvřený Připraven k řešení K testvání Odlžený Vývjář Řešený Vyřešený Tester Vytvřený Vrácen k pravě Uzavřený 17

18 Obr. 7b Stavy záznamu chrnlgicky Vznik chyby Vytvřený Řešení dlžen Přiřazen k řešení Odlžený Předán k řešení Záznam zamítnut Vrácen k pravě Vrácen k dřešení Řešený Vyřešený K testvání Uzavřený Připraven k nasazení u klienta Oprava chyby uzavřena Zadání změn a analýza Analytik vypracvává z přijatých pžadavků zadání pr vývj a testy. Analýza zadání však prbíhá intuitivně a nefrmálně. Vývjář dstává zadání převážně v mluvené neb i v písemné frmě, které bsahuje základní bdy, jak má výstup fungvat. Určitá část zadání je tedy na iniciativě samtnéh vývjáře. Vývj Rzvj aplikací se prvádí na vývjářských databázích. Při prgramvání funkcinalit, ve frmě přidělených záznamů ze zadání pr release, se průběžně prvádí překlad na testvací databázi, na které pstupně testeři věřují správnst fungvání aplikace a naimplementvaných funkcinalit. 18

19 Vývjáři p sbě testují naprgramvané funkcinality jen základně na vývjářské databázi. Další testvání se prvádí na testvací databázi, která má pdbné prstředí jak klient. Testy Testeři testují puze přidělené záznamy spadající d určitéh release, žádné další testy se na tmt prjektu neprvádějí. Jedině na příkaz veducí prjektu, například testvání knkrétní určité funkcinality aplikace. Testvání funkcinality se prvádí intuitivně a nefrmálně, tj. neprvádí se pdle žádnéh testvacíh scénáře ani se nepužívají autmatické testy. Testeři testují naimplementvané funkcinality, které jsu průběžně překládány v rámci jednh zadání pr release. P věření správnsti fungvání dané funkcinality se uzavře příslušný záznam, tj. nastaví se d stavu Uzavřený záznam. Pkud funkcinalita správně nefunguje pdle zadání d analytika, tak se vrací zpátky vývji. P testvání všech přiřazených záznamů se vydává release, který si pak zákazníci sami nasazují. Tent realese klienti získají přes speciální zabezpečenu webvu stránku, kde si příslušný release stáhnu a nainstalují ve svém prstředí. Obr. 8 Prces zadání Klient Zadání Helpdesk Evidence Pžadavek Analytik Vytvření zadání Vývjáři Testeři 19

20 9. Identifikace prblémů IT ddělení splečnsti V tét kapitle se pkusím identifikvat základní prblémy na prjektu Dcházka a výkny. Prblémy ppíši pdle činnstí prjektu, tj. vedení prjektu, analýza, vývj a testy. Vedení prjektu Základní prblém lze vidět v tm, že veducí prjektu je zárveň analytik, správce databází a také rzvíjí tlustéh klienta. Je zdpvědný za příliš mnh funkcí. Většinu infrmací prjektu má veducí prjektu v hlavě a ne ve firemním systému neb v nějaké dkumentaci či prtklech. Tímt se také stává pr splečnst nenahraditelný a zárveň velkým rizikem. Veducí prjektu krdinuje a řídí lidi na prjektu chaticky, nejsu stanvena žádná pevná pravidla, pdle kterých by se prjekt řídil. Část zaměstnanců na prjektu fluktuje, většinu p 1 rce. Nejspíš prt, že ani p rce nejsu schpni prniknut d prcesů rzvje prjektu kvůli nekvalitní dkumentaci a nedstatku času veducíh prjektu. Analýza Klady: Analýza je zaznamenávána přím d záznamů, které jsu delegvány d vývje k řešení, cž zrychluje prces pravení chyby neb naprgramvání změnvéh pžadavku. Analýza prbíhá intuitivně a nefrmálně. Tent prces analýzy je rychlý a nízknákladvý. Pracvníci musí mít velmi dbru znalst aplikace, tvří se tím vysce expertní tým. Zápry: Analýza prbíhá intuitivně a nefrmálně. Je prblematické zašklit nvéh člena d týmu. Všichni pracvníci musí vědět aplikaci vše, nemhu být specializvaní na určitu blast. Zadání vývjářům i testerům je většinu v mluvené neb písemné frmě s ppisem základních bdů identifikvané chyby neb změněné funkčnsti. Prjektvá dkumentace není pravidelně aktualizvána. Prjektvá dkumentace bsahuje puze ppisy jedntlivých funkčnstí, tj. k čemu služí, ale již ne jejich prpjenst a vzájemnu závislst. Vývj Klady: Vývjáři mají velmi dbru znalst vyvíjené aplikace. Zápry: Vývjáři nepužívají ani nevytváří prgramátrsku dkumentaci, která by bsahvala například jednduché UML diagramy, kde by byl názrně zbrazen, jak aplikace funguje, jak mezi sebu kmunikují jedntlivé bjekty, jak je napjena na databázi, atd. Prt je aplikace vyvíjena nestejnrdě. 20

21 Vývj nepužívá žádný pdpůrný Framewrk. Framewrk je sftwarvá struktura, která služí jak pdpra při vývji a rganizaci jiných sftwarvých prjektů a zárveň sada daných pravidel vývje sftwaru. například připjení na databázi, vytvření nvéh dialgvéh kna pdle daných pravidel a implementačních vzrů apd. Testy Klady: Testeři jsu bývalé mzdvé účetní, které znají prblematiku zpracvání mezd, nepřítmnstí, příplatků a dcházky. Zápry: Testeři nepršli žádným šklení metdice a prcesu testvání, prt testvání prbíhá intuitivně a nefrmálně. Plánvání a příprava testů se na prjektu neprvádí. Nerealizuje se regresní testvání a ani se nepužívají nástrje pr autmatické testvání. Testvací data nejsu zadávána analytikem ani test analytikem. Tester je pužívá pdle svéh uvážení a ne pdle th, jak je pužívá klient. Testvací data na testvacích databázích nejsu naknfigurvána pdle klientskéh prstředí. 21

22 10. Návrh hřešení metdika testvání V tét kapitle se pkusím navrhnut metdiku testvání pr prjekt Dcházka a výkny. Návrh řešení vychází z metdiky Ratinal Unified. Ratinal Unified Prcess (RUP) je metdiku vývje sftwaru, kteru vytvřila americká splečnst IBM Ratinal Sftware Crpratin. RUP je nabízen jak kmerční prdukt, který IBM Ratinal Sftware Crpratin pskytuje především splečnstem zabývajících se vývjem infrmačních systémů a sftwarem becně. Je pužitelná pr jakýkliv rzsah prjektu, ale díky vyské rzsáhlsti RUPu jsem ji přizpůsbila pr ptřeby mdelvé splečnsti XYZ Prces testvání S blastí testvání suvisí celá řada prcesů, které se prlínají celým vývjvým cyklem. V návrhu metdiky testvání ppíši, jakým způsbem prběhne celkvá příprava testů (d naplánvání pr vytvření pdkladů pr testvání), prvedení testů, jejich vyhdncení a jaké jsu suvisející řídící prcesy. Prces testvání Obr. 9 Prces testvání Řízení testů Plánvání testů Testvání Příprava testvání Prvedení testů Vyhdncení testů Správa chyb Výchzím prcesem je Plánvání testů, v průběhu kteréh vzniknu před schválením rzsahu release dhady nárčnsti a základní specifikace testvacíh prcesu. Na prces Plánvání navazuje Příprava testů, kde vznikají pdklady pr realizaci testů a Prvedení testů. Realizvané 22

23 testy jsu průběžně vyhdncvány, zejména s hledem na pstup testvání a kvalitu testvané aplikace. Všechny testvací prcesy zastřešuje Řízení testů, v rámci kteréh prbíhá krdinace jedntlivých prcesů v rámci testvání a jejich sledvání Plánvání testů V průběhu plánvání testů prbíhá hrubý dhad nárčnsti testů. P zahájení release vzniká dkument Plán testů, kde je naplánvána časvá nárčnst a zdrje, které budu na testvání přiřazeny. Vzhledem k tmu, že Plán testů se vytváří suběžně se správu pžadavků, tak nejsu některé infrmace ještě k dispzici. Z th důvdu je Plán testů průběžně kmpletván v rámci Řízení testů. Plán testů bsahuje detailní rzpracvání činnstí realizvané při testvání, jejich rganizační zabezpečení a shrnutí dalších infrmací nezbytných pr krdinaci aktivit při testvání. Vytvření plánu je základem pr prces řízení testů, mnitrvání průběhu testů a hdncení efektivity a výsledků testů. S dbře vypracvaným plánem je mžné včas pdchytit ptenciální rizika a řešit prblémy, které se během prvádění testů bjeví. Plán testů bsahuje Harmngram testů Organizační zabezpečení testů Způsby testvání (viz kapitla 10.4 Testvací scénáře) Manuální testy Autmatizvané testy Regresní testy Typy realizvaných testů (viz kapitla 10.4 Testvací scénáře) Funkční testy Výknnstní testy Platfrmvé testy Testy GUI (graphical user interface) Odhady nárčnsti přípravy a realizace dílčích pdkladů Specifikace testvacích data jsu t pžadavky především na knfiguraci aplikace, např. jaká data budu ptřeba nahrát, aby se mhly prvést naplánvané testy. Pžadavky na testvací prstředí pr prvedení testvání Akceptační kritéria 23

24 P dhadu nárčnsti prběhne specifikace testů, která stanví základní přístup k testvání, tj. jaké jsu základní pdmínky, aby mhl být pžadavek testván, jaké typy testů (funkční, výknnstní,...) budu realizvány či zda bude například třeba realizvat regresní testvání, tj. testy zaměřené na úplné testvání celé aplikace. V tmt prcesu jsu rvněž jednznačně stanvena akceptační kritéria, která musí být bjektivní a měřitelná, které může bez prblému psudit 3. sba. Tyt kritéria musí být daná na začátku prjektu neb zadání nvé funkčnsti, prtže mhu být v dbě dknčvání zpchybňvána jak klientem, tak samtným ddavatelem. Obr. 10 Plánvání testů Plánvání testů Analýza pžadavků Odhad nárčnsti testvání Naplánvání testů Plán testů Specifikace testů Stanvení akceptačních kritérií Odhad nárčnsti testvání Analytik na základě zadání pžadavků a jejich analýzy dpadu identifikuje, jaké typy testů bude nad pžadavky třeba realizvat a nárčnst jedntlivých typů testů, např. klik času je ptřeba na prvedení všech testů a klik člvěkhdin. Na základě uvedených pdkladů bude mžné přesněji dhadnut nárčnst testů a s dstatečným předstihem zajistit zdrje nezbytné pr realizaci testů. Odhad nárčnsti je třeba detailněji specifikvat u kmplexnějších či nárčných pžadavků, u drbných pžadavků pstačí uvést celkvý dhad nárčnsti testů. Test krdinátr pak tent dhad pužije jak pdklad pr naplánvání testů. 24

25 Naplánvání testů Naplánvání testů prvádí Test krdinátr p zahájení prjektu na základě milníků vývje (dknčení vývje, předpkládané datum nasazení d u klienta apd.), ale v dstatečném předstihu před přípravu pdkladů pr testvání a realizací testů. Časvě Naplánvání testů spadá d etapy, kdy prbíhá příprava analýzy. Zde vznikne klíčvá část dkumentu Plán testů. Případné úpravy vznikléh plánu, které dále vyplynu z prbíhající analýzy a jsu dále prváděny v rámci prcesu Řízení testů Specifikace testů Specifikace prbíhá před Přípravu a Prvedením testů v rámci prcesu Plánvání testů, která je zahájena suběžně s analýzu a Naplánváním testů. Prces specifikace je jednu z činnstí Test krdinátra, které směřují k dalšímu zásadnímu dplnění Plánu testů. Cílem specifikace je shrmáždit bjektivní infrmace, na základě kterých je mžné v vytvřit harmngram a dhady kapacit. V rámci tht prcesu jsu realizvány následující činnsti: rzčlenění pžadavků d lgických částí, které má smysl testvat samstatně; rzhdnutí typech testů (funkční, výknnstní,...); zařazení pžadavků d testvacích sestav, které budu realizvány nad daným systémem; zvlení vhdných pdkladů, aby se ptimalizval zatížení pracvníků, kteří testvání budu realizvat; jak pdklady mhu služit následující: Testvací scénáře - jsu definvány u pžadavků, kde se předpkládá manuální testvání testery. Testvací skripty - vznikají/jsu aktualizvány u pžadavků testvaných autmatizvaným způsbem. Další úpravy specifikace, které jsu například dány na základě pkračujícíh analýzy, jsu realizvány v rámci prcesu Řízení testů při kmpletaci specifikace testů Stanvení akceptačních kritérií Akceptační kritéria v suvislsti s testváním služí jak pdklad pr plánvání, knkrétně v blasti dhadu celkvé dby testvání, typů testů a způsb jejich přípravy. Akceptační kritéria jsu základem dhdy mezi ddavatelem sftwaru a zadavatelem hledně kvality aplikace pžadvané ze strany zadavatelů. Z th důvdu akceptační kritéria musí být jednznačně definvána před vlastním prvedením testů. Je tedy třeba specifikvat kritéria c nejdříve, pněvadž mhu významným způsbem vlivnit následnu pracnst realizace pžadavků. Akceptační kritéria definuje Analytik při zpracvávání analýzy dpadu pžadavku na základě infrmací bsažených v zadání pžadavků a infrmací získaných při kmunikaci s klientem. Tat kritéria je třeba dsuhlasit ze strany klienta, aby mhly služit jak pdmínka akceptace. 25

26 Příprava testů Základními vstupy d přípravy testů je analýza pžadavků. Jak další, dplňkvé pdklady služí případné prvzní SLA a Plán testů. Příprava testů je zaměřena na vytvření pdkladů a dalších materiálů nezbytných pr efektivní prvedení testů. Pdklady mhu mít pdbu: Analýza pžadavků Testvací pžadavky Testvací scénáře / skripty Uvedené pdklady jsu rztříděny d testvacích sestav. V případě Analýzy pžadavků budu mít pdbu seznamu jedntlivých funkcinalit v přadí, v jakém se spuští, v případě testvacích scénářů půjde seznam přadí spuštěných pžadavků či jedntlivých scénářů a v případě autmatizvaných testvacích skriptů bude testvací sada vytvářena přím v pužitém nástrji. Krmě těcht pdkladů jsu připravvána i testvací data a jsu zadávány pžadavky na testvací prstředí (např. naknfigurvání databáze, způsb instalace, verze aplikace apd.). Příprava testů Obr. 11 Příprava testů Vytváření pdkladů Analýza pžadavků Příprava analýzy pžadavků pr testvání Vytváření testvacích sestav Testvací sestavy Plán testů Vytváření testvacích pžadavků Prvzní SLA Vytváření testvacích skriptů a scénářů Příprava testvacích dat Testvací data Identifikace pžadavků na testvací prstředí Testvací Prstředí 26

27 Příprava analýzy pžadavků pr testvání Analytik prvede Analýzu pžadavků, které využije jak sučást pdkladů pr realizaci testů a která budu následně zařazena d testvacích sestav. Sučástí je rvněž identifikace suvisejících testvacích dat Vytváření testvacích pžadavků Testvací pžadavky jsu jedním z pdkladů pr manuální testvání, které prvádí Analytik. Testvací pžadavky mhu vznikat kdykli během dby Přípravy testů. Pžadavky jsu v pdstatě nefrmalizvané pdněty na testvání ptenciálně prblematických situací. Analytik je vytváří jak dprvdné pznámky k analýze pžadavků, aby se na nic nezapmněl Vytváření testvacích scénářů/skriptů Testvací scénáře jsu jedním z pdkladů pr manuální testvání, které vytváří Test analytik pr Testery. Test analytik v rámci scénáře uvede jedntlivé krky: c přesně má testující udělat; na c kliknut; jaké hdnty / data zadat ; věřvací akce, tzn. kntrla čekávané chvání systému. Pr pužití autmatizvaných testů vytváří Test analytik ve zvleném nástrji Testvací skripty, které jsu autmatizvanu bdbu testvacích scénářů. Dá se čekávat, že prvtní záznam scénáře/skriptu bude vyžadvat výraznější pdpru ze strany Analytika, další úpravy scénáře/skriptu, však budu vyžadvat puze mezené knzultace Vytváření testvacích sestav Testvací sestavy jsu základní jedntku, nad kteru se plánuje a prbíhá testvání. Testvací sestavy jsu lgický sled jedntlivých pdkladů pr testvání, které dhrmady tvří jeden celek. Při vytváření sestavy pstupuje kmpetentní pracvník tím způsbem, že seřadí pdklady vytvřené k testvání určité funkcinality či skupiny funkcinalit d chrnlgickéh přadí, v jakém jsu za sebu realizvány. V případě manuálníh testvání vytváří Testvací sestavy Analytik. U autmatizvanéh testvání vytváří sestavy v příslušném nástrji Test analytik na základě infrmací d Analytika. 27

28 Obr. 12 Testvací sestavy Testvací sestavy Analýza pžadavků Testvací pžadavky Testvací scénář Testvací skript Příprava testvacích dat Data nezbytná pr prvedení testů jsu becně shrnuta v Plánu testů a knkrétně specifikvána v dalších výše uvedených vstupních dkumentech. Vývjář na základě uvedených vstupů připraví data pr testvání, cž bnáší (dle typů dat): návrh databázvých dtazů či skriptů pr vygenervání dat; vytvření vstupních dat (hdnty plí, tabulky, seznamy hdnt,...); vytvření čekávaných výsledků (výpčty, výstupy prvedených akcí); příprava výchzí sady dat před zahájením testvání Identifikace pžadavků na testvací prstředí Test krdinátr specifikuje knkrétní pžadavky na HW a SW vybavení testvacíh prstředí: jaké servery je třeba nainstalvat, knfigurace DB, serverů, vybavení testvacích stanic apd. Jsu definvány pžadavky na všechna prstředí pr všechny systémy a všechna stádia testvání, kterými implementvané změny prchází Prvedení testů Prvedení testů je realizván s využitím pdkladů a dalších materiálů vytvářených v předchzím krku. Samtné vyknání testů může mít dvjí pdbu: Prvedení testů v případě manuálních testů; Spuštění testů a dhled nad běžícími skripty. 28

29 Chyby, které jsu při testvání zachyceny, jsu zaznamenávány d k tmu určenéh nástrje. Na záznam chyb navazuje jejich sledvání p vyřešení chyby jsu prváděny retesty příslušných funkčnstí. Výstupy z prvedení či spuštění testů jsu výsledky testů. Výsledky testů mhu mít různu pdbu, která závisí především na charakteru testvacích sad. V případě manuálníh testvání půjde přehled výsledků jedntlivých scénářů. V případě autmatizvanéh testvání budu výsledky vygenervány přím z nástrje. Obr. 13 Prvedení testů Plán testů Prvedení testů Testvací sestavy Prvedení / spuštění testů Výsledky testů Aktualizvaný Plán testů Testvací data Retesty Správa chyb Naknfigurvané testvací prstředí Prvedení/spuštění testů Za prvedení a spuštění manuálních a autmatizvaných testů jsu zdpvědné rle Testera a Test analytika. Manuální testvání je prváděn pmcí Testvacích scénářů, za které je kmpetentní Tester. Při prvádění testů Tester průběžně zaznamenává Výsledky testů, aby zajistil plynulu správu pžadavků. Za realizaci autmatizvaných testů zdpvídá Test analytik, který spuští Testvací sestavy slžené z Testvacích skriptů ve zvleném nástrji pr pdpru autmatizvaných testů. Nástrj prvede testy a vygeneruje Výsledky testů Vyhdncení testů Klíčvými vstupy tht prcesu jsu Výsledky testů, aktualizvaný testvací plán a databáze chyb. Především na základě těcht vstupů jsu vytvářeny pravidelné reprty pstupu testvání a kvalitě testvané aplikace. 29

30 Obr. 14 Vyhdncení testů Vyhdncení testů Výsledky testů Aktualizvaný Plán testů Vytváření reprtů Výsledky testů Databáze chyb Pstup testvání Chybvst Vytváření reprtů Test krdinátr připravuje v pravidelných intervalech reprty, které jsu zaměřeny na: pstup testvání, kde prvnává plán vs. skutečnst a vyhdncení, zda byly realizvány všechny naplánvané testy či které testy nebyly v rzpru s plánem realizvány; kvalitu testvané aplikace, knkrétně typy zjištěných chyb, kategrie, stav řešení, trendy. Pdklady pr reprty získá Test krdinátr na základě předdefinvaných dtazů ve využívaných nástrjích na pdpru testvání Správa chyb Jedním z účelů testvání je dstranit chyby, které vznikly v průběhu vývje. Během testvání je zpravidla vyhdncena řada chyb. Chybu rzumíme nečekávané chvání aplikace či je tt chvání dknce v rzpru s pžadavky klienta. Aby byl ze strany zadavatele mžné funkčnst akceptvat, je třeba bjevené chyby pravit a vytvřit nvu verzi systému, která je již nebsahuje. Chyby jsu nejvíce nacházeny a řešeny v bdbí, kdy prbíhá prces Prvedení testů. Nalezené chyby jsu pak zaznamenány d databáze chyb (d bug trackingvéh nástrje), kde je sledván jejich průběh prav. Obr. 15 Správa chyb Správa chyb Výsledky testů Zaznamenání chyb Databáze chyb Sledvání zaznamenaných chyb 30

31 Zaznamenání chyb Způsb zadání chyby závisí na tm, kd realizuje testy a na základě jakých pdkladů. Manuální testy V případě, že jsu testy realizvány manuálně Testerem (na základě Testvacích scénářů), jsu chyby zaznamenány přím testujícím d databáze chyb, které jsu pak řešeny v suladu s definvaným živtním cyklem. Autmatizvané testy U autmatizvaných testů jsu testy spuštěny Test analytikem, který vytvářel příslušné skripty. Test analytik na základě Výsledků testů prvním krku vyhdntí, zda se skutečně jedná chybu testvané aplikace či např. chybu ve skriptu, pak zadá zjištěnu chybu standardním způsbem d databáze chyb Sledvání zaznamenaných chyb Sučástí prcesu správy chyb je sledvání pstupu řešení zaznamenaných chyb. Stav řešení chyby je sučástí databáze, kteru Test krdinátr sleduje, vyhdncuje a na základě získaných infrmací prvádí aktualizaci Plánu testů. Pr efektivní řešení chyb je třeba je průběžně sledvat, v jakém stavu se nacházejí, jaké je jejich mnžství atd. Za sledvání chyb je zdpvědný Test krdinátr, který musí udržvat neustálý přehled chybách. Sleduje tedy: nvé chyby, Sleduje je v určitém časvém intervalu (denně, týdně,...). chyby dle stavů, Klik chyb se nachází v jakém stavu (např. klik chyb je praven, klik chyb je v řešení,...). trendy v řešení chyb. Sleduje pměr nvě vzniklých chyb k uzavřeným chybám. Z tht pměru může dvdit, zda je vývjvý tým schpen chyby včas zapracvat. Test krdinátr na základě zjištěných infrmací případně aktualizuje Plán testů neb pdniká krky směřující k minimalizaci neb dstranění dpadu chyb na testvání v rámci release Řízení testů Právě v blasti řízení testů se dehrává krdinace dílčích aktivit a průběžné sledvání a vyhdncvání prcesu testvání. Celý prces Řízení testů spadá d kmpetence Test krdinátra a představují hlavní výknnu slžku jeh práce. 31

32 V úvdních fázích testvání prběhne rvněž kmpletace testvacíh plánu, tj. je dknčena specifikace testů a kmpletace akceptačních kritérií. S definitivní platnstí se rzhdne, jaké typy testů budu realizvány, v jakých klech, průběžně jsu detailizvány harmngramy jedntlivých testů a jsu jednznačně určena akceptační kritéria. V návaznsti na pstup a výsledky testvání prbíhá aktualizace a detailizace plánu testů. Na knci akceptace vzniká Akceptační prtkl, který je pdepisván klientem. Akceptační prtkl je seznam akceptačních kritérií, kde klient svým pdpisem stvrzuje, že byly všechny kritéria pr předání splněna a přebírá řešení d ddavatele řešení. Obr. 16 Řízení testů Řízení testů Plán testů Krdinace aktivit a mnitrvání testů Aktualizvaný Plán testů Kmpletace specifikace testů Výsledky testů Kmpletace Akceptačních kritérií Řízení akceptace Akceptační prtkl Pstup testvání Chybvst Krdinace aktivit a mnitrvání testů Test krdinátr prvádí průběžné mnitrvání prbíhajících činnstí (např. na základě reprtů testvání, eskalvaných prblémů apd.) a s využitím získaných infrmací prvádí řízení činnstí při testvání a řešení případných prblémů a rizik Kmpletace specifikace testů Test krdinátr upraví specifikaci testů v Plánu testů. T znamená, že zapracuje případné změny, které se týkají typů realizvaných testů, jejich stádií, rganizací testů v sestavách, míry frmalizace pdkladů pr testvání apd., jak již byl ppsán v aktivitě Specifikace testů. Měl by se jednat průběžné finální úpravy. 32

33 Kmpletace akceptačních kritérií V případě ptřeby, na základě zpdrbňujících infrmací Test krdinátr dplní či upřesní akceptační kritéria, která byla specifikvána v Plánu testů během aktivity Definice akceptačních kritérií. Tat kritéria je třeba dsuhlasit ze strany klienta, aby mhly služit jak pdmínka akceptace. Definice akceptačních kritérií musí být dknčena před zahájením realizace testů Řízení akceptace Řízení akceptace není jednrázvu akcí na knci prcesu testvání, ale je dluhdbější aktivitu. Je pstavena na akceptačních kritérií před realizací testů a prbíhá již d úvdních jednání s klientem, hledně plánvání a realizace akceptace. Řízení akceptace zahrnuje řadu činnstí, které směřují k bezprblémvé kmunikaci mezi zadavatelem, který pžaduje funkcinalitu v knkrétní kvalitě, a ddavatelem řešení, který na základě definvaných kritérií bhajuje ddržení pžadavků klienta. Za řízení akceptace je zdpvědný Test krdinátr, který především musí: určit způsb splupráce mezi pracvníky IT a klientem; vyjasnit, jakým způsbem budu připraveny pdklady pr akceptační testy; dhdnut případné využití existujících pdkladů pr testvání; sledvat a vyhdncvat výsledky akceptačních testů; řešit případná rizika a suvisející prblémy během akceptačních testů; zajistit frmální schválení akceptace prstřednictvím akceptačníh prtklu Organizační struktura V tét kapitle charakterizuji jedntlivé rle z prcesu testvání, kde specifikuji jejich pžadvané vlastnsti a aktivity, za které jsu zdpvědné. Tyt rle pak zařadím d stávající rganizační struktury k jedntlivým zaměstnancům Analytik Analytik je v rámci testvání kmpetentní za realizaci činnstí, pr které je nezbytná jeh znalst příslušnéh systému p funkční a business stránce. Analytik je kmpetentní: za vytvření vybraných pdkladů pr testvání, dhadnutí nárčnsti testvání před zařazením pžadavku d release zkmpletvání Analýzy pžadavků vytvření Testvacích pžadavků 33

34 za pskytnutí zpětné vazby pr Test krdinátra, za kmunikaci s Test analytikem při zpracvávání Testvacích scénářů či skriptů (věření správnsti). Předpkladem pr efektivní práci Analytika je: vynikající znalst funkční stránky příslušnéh systému, výbrná rientace v řešení business prblematice, manažerský phled na řešení zadané změny, rganizační a kmunikační schpnsti, znalst v blasti vytváření Testvacích pžadavků. Obr. 17 Kmpetence analytika Analytik Analýza pžadavků Testvací sestava Testvací pžadavky Realizvané aktivity Obr. 18 Realizvané aktivity Plánvání testů Odhad Stanvení akceptačních nárčnsti testů kritérií Prvedení testů Příprava Vytváření testvacích analýzy pžadavků pžadavků Vytváření testvacích sestav Test krdinátr Test krdinátr představuje řídící rli v blasti testvání. Jeh hlavní pracvní náplň zahrnuje realizaci manažerských činnstí: 34

35 řízení a krdinace činnsti suvisející s přípravu a realizací testů, sledvání a mnitrvání stavu testvání, průběžné mnitrvání pstupu testvání a jeh vyhdncení prti stanvenému plánu, definice a sledvání klíčvých metrik (termíny, ptřeba zdrjů,...), příprava reprtů stavu testvání, řešení a eskalace prblémů či rizik během testů. Test krdinátr je rvněž zdpvědný za naplánvání testů: Na základě klíčvých milníků realizace změny plánuje harmngram testvání. Odhaduje nárčnst realizace dílčích činnstí během testvání. Na základě kmunikace s kmpetentními pracvníky rganizuje testvání pžadavků prstřednictvím testvacích sad. Stanví nezbytnu míru frmalizace pdkladů pr testy. Specifikuje kla testů. Určuje nezbytné typy testů, které je třeba realizvat. Test krdinátr během řízení akceptace kmunikuje s klientem s cílem zajistit, aby akceptace prběhla v termínech. V suvislsti s akceptací musí ve splupráci se zadavateli vymezit především: rganizace akceptačníh prcesu, způsb přípravy realizace akceptačních testů, harmngram akceptace, frmální dkumentaci akceptace. Pžadvané znalsti: dbré znalsti blasti testvání sftwaru, manažerské dvednsti nezbytné pr řízení a krdinaci aktivit, znalst testvacích nástrjů pr pdpru autmatizvanéh testvání (principy jejich pužívání a způsb jejich práce), manažerská praxe v blasti testvání (plánvání a rganizace testů). 35

36 Obr. 19 Kmpetence Test krdinátra Test Krdinátr Plán testů Testvací prstředí Záznam chyby Test reprt Akceptační prtkl Obr. 20 Realizvané aktivity Realizvané aktivity Plánvání testů Příprava testů Naplánvání testů Specifikace testů Identifikace pžadavků na testvací prstředí Vyhdncení testů Správa chyb Vytvření reprtů Sledvání zaznamenaných chyb Řízení testů Krdinace aktivit a mnitrvání testů Kmpletace Kmpletace akceptačních specifikace testů kritérií Řízení akceptace Test analytik Test analytik je rle, která je v blasti testvání spjena s využitím nástrjů pr pdpru autmatizvanéh testvání a testvání pdle scénáře. Test analytik je kmpetentní: za rzpracvání pdkladů pr manuální testvání d takvé úrvně detailu, aby mhli systém bez prblémů testvat testeři, kteří nedispnují detailní znalstí systému; Je vhdné, když Test analytik puze testvací scénáře vytváří a ne je přím prvádí, je t kntraprduktivní. Když Test analytik testuje pdle vlastních scénářů, tak nabývá djem, že všechny testvací krky zná a nemusí se tedy pdle scénáře řídit. Tím vzniká rizik přehlédnutí chyby v aplikaci. 36

37 za základní správu nástrje pr autmatizvané testvání: za úkny nezbytné pr přípravu testů v nástrji, za vytváření struktury testů. za vytváření pdkladů pr autmatizvané tetvání v pdbě Testvacích skriptů; za ladění a úpravy Testvacích skriptů; definice Testvacích sestav; kmunikaci s Analytikem při specifikaci cíle testvacích scénářů či skriptů a věření jejich věcné správnsti; identifikace testů (testvacích scénářů) vhdných pr autmatizaci; za vytvření a spuštění autmatizvaných testů. Pžadvané znalsti: výbrnu znalst zvlenéh nástrje pr pdpru autmatizvanéh testvání, z phledu správy nástrje a jeh uživatelské úpravy, z phledu jeh funkčnsti, struktury záznamů, nastavení a praktickéh využití, znalsti suvisejících sftwarvých nástrjů, znalst skriptvacíh jazyka pr případné úpravy autmaticky genervaných skriptů, znalst blasti testvání, především pdby standardizvaných dkumentů, tzn. Testvací scénáře, Testvací skripty a jejich bsahu, znalst klíčvých metdik testvání. Obr. 21 Kmpetence Test analytika Test Analytik Testvací scénář Testvací skript Testvací sestava Záznam chyby Výsledky testů 37

38 Obr. 22 Realizvané aktivity Realizvané aktivity Příprava testů Vytváření testvacích scénářů/skriptů Vytváření testvacích sestav Prvedení testů Spuštění/prvedení testů Správa chyb Zaznamenání chyby Tester Tester je rle, která je kmpetentní za samstatnu realizaci manuálních testů pdle detailních testvacích scénářů, následný záznam chyb a restvání pravených chyb. Znalsti pžadvané na tét rli jsu základní znalsti testvané aplikace a její účel pužívání klientem. Obr. 23 Kmpetence Testera Tester Výsledky testů Záznam chyby Obr. 24 Realizvané aktivity Realizvané aktivity Prvedení testů Spuštění/prvedení testů Zaznamenání chyby 38

39 Zařazení rlí d rganizační struktury splečnsti Jak jsem již v kapitle Prjekt Dcházka a výkny zmiňvala, tak na prjektu pracují: 1 veducí prjektu / analytik, 2 vývjáři, 2 testeři, z nich jeden na plviční úvazek. V tét kapitle zařadím d rganizační struktury rle na prjektu. Na tent prjekt bych navrhvala přijmut jednh zaměstnance, který by zastával rli Analytika na prjektu. Tmut nvéh zaměstnanci by veducí prjektu pstupně předával své knw-hw a pvinnsti analytika. Tent nvý zaměstnanec by vyknával puze rli Analytika. Další zaměstnanec, který pracuje jak tester na plný úvazek by vyknával rli Test krdinátra a Test analytika. Musel by prjít něklika škleními na testvání. Tent zaměstnanec by byl kmpetentní především za řízení prcesu testvání, psaní testvacích manuálních a autmatizvaných testů. Zaměstnanec na plviční úvazek by měl rli testera, který testval aplikaci pdle testvacích scénářů napsaných Test analytikem, řídil se pkyny Test krdinátra a zaznamenával nalezené chyby. Obr. 25 Organizační struktura prjektu Veducí prjektu Nvý zaměstnanec na prjektu Test Krdinátr Analytik Test Designér Tester 10.3 Autmatizvané testvání Některé funkčnsti, které se nemění, se musí testvat vícekrát, aby se věřil, že chyby z předcházejících testů byly skutečně praveny a nebjevili se nvé. Tmut pakvanému prcesu testvání se říká regresní testvání. Tt testvání může prvádět manuálně tester pdle 39

40 testvacíh scénáře. Opakvání regresníh testvání určité funkčnsti může být vzhledem k harmngramu nemžné neb pr testera dst jedntvárná činnst, kde vzniká rizik přehlédnutí chyby. Eliminvání tht rizika je výběr vhdnéh nástrje na autmatizaci testů aplikace. Autmatizvaný test se skládá z jedntlivých testvacích skriptů. Testvací skript je sada krků a bdů věření veducí k prvedení testů pmcí SW aplikace. Princip autmatickéh testvání spčívá v zaznamenání neb vyvlání pžadvané činnsti v testvané aplikaci pmcí určitéh nástrje tj. jiné SW aplikace pr autmatické testvání sftwaru a následné přehrání a vyhdncení tét činnsti. Lidský zásah je nutný puze v pčáteční fázi záznamu a tvrby autmatickéh testu a případně při jeh vyhdncení. Samtný test prbíhá autmaticky. Mezi výhdy patří nízké náklady na samtný prvz, prtže veškeru činnst bstarává samtný nástrj bez nutnsti lidskéh zásahu. Absence lidskéh faktru v prcesu testvání také eliminuje případné chyby a myly, které vznikají díky lidské nepzrnsti. I přes zjevné výhdy se autmatické testvání ptýká s mnha překážkami. Největší z nich jsu vyské pčáteční náklady, časvá a rganizační nárčnst celéh řešení a ptřeba kvalifikvaných lidských zdrjů. 2 Výhdy manuálníh testvání: Na manuální testvání není ptřeba specializvané pracvníky, stačí základní znalst aplikace jak má tester. Na vytvření testvacíh scénáře nejsu třeba žádné přizvací náklady. Test analytik tyt scénáře vytváří například d textvéh neb tabulkvéh dkumentu. Testvací scénáře se snadn pužívají (všechny krky jsu detailně ppsány). Nevýhdy manuálníh testvání: Když se testvání funkčnsti pakuje vícekrát, tak je t časvě nárčné a je rizik, že se nestihnu všechny naplánvané testy. Pkud tester prvádí testvání vícekrát, tak ztrácí pzrnst a pdléhá djmu, že scénář zná, tím vzniká rizik přehlédnutí chyby, která by mhla hrzit akceptaci releasu klientem. Během pakvanéh testvání určité funkčnsti se Tester nemůže věnvat jiným testům, které mu Test krdinátr naplánval. Výhdy autmatizvanéh testvání: Testvání pmcí autmatizvanéh nástrje je mnh násbně rychlejší než pakvané prvádění manuálníh testvání testerem. P spuštění autmatizvaných testů se může Test analytik věnvat další práci, tj. práce je mnhem efektivnější. 2 BLAŽOVÁ, Rmana. TST Autmatické testy : Přednáška pr předmět Testvání sftware [nline]. s. 1 < 40

41 Autmatizvaný test se může spustit mnhkrát a vždy test prběhne přesně, správně a za stejný časvý úsek. Nevýhdy manuálníh testvání: Na trhu je spusty nástrjů pr autmatizvané testvání, prt přízení takvé nástrje může mít vyské přizvací náklady. Na pužívání tht nástrje je ptřeba zkušené pracvníky, kteří budu umět pracvat s tímt nástrjem a v případě ptřeba dprgramvat část skriptu. Vytváření autmatizvaných testů je časvě nárčné, prt se autmatizvaně testují jen funkčnsti, které se nemění, jinak by práce byla neefektivní.l Autmatizvané testvání nemůže nahradit lidské k a intuici. Autmatizvaný test testuje puze t, c má naprgramván. Pmcí autmatizvaných testů nelze testvat uživatelské rzhraní Testvací nástrje pr autmatizvané testvání HP QuickTest Prfessinal je nástrj pr autmatizvané testvání funkčnsti aplikací, především prstřednictvím uživatelskéh rzhraní. Vlastnsti prduktu: Simuluje práci skutečnéh uživatele, zaznamenává chvání aplikace a sleduje, zda se shduje s čekávaným chváním. Při nahrávání testvacíh skriptu je prváděna tatáž činnst jak u skutečnéh uživatele. Zaznamenává uživatelské činnsti d skriptu pmcí VBScriptu. V místech, kde má QuickTest prvést určitu kntrlu, vkládáme d skriptu kntrlní bdy. Kntrlní bd bsahuje předpis kntrly a čekávané hdnty. Očekávanu hdntu mhu být zbrazená data, vlastnsti nějakéh bjektu či výsledek SQL dtazu. P spuštění testvacíh skriptu djde k prvnání a vyhdncení hdnt čekávaných a skutečných. QuickTest vše zaznamená d pdrbných, graficky zpracvaných, výstupních zpráv. 3 CubicTest CubicTest je nástrj pr autmatizvané testvání zalžený na grafickém editru. Tent nástrj lze využít prakticky pr všechny webvé aplikace, kde pdpruje většinu uživatelských interakcí. 3 KOMIX, s. r.. - HP QuickTest Prfessinal [nline]. < 41

42 Vlastnsti prduktu: Pdbně jak HP QuickTest simuluje skutečnéh uživatele, v pdstatě přím nahrává uživatelv klikání d webvé aplikace. Testvací skript lze také sestavit pmcí grafickéh editru, kam se přidávají jedntlivé prvky stránky, na které se pak navazují uživatelské interakce. CubicTest je t Open Surce grafický mdul Eclipsu (vývjvé platfrmy určené pr prgramvání v jazyce Java). Tent nástrj lze spuštět v různých prhlížečích. Jak výchzí prhlížeč pr editaci a spuštění testů je Firefx neb Opera. P nainstalvání watir plug-in lze testy spuštět i prhlížeči Internet Explrer. Pr prjekt Dcházka a výkny bych dpručila nástrj CubicTest, prtže se snadn vládá přes grafický editr neb jen nahrává kliky uživatele. Tent nástrj je pen surce, takže by nebyly žádné náklady na přízení Testvací scénáře Testvací scénáře jsu skupina p sbě lgicky následujících krků a věřvacích akcí, které mají za cíl testvat vybranu funkčnst aplikace, např. přihlášení d aplikace: 1. zadání uživatelskéh jména 2. zadání hesla 3. ptvrzení zadaných přihlašvacích údajů 4. načtení aplikace Jedntlivé testvací případy ve scénáři mhu na sebe navazvat a tím pádem je nutné je vyknávat v hierarchicky neb na přadí testvání jedntlivých případů nezáleží. Testvací scénář může mít stejnu strukturu jak analýza pžadavků. Testvací scénář má nejčastěji pdbu dkumentu, který je tvřen v tabulkvém editru. Způsby testvání: manuální testy - testy realizvané manuálně pdle testvacíh scénáře autmatizvané - testy realizvané s využitím autmatizvanéh nástrje na pdpru testvání regresní testy - testy zaměřené na testvání celéh systému, tzn. včetně již testvaných funkčnstí Typy realizvaných testů: Funkční testy - testy jsuzaměřené na věření správnsti funkcí aplikace, tj. zda dpvídá analýze, 42