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

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

Kateřina Urbanová

Unicorn College © 2010 Unicorn College, V Kapslovně 2767/2, Praha 3, 130 00 Název práce v ČJ: Název práce v AJ:

Redesign procesu testů a test management Redesign of test and test management process

Autor:

Kateřina Urbanová

Akademický rok:

2009/2010

Kontakt:

Email: [email protected] Tel: (+420) 777 158 508

2

1. Zadání

3

2. Abstrakt Budu psát o fiktivní společnosti na základě mých zkušeností ze současného a minulého zaměstnání. Tato společnost má problémy s kvalitou produktu, které jsou způsobeny zejména nedostatečně rozvinutým procesem testování a test managementu. SW produkt této společnosti je docházkový systém, který dodává vstupy pro výpočet mezd. Cílem práce bude navrhnout řešení na zefektivnění testovacích procesů, eliminovat rizika spojená s nedostatečným testováním a tím zvýšit kvalitu výsledného produktu. Navrhnu metodiku testování přímo na tento specifický projekt. Klíčová slova: Testování, metodika, testovací scénáře, automatizované testy, analytik, vedoucí projektu, tester, vývojář

4

3. Abstract I will write about a fictitious company based on my experience of current and past employment. This company has problems with product quality, which are mainly due to an underdeveloped testing process and test management. Software product that the company is an attendance system that provides inputs for the calculation of wages. The aim of the work will propose solutions to streamline the testing process, eliminating the risks associated with inadequate testing and thereby increase the quality of final product. I will propose a methodology for testing directly on this specific project. Keywords: Testing, methodology, test scenarios, automated tests, Analyst, Project team leader, Tester, Developer

5

4. Prohlášení Prohlašuji, že svou bakalářskou práci na téma Redesign procesu testů a test management jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a odborným konzultantem, s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne 07.05. 2010

…….………………. Kateřina Urbanová

6

5. Poděkování Děkuji vedoucímu bakalářské práce Petru Hájkovi PhD za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

7

6. Obsah 1. Zadání ..................................................................................................................................................3 2. Abstrakt ................................................................................................................................................4 3. Abstract ................................................................................................................................................5 4. Prohlášení ............................................................................................................................................6 5. Poděkování...........................................................................................................................................7 6. Obsah ...................................................................................................................................................8 7. Úvod ...................................................................................................................................................10 8. O společnosti......................................................................................................................................11 8.1 IT oddělení ...................................................................................................................................11 8.1.1 Projekt Docházka a výkony ..................................................................................................14 8.1.1.1 Proces rozvoje...............................................................................................................15 9. Identifikace problémů IT oddělení společnosti ...................................................................................20 10. Návrh hřešení – metodika testování ................................................................................................22 10.1 Proces testování ........................................................................................................................22 10.1.1 Plánování testů ...................................................................................................................23 10.1.1.1 Odhad náročnosti testování ........................................................................................24 10.1.1.2 Naplánování testů .......................................................................................................25 10.1.1.3 Specifikace testů .........................................................................................................25 10.1.1.4 Stanovení akceptačních kritérií ...................................................................................25 10.1.2 Příprava testů .....................................................................................................................26 10.1.2.1 Příprava analýzy požadavků pro testování ................................................................27 10.1.2.2 Vytváření testovacích požadavků ...............................................................................27 10.1.2.3 Vytváření testovacích scénářů/skriptů ........................................................................27 10.1.2.4 Vytváření testovacích sestav ......................................................................................27 10.1.2.5 Příprava testovacích dat .............................................................................................28 10.1.2.6 Identifikace požadavků na testovací prostředí............................................................28 10.1.3 Provedení testů...................................................................................................................28 10.1.3.1 Provedení/spuštění testů ............................................................................................29 10.1.4 Vyhodnocení testů ..............................................................................................................29 10.1.4.1 Vytváření reportů.........................................................................................................30 10.1.5 Správa chyb........................................................................................................................30 10.1.5.1 Zaznamenání chyb......................................................................................................31 10.1.5.2 Sledování zaznamenaných chyb ................................................................................31 10.1.6 Řízení testů.........................................................................................................................31 10.1.6.1 Koordinace aktivit a monitorování testů ......................................................................32 10.1.6.2 Kompletace specifikace testů......................................................................................32 10.1.6.3 Kompletace akceptačních kritérií ................................................................................33 10.1.6.4 Řízení akceptace.........................................................................................................33

8

10.2 Organizační struktura.................................................................................................................33 10.2.1 Analytik ...........................................................................................................................33 10.2.2 Test koordinátor..................................................................................................................34 10.2.3 Test analytik........................................................................................................................36 10.2.4 Tester..................................................................................................................................38 10.2.5 Zařazení rolí do organizační struktury společnosti.............................................................39 10.3 Automatizované testování..........................................................................................................39 10.3.1 Testovací nástroje pro automatizované testování..............................................................41 10.4 Testovací scénáře......................................................................................................................42 11. Závěr ................................................................................................................................................44 12. Conclusion........................................................................................................................................46 13. Seznam použité literatury.................................................................................................................48 14. Seznam obrázků ..............................................................................................................................49

9

7. Úvod Tato bakalářská práce je zaměřena na návrh řešení a zefektivnění testovacích procesů fiktivní společnosti. Tato fiktivní společnost bude sloužit jako modelový příklad společnosti se špatnou kvalitou výstupů. V některých oblastech jsem se inspirovala společností, ve které momentálně pracuji. Především se v této fiktivní společnosti zaměřím na jeden konkrétní projekt – Docházka a výkony. V kapitole O společnosti přiblížím fiktivní společnost, její procesy, organizační strukturu, kde se detailněji zaměřím na projekt Docházka a výkony. V další kapitole Identifikace problémů IT oddělení popíši výhody a nevýhody procesů projektu, konkrétně se zaměřím na vedení projektu, analýzu, vývoj a testy. V kapitole Návrh řešení – metodika testování redesignuji pouze testovací procesy. Tento návrh není myšlen jako všeobecná metodika testování, ale snažila jsem se tuto metodiku navrhnout přímo pro tento specifický projekt fiktivní společnosti. Při vytváření návrhu řešení jsem vycházela z metodiky Rational Unified Process společnosti IBM Rational Software Corporation. V práci se zaměřím i na možnost využití nástrojů pro automatizované testování.

10

8. O společnosti Společnost XYZ spol. s r.o. vznikla v roce 1991. Má 7 poboček po celé České republice se sídlem v Praze. V pražské centrále je přímo majitel společnosti, který vydává nařízení pro pobočky v Čechách a Evropě. Centrála zajišťuje obchod, outsourcing, vývoj, servis a zákaznickou podporu. Pobočky v Čechách a v evropských zemích zajišťují pouze outsourcing a obchod. Původně se společnost zaměřovala na vývoj a implementaci mzdového a HR softwaru s českou a slovenskou legislativou, po té rozšířila svou působnost i na poskytování mzdového outsourcingu, který poskytuje i v několika evropských zemích: Bulharsko, Maďarsko, Polsko, Rakousko, Rumunsko, Rusko, Slovensko a Ukrajina. Obr. 1 Organizační struktura sídla v Praze

Maijtel / Jednatel

Provozní asistentka

Ředitel společnosti

Personální oddělení

Technické Oddělení zákaznické oddělení podpory

Helpdesk

Oddělení outsourcingu

Obchodní oddělení

IT oddělení

Mzdový outsourcing, který poskytuje společnost XYZ, je služba, kdy společnost převezme agendu výpočtu mezd, včetně povinností s tím spojených a odpovědnosti za vypočítaná data za klienta. Klient pouze dodává podklady potřebné pro výpočet mezd (docházka zaměstnanců, dovolené, neschopenky). Službu mzdový outsourcing provozuje na vlastním softwaru, který vyvíjí a implementuje u klientů.

8.1 IT oddělení IT oddělení vyvíjí systém pro řízení lidských zdrojů, který podporuje především mzdové a personální procesy. Jedná se především o rozvoj softwaru. Tento systém se konkrétně skládá ze základního a nástavbového modulu:

11

1. Základní moduly: •

Systémový modul o

Typickým uživatelem tohoto modulu je administrátor aplikace,

o

definuje uživatele a vytváří uživatelská připojení k aplikaci a databázi; konfiguraci přístupových práv uživatelů k jednotlivým objektům systému a konfiguraci parametrů systému.

•

Analýza práce o

S tímto modulem pracuje organizační nebo personální útvar,

o

evidence základních údajů o druzích práce, funkcích a činnostech; definice dalších údajů - lékařské vyšetření stanovené předpisy, odborná přezkoušení a jejich periodicita, odpovědnosti, pravomoci; analýza práce pomocí analytické bodovací metody ILO.

•

Pracovní místa o

S tímto modulem pracuje organizační nebo personální útvar,

o

evidence organizační struktury společnosti včetně její verzování; evidence pracovních míst včetně tarifního zařazení; vymezení konkrétních nároků na pracovní způsobilost a sociální kompetence zaměstnance na daném pracovním místě (upřesnění požadavků vyplývajících z funkce, přiřazené danému pracovnímu místu); průřezové sledování obsazení pracovního místa; sledování limitů přesčasové práce, definici okruhů otázek pro hodnocení zaměstnance; evidenci vztahů mezi pracovními místy.

•

Personální evidence o

S tímto modulem pracuje organizační nebo personální útvar,

o

evidence osobních a jiných údajů o zaměstnanci; včetně údajů o jeho rodinných příslušnících; adresách, předchozích zaměstnavatelích, praxi, pobíraných důchodech, změněné pracovní schopnosti apod.; sepsání pracovní smlouvy; mzdového výměru, ukončení právního vztahu, sledování průběhu zaměstnání v organizaci; sledování nároků a čerpání dovolené; evidenci přihlášení ke zdravotní pojišťovně.

•

Mzdy a platy o

S tímto modulem pracuje mzdový nebo personální útvar,

o

Zadávání podkladů pro výpočet mezd a výpočet mzdy; navázání na sdružené personální moduly, práci s údaji, které sdílí s personální evidencí; práci s kalendáři; práci s vlastními složkami mezd (definovanými uživatelem); čerpání dat z docházky, výkonů resp. jinak zadaných mzdových údajů.

12

2. Nadstavbové moduly: •

Docházka a výkony o

S tímto modulem pracují linioví manažeři na nejnižším stupni organizační struktury, personální útvar a mzdová účtárna,

o

umožňuje ze sledování docházky a výkonů, připravovat vstupy do modulu mezd a platů pro výpočet mezd a platů a pro rozborovou činnost; měsíční sledování docházky a výkonů, které shrnuje data za jednotlivé dny měsíce; kontrolu podkladů pro zúčtování mezd, volitelně naplňovat data přímo v měsíční docházce, nebo z automatizovaného sledování (například formou magnetických karet); přerozdělování odměn; automatické generování složek mezd podle výkonů (příplatky za směnnost, prostředí. Obr. 2 Využití modulů aplikace

Organizační útvar

Personální útvar

Mzdový útvar

Linioví manažeři

Administrátor

Analýza práce

Systémový modul

Pracovní místa

Personální evidence

Mzdy a platy

Docházka a výkony

Oddělení vede ředitel, který koordinuje 3 projekty: projekt Mzdy a Personální evidence, projekt Docházka a výkony. Jednotlivé projekty řídí vedoucí, kteří jsou zároveň hlavní analytici. Každý projekt má k dispozici 2 - 3 vývojáře a 2 - 3 testery. Většina testerů jsou bývalé mzdové účetní.

13

Obr. 3 Projekty společnosti

IT oddělení

Projekt Mzdy

Projekt Personální evidence

Projekt docházka a výkony

Obr.4 Personální složení projektu

Vedoucí a analytik

Vývojáři

Testeři

8.1.1 Projekt Docházka a výkony Projekt docházka a výkony rozvíjí nástavbový modul podle požadavků klienta, řeší změnové a chybové požadavky. Modul docházky se skládá ze systémového modulu, tlustého a tenkého klienta. Systémový modul je určen pro konfiguraci a pracuje na bázi lokální aplikace, viz kapitola 8.1

IT oddělení. Tlustý klient je lokální aplikace s konektivitou na server, kde se upravují

číselníky aplikace, vytváří struktura společnosti, otvírají / zavírají jednotlivá období a řídí samotná docházka zaměstnanců. Systémový modul a tlustý klient docházky používá na databázi Oracle. Tyto aplikace jsou vyvíjeny na platformě PowerBuilder. Tenký klient představuje aplikaci na bázi webového rozhraní, kde se pouze řídí docházka zaměstnanců. Serverová část tenkého klienta je vyvíjena v objektovém programovacím jazyku Java. Co se týče personálního obsazení, tak projekt řídí vedoucí projektu, který je zároveň hlavní a jediný analytik, 2 vývojáři, 2 testeři, z toho jeden na poloviční úvazek. Vedoucí projektu má za úkol koordinovat a řídit veškeré aktivity, které se odehrávají v rámci release či projektu. Má na starosti IT analýzu, business analýzu. Také prioritizuje příchozí požadavky a provádí analýzu jejich dopadu. Vedoucí se částečně podílí i na rozvoji tlustého klienta a spravuje databázi projektu. Podřízení vývojáři rozvíjí především tenkého klienta, nasazují nové verze a patche. Testeři ověřují správnost fungování implementované funkcionality, tedy zda odpovídá zadaným požadavkům.

14

8.1.1.1 Proces rozvoje Po dlouholeté zkušenosti s vývojem softwaru a podle charakteru projektu se společnost víceméně přiblížila k modelu „Programuj a opravuj“. Tento model zpravidla používají projektové týmy, který se nikterak nesnaží o žádný jiný model. „Tým, který se drží tohoto postupu, začíná obvykle hrubou představou výsledného produktu, udělá si nějaký jednoduchý návrh a poté vstoupí do dlouhého, neustále se opakujícího cyklu kódování (programování), testování a opravování chyb.“

1

U toho to modelu je zpravidla neformální plánování a analýza požadavků, takže projektový tým vykazuje okamžité výsledky. Tester prakticky každý den testuje novou nebo aktualizovanou verzi softwaru, kterou musí otestovat. Provede všechny potřebné testy a okamžitě zaznamená chyby.

1

Obr. 5 Model „Programuj a opravuj“ „Programuj a opravuj“

Neformální analýza požadavků

Programování

Výsledný produkt

Opravování

Proces rozvoje začíná správou požadavků. Požadavky představují nahlášené změny zadání a zjištěné chyby klientem, které posílá formou emailu na Helpdesk. Ten pak zajišťuje jejich evidenci a písemnou komunikaci s klientem. Z přijatých požadavků se vytvoří zadání pro release, tj. vyberou se požadavky, které se budou v daném patchi nebo verzi řešit a následně nasazovat u klienta. Pak proběhne vývoj podle zadání a jeho průběžné testování. Po dokončení všech testů se release nasazuje u klienta. Patch se vydává pravidelně každý měsíc nebo i častěji v závislosti na závažnosti nalezených chyb v dané aplikaci. Verze se vydává 2x do roka a tvoří ji všechny vydané patche od poslední vydané verze.

1

PATTON, Ron. Testování softwaru. s. 28

15

Obr. 6 Proces rozvoje Proces rozvoje

Řízení projektu

Správa požadavků

Analýza zadání

Vývoj

Testování

Nasazení

Jako nástroj pro sledování a správu chyb (neboli bug-trackingový nástroj) se na projektu Docházka a výkony používá aplikace, která byla společností vyvinuta pro tyto účely. Pracuje na principu nastavení stavu řešení chyby jako u běžných bug-trackingových nástrojů. Na každý požadavek od klienta se v této aplikaci založí tzv. „záznam“ o chybě nebo změně zadání. Záznamy jsou vždy provázány s konkrétním požadavkem od klienta. Vedoucí projektu / analytik zodpovídá za jejich provázanost. Tento bug-trackingový nástroj slouží jako hlavní komunikační prostředek mezi vývojáři a testery. Na tomto projektu se používá těchto 8 stavů, které jsou v aplikaci rozlišeny barvami pro lepší orientaci: 1. Vytvořený o

Záznam o chybě vytváří buď analytik na základě změnových požadavků nebo tester na základě nalezené chyby při testování aplikace.

2. Přiřazený k řešení o

Analytik pak zhodnotí závažnost chyby, popřípadě doplní základní zadání pro vývojáře a ho zařadí do příslušné verze nebo patche.

o

Ke každému záznamu přiřazuje konkrétního vývojáře i testera, kteří budou záznam řešit.

3. Řešený o

Tento stav nastavuje vývojář ve chvíli, kdy na záznamu začíná pracovat. Vedoucí projektu pak může sledovat, jaké záznamy jsou rozpracované a který vývojář jej řeší.

16

4. Vyřešený k překladu o

Vývojář nastavuje tento stav, když je záznam vyřešen a připraven k překladu na testovací databázi.

5. K testování o

Analytik tento stav nastaví po překladu záznamu na testovací databázi.

6. Vrácen k opravě o

Když požadavek, na který byl záznam vytvořen, není správně naprogramován nebo opraven, tak tester vrací tímto stavem záznam vývojáři s popisem chování, který znovu musí tento záznam vyřešit.

7. Uzavřený o

Když tester ověří správné chování požadavku, tak záznam se uzavírá.

o

Analytik tento záznam průběžně zařadí komentářů k verzi pro klienta.

8. Odložený o

Když vedení projektu rozhodne, že záznam se bude řešit v jednom z dalších patchů a zatím není zařazen do nějakého konkrétního patche.

Obr. 7a Stavy záznamu chronologicky rozdělené podle rolí

Analytik

Vytvořený Připraven k řešení

Vývojář

Řešený

Vyřešený

Tester

Vytvořený

Vrácen k opravě

17

K testování

Uzavřený

Odložený

Obr. 7b Stavy záznamu chronologicky

Vznik chyby

Vytvořený

Řešení odloženo

Přiřazen k řešení

Odložený Předán k řešení

Vrácen k dořešení

Záznam zamítnut

Vrácen k opravě

Řešený

Vyřešený

K testování

Uzavřený Připraveno k nasazení u klienta Oprava chyby uzavřena

Zadání změn a analýza Analytik vypracovává z přijatých požadavků zadání pro vývoj a testy. Analýza zadání však probíhá intuitivně a neformálně. Vývojář dostává zadání převážně v mluvené nebo i v písemné formě, které obsahuje základní body, jak má výstup fungovat. Určitá část zadání je tedy na iniciativě samotného vývojáře. Vývoj Rozvoj aplikací se provádí na vývojářských databázích. Při programování funkcionalit, ve formě přidělených záznamů ze zadání pro release, se průběžně provádí překlad na testovací databázi, na které postupně testeři ověřují správnost fungování aplikace a naimplementovaných funkcionalit.

18

Vývojáři po sobě testují naprogramované funkcionality jen základně na vývojářské databázi. Další testování se provádí na testovací databázi, která má podobné prostředí jako klient. Testy Testeři testují pouze přidělené záznamy spadající do určitého release, žádné další testy se na tomto projektu neprovádějí. Jedině na příkaz vedoucí projektu, například otestování konkrétní určité funkcionality aplikace. Testování funkcionality se provádí intuitivně a neformálně, tj. neprovádí se podle žádného testovacího scénáře ani se nepoužívají automatické testy. Testeři testují naimplementované funkcionality, které jsou průběžně překládány v rámci jednoho zadání pro release. Po ověření správnosti fungování dané funkcionality se uzavře příslušný záznam, tj. nastaví se do stavu „Uzavřený záznam“. Pokud funkcionalita správně nefunguje podle zadání od analytika, tak se vrací zpátky vývoji. Po otestování všech přiřazených záznamů se vydává release, který si pak zákazníci sami nasazují. Tento realese klienti získají přes speciální zabezpečenou webovou stránku, kde si příslušný release stáhnou a nainstalují ve svém prostředí. Obr. 8 Proces zadání

Klient

Zadání

Helpdesk

E-Mail

Evidence

Analytik

Požadavek

Vytvoření zadání

19

Vývojáři

Testeři

9. Identifikace problémů IT oddělení společnosti V této kapitole se pokusím identifikovat základní problémy na projektu Docházka a výkony. Problémy popíši podle činností projektu, tj. vedení projektu, analýza, vývoj a testy. Vedení projektu Základní problém lze vidět v tom, že vedoucí projektu je zároveň analytik, správce databází a také rozvíjí tlustého klienta. Je zodpovědný za příliš mnoho funkcí. Většinu informací o projektu má vedoucí projektu v hlavě a ne ve firemním systému nebo v nějaké dokumentaci či protokolech. Tímto se také stává pro společnost „nenahraditelný“ a zároveň velkým rizikem. Vedoucí projektu koordinuje a řídí lidi na projektu chaoticky, nejsou stanovena žádná pevná pravidla, podle kterých by se projekt řídil. Část zaměstnanců na projektu fluktuje, většinou po 1 roce. Nejspíš proto, že ani po roce nejsou schopni proniknout do procesů rozvoje projektu kvůli nekvalitní dokumentaci a nedostatku času vedoucího projektu. Analýza Klady: •

Analýza je zaznamenávána přímo do záznamů, které jsou delegovány do vývoje k řešení, což zrychluje proces opravení chyby nebo naprogramování změnového požadavku.

•

Analýza probíhá intuitivně a neformálně. Tento proces analýzy je rychlý a nízkonákladový. Pracovníci musí mít velmi dobrou znalost aplikace, tvoří se tím vysoce expertní tým.

Zápory: •

Analýza probíhá intuitivně a neformálně. Je problematické zaškolit nového člena do týmu. Všichni pracovníci musí vědět o aplikaci vše, nemohou být specializovaní na určitou oblast.

•

Zadání vývojářům i testerům je většinou v mluvené nebo písemné formě s popisem základních bodů identifikované chyby nebo změněné funkčnosti.

•

Projektová dokumentace není pravidelně aktualizována.

•

Projektová dokumentace obsahuje pouze popisy jednotlivých funkčností, tj. k čemu slouží, ale již ne jejich propojenost a vzájemnou závislost.

Vývoj Klady: •

Vývojáři mají velmi dobrou znalost vyvíjené aplikace.

Zápory: •

Vývojáři nepoužívají ani nevytváří programátorskou dokumentaci, která by obsahovala například jednoduché UML diagramy, kde by bylo názorně zobrazeno, jak aplikace funguje, jak mezi sebou komunikují jednotlivé objekty, jak je napojena na databázi, atd. Proto je aplikace vyvíjena nestejnorodě.

20

•

Vývoj nepoužívá žádný podpůrný Framework. Framework je softwarová struktura, která slouží jako podpora při vývoji a organizaci jiných softwarových projektů a zároveň sada daných pravidel vývoje softwaru. například připojení na databázi, vytvoření nového dialogového okna podle daných pravidel a implementačních vzorů apod.

Testy Klady: •

Testeři jsou bývalé mzdové účetní, které znají problematiku zpracování mezd, nepřítomností, příplatků a docházky.

Zápory: •

Testeři neprošli žádným školení o metodice a procesu testování, proto testování probíhá intuitivně a neformálně.

•

Plánování a příprava testů se na projektu neprovádí.

•

Nerealizuje se regresní testování a ani se nepoužívají nástroje pro automatické testování.

•

Testovací data nejsou zadávána analytikem ani test analytikem. Tester je používá podle svého uvážení a ne podle toho, jak je používá klient.

•

Testovací data na testovacích databázích nejsou nakonfigurována podle klientského prostředí.

21

10. Návrh hřešení – metodika testování V této kapitole se pokusím navrhnout metodiku testování pro projekt Docházka a výkony. Návrh řešení vychází z metodiky Rational Unified. Rational Unified Process (RUP) je metodikou vývoje softwaru, kterou vytvořila americká společnost IBM Rational Software Corporation. RUP je nabízen jako komerční produkt, který IBM Rational Software Corporation poskytuje především společnostem zabývajících se vývojem informačních systémů a softwarem obecně. Je použitelná pro jakýkoliv rozsah projektu, ale díky vysoké rozsáhlosti RUPu jsem ji přizpůsobila pro potřeby modelové společnosti XYZ.

10.1 Proces testování S oblastí testování souvisí celá řada procesů, které se prolínají celým vývojovým cyklem. V návrhu metodiky testování popíši, jakým způsobem proběhne celková příprava testů (od naplánování pro vytvoření podkladů pro testování), provedení testů, jejich vyhodnocení a jaké jsou související řídící procesy. Obr. 9 Proces testování Proces testování

Řízení testů

Plánování testů

Testování

Příprava testování

Provedení testů

Vyhodnocení testů

Správa chyb

Výchozím procesem je Plánování testů, v průběhu kterého vzniknou před schválením rozsahu release odhady náročnosti a základní specifikace testovacího procesu. Na proces Plánování navazuje Příprava testů, kde vznikají podklady pro realizaci testů a Provedení testů. Realizované

22

testy jsou průběžně vyhodnocovány, zejména s ohledem na postup testování a kvalitu testované aplikace. Všechny testovací procesy zastřešuje Řízení testů, v rámci kterého probíhá koordinace jednotlivých procesů v rámci testování a jejich sledování.

10.1.1 Plánování testů V průběhu plánování testů probíhá hrubý odhad náročnosti testů. Po zahájení release vzniká dokument Plán testů, kde je naplánována časová náročnost a zdroje, které budou na testování přiřazeny. Vzhledem k tomu, že Plán testů se vytváří souběžně se správou požadavků, tak nejsou některé informace ještě k dispozici. Z toho důvodu je Plán testů průběžně kompletován v rámci Řízení testů. Plán testů obsahuje detailní rozpracování činností realizované při testování, jejich organizační zabezpečení a shrnutí dalších informací nezbytných pro koordinaci aktivit při testování. Vytvoření plánu je základem pro proces řízení testů, monitorování průběhu testů a hodnocení efektivity a výsledků testů. S dobře vypracovaným plánem je možné včas podchytit potenciální rizika a řešit problémy, které se během provádění testů objeví. Plán testů obsahuje •

Harmonogram testů

•

Organizační zabezpečení testů

•

Způsoby testování (viz kapitola 10.4 Testovací scénáře)

•

o

Manuální testy

o

Automatizované testy

o

Regresní testy

Typy realizovaných testů (viz kapitola 10.4 Testovací scénáře) o

Funkční testy

o

Výkonnostní testy

o

Platformové testy

o

Testy GUI (graphical user interface)

•

Odhady náročnosti přípravy a realizace dílčích podkladů

•

Specifikace testovacích data o

jsou to požadavky především na konfiguraci aplikace, např. jaká data budou potřeba nahrát, aby se mohly provést naplánované testy.

•

Požadavky na testovací prostředí pro provedení testování

•

Akceptační kritéria

23

Po odhadu náročnosti proběhne specifikace testů, která stanoví základní přístup k testování, tj. jaké jsou základní podmínky, aby mohl být požadavek otestován, jaké typy testů (funkční, výkonnostní, ...) budou realizovány či zda bude například třeba realizovat regresní testování, tj. testy zaměřené na úplné otestování celé aplikace. V tomto procesu jsou rovněž jednoznačně stanovena akceptační kritéria, která musí být objektivní a měřitelná, které může bez problému posoudit 3. osoba. Tyto kritéria musí být daná na začátku projektu nebo zadání nové funkčnosti, protože mohou být v době dokončování zpochybňována jak klientem, tak samotným dodavatelem.

Obr. 10 Plánování testů Plánování testů

Analýza požadavků

Odhad náročnosti testování

Naplánování testů

Plán testů

Specifikace testů

Stanovení akceptačních kritérií

10.1.1.1 Odhad náročnosti testování Analytik na základě zadání požadavků a jejich analýzy dopadu identifikuje, jaké typy testů bude nad požadavky třeba realizovat a náročnost jednotlivých typů testů, např. kolik času je potřeba na provedení všech testů a kolik člověkohodin. Na základě uvedených podkladů bude možné přesněji odhadnout náročnost testů a s dostatečným předstihem zajistit zdroje nezbytné pro realizaci testů. Odhad náročnosti je třeba detailněji specifikovat u komplexnějších či náročných požadavků, u drobných požadavků postačí uvést celkový odhad náročnosti testů. Test koordinátor pak tento odhad použije jako podklad pro naplánování testů.

24

10.1.1.2 Naplánování testů Naplánování testů provádí Test koordinátor po zahájení projektu na základě milníků vývoje (dokončení vývoje, předpokládané datum nasazení do u klienta apod.), ale v dostatečném předstihu před přípravou podkladů pro testování a realizací testů. Časově Naplánování testů spadá do etapy, kdy probíhá příprava analýzy. Zde vznikne klíčová část dokumentu Plán testů. Případné úpravy vzniklého plánu, které dále vyplynou z probíhající analýzy a jsou dále prováděny v rámci procesu Řízení testů.

10.1.1.3 Specifikace testů Specifikace probíhá před Přípravou a Provedením testů v rámci procesu Plánování testů, která je zahájena souběžně s analýzou a Naplánováním testů. Proces specifikace je jednou z činností Test koordinátora, které směřují k dalšímu zásadnímu doplnění Plánu testů. Cílem specifikace je shromáždit objektivní informace, na základě kterých je možné v vytvořit harmonogram a odhady kapacit. V rámci tohoto procesu jsou realizovány následující činnosti: •

rozčlenění požadavků do logických částí, které má smysl testovat samostatně;

•

rozhodnutí o typech testů (funkční, výkonnostní, ...);

•

zařazení požadavků do testovacích sestav, které budou realizovány nad daným systémem;

•

zvolení vhodných podkladů, aby se optimalizovalo zatížení pracovníků, kteří testování budou realizovat; jako podklady mohou sloužit následující: o

Testovací scénáře - jsou definovány u požadavků, kde se předpokládá manuální otestování testery.

o

Testovací skripty -

vznikají/jsou aktualizovány u požadavků testovaných

automatizovaným způsobem. Další úpravy specifikace, které jsou například dány na základě pokračujícího analýzy, jsou realizovány v rámci procesu Řízení testů při kompletaci specifikace testů.

10.1.1.4 Stanovení akceptačních kritérií Akceptační kritéria v souvislosti s testováním slouží jako podklad pro plánování, konkrétně v oblasti odhadu celkové doby testování, typů testů a způsob jejich přípravy. Akceptační kritéria jsou základem dohody mezi dodavatelem softwaru a zadavatelem ohledně kvality aplikace požadované ze strany zadavatelů. Z toho důvodu akceptační kritéria musí být jednoznačně definována před vlastním provedením testů. Je tedy třeba specifikovat kritéria co nejdříve, poněvadž mohou významným způsobem ovlivnit následnou pracnost realizace požadavků. Akceptační kritéria definuje Analytik při zpracovávání analýzy dopadu požadavku na základě informací obsažených v zadání požadavků a informací získaných při komunikaci s klientem. Tato kritéria je třeba odsouhlasit ze strany klienta, aby mohly sloužit jako podmínka akceptace.

25

10.1.2 Příprava testů Základními vstupy do přípravy testů je analýza požadavků. Jako další, doplňkové podklady slouží případné provozní SLA a Plán testů. Příprava testů je zaměřena na vytvoření podkladů a dalších materiálů nezbytných pro efektivní provedení testů. Podklady mohou mít podobu: •

Analýza požadavků

•

Testovací požadavky

•

Testovací scénáře / skripty

Uvedené podklady jsou roztříděny do testovacích sestav. V případě Analýzy požadavků budou mít podobu seznamu jednotlivých funkcionalit v pořadí, v jakém se spouští, v případě testovacích scénářů půjde o seznam pořadí spouštěných požadavků či jednotlivých scénářů a v případě automatizovaných testovacích skriptů bude testovací sada vytvářena přímo v použitém nástroji. Kromě těchto podkladů jsou připravována i testovací data a jsou zadávány požadavky na testovací prostředí (např. nakonfigurování databáze, způsob instalace, verze aplikace apod.). Obr. 11 Příprava testů Příprava testů Vytváření podkladů

Analýza požadavků

Příprava analýzy požadavků pro testování

Plán testů

Vytváření testovacích požadavků

Provozní SLA

Vytváření testovacích sestav

Testovací sestavy

Vytváření testovacích skriptů a scénářů

Příprava testovacích dat

Testovací data

Identifikace požadavků na testovací prostředí

Testovací Prostředí

26

10.1.2.1 Příprava analýzy požadavků pro testování Analytik provede Analýzu požadavků, které využije jako součást podkladů pro realizaci testů a která budou následně zařazena do testovacích sestav. Součástí je rovněž identifikace souvisejících testovacích dat.

10.1.2.2 Vytváření testovacích požadavků Testovací požadavky jsou jedním z podkladů pro manuální testování, které provádí Analytik. Testovací požadavky mohou vznikat kdykoli během doby Přípravy testů. Požadavky jsou v podstatě neformalizované podněty na otestování potenciálně problematických situací. Analytik je vytváří jako doprovodné poznámky k analýze požadavků, aby se na nic nezapomnělo.

10.1.2.3 Vytváření testovacích scénářů/skriptů Testovací scénáře jsou jedním z podkladů pro manuální testování, které vytváří Test analytik pro Testery. Test analytik v rámci scénáře uvede jednotlivé kroky: •

co přesně má testující udělat;

•

na co kliknout;

•

jaké hodnoty / data zadat ;

•

ověřovací akce, tzn. kontrola očekávané chování systému.

Pro použití automatizovaných testů vytváří Test analytik ve zvoleném nástroji Testovací skripty, které jsou automatizovanou obdobou testovacích scénářů. Dá se očekávat, že prvotní záznam scénáře/skriptu bude vyžadovat výraznější podporu ze strany Analytika, další úpravy scénáře/skriptu, však budou vyžadovat pouze omezené konzultace.

10.1.2.4 Vytváření testovacích sestav Testovací sestavy jsou základní jednotkou, nad kterou se plánuje a probíhá testování. Testovací sestavy jsou logický sled jednotlivých podkladů pro testování, které dohromady tvoří jeden celek. Při vytváření sestavy postupuje kompetentní pracovník tím způsobem, že seřadí podklady vytvořené k otestování určité funkcionality či skupiny funkcionalit do chronologického pořadí, v jakém jsou za sebou realizovány. V případě manuálního testování vytváří Testovací sestavy Analytik. U automatizovaného testování vytváří sestavy v příslušném nástroji Test analytik na základě informací od Analytika.

27

Obr. 12 Testovací sestavy

Testovací sestavy

Analýza Testovací požadavků požadavky

Testovací scénář

Testovací skript

10.1.2.5 Příprava testovacích dat Data nezbytná pro provedení testů jsou obecně shrnuta v Plánu testů a konkrétně specifikována v dalších výše uvedených vstupních dokumentech. Vývojář na základě uvedených vstupů připraví data pro testování, což obnáší (dle typů dat): •

návrh databázových dotazů či skriptů pro vygenerování dat;

•

vytvoření vstupních dat (hodnoty polí, tabulky, seznamy hodnot,...);

•

vytvoření očekávaných výsledků (výpočty, výstupy provedených akcí);

•

příprava výchozí sady dat před zahájením testování.

10.1.2.6 Identifikace požadavků na testovací prostředí Test koordinátor specifikuje konkrétní požadavky na HW a SW vybavení testovacího prostředí: •

jaké servery je třeba nainstalovat,

•

konfigurace DB, serverů,

•

vybavení testovacích stanic apod.

Jsou definovány požadavky na všechna prostředí pro všechny systémy a všechna stádia testování, kterými implementované změny prochází.

10.1.3 Provedení testů Provedení testů je realizováno s využitím podkladů a dalších materiálů vytvářených v předchozím kroku. Samotné vykonání testů může mít dvojí podobu: •

Provedení testů – v případě manuálních testů;

•

Spuštění testů a dohled nad běžícími skripty.

28

Chyby, které jsou při testování zachyceny, jsou zaznamenávány do k tomu určeného nástroje. Na záznam chyb navazuje jejich sledování – po vyřešení chyby jsou prováděny retesty příslušných funkčností. Výstupy z provedení či spuštění testů jsou výsledky testů. Výsledky testů mohou mít různou podobu, která závisí především na charakteru testovacích sad. V případě manuálního testování půjde o přehled výsledků jednotlivých scénářů. V případě automatizovaného testování budou výsledky vygenerovány přímo z nástroje. Obr. 13 Provedení testů

Plán testů

Provedení testů

Provedení / spuštění testů

Výsledky Aktualizovaný testů Plán testů

Testovací sestavy

Retesty Testovací data

Správa chyb

Nakonfigurované testovací prostředí

10.1.3.1 Provedení/spuštění testů Za provedení a spuštění manuálních a automatizovaných testů jsou zodpovědné role Testera a Test analytika. Manuální testování je prováděno pomocí Testovacích scénářů, za které je kompetentní Tester. Při provádění testů Tester průběžně zaznamenává Výsledky testů, aby zajistil plynulou správu požadavků. Za realizaci automatizovaných testů zodpovídá Test analytik, který spouští Testovací sestavy složené z Testovacích skriptů ve zvoleném nástroji pro podporu automatizovaných testů. Nástroj provede testy a vygeneruje Výsledky testů.

10.1.4 Vyhodnocení testů Klíčovými vstupy tohoto procesu jsou Výsledky testů, aktualizovaný testovací plán a databáze chyb. Především na základě těchto vstupů jsou vytvářeny pravidelné reporty o postupu testování a kvalitě testované aplikace.

29

Obr. 14 Vyhodnocení testů Vyhodnocení testů

Výsledky testů

Aktualizovaný Plán testů

Vytváření reportů

Databáze chyb

Výsledky testů

Postup testování

Chybovost

10.1.4.1 Vytváření reportů Test koordinátor připravuje v pravidelných intervalech reporty, které jsou zaměřeny na: •

postup testování, kde porovnává plán vs. skutečnost a vyhodnocení, zda byly realizovány všechny naplánované testy či které testy nebyly v rozporu s plánem realizovány;

•

kvalitu testované aplikace, konkrétně typy zjištěných chyb, kategorie, stav řešení, trendy….

Podklady pro reporty získá Test koordinátor na základě předdefinovaných dotazů ve využívaných nástrojích na podporu testování.

10.1.5 Správa chyb Jedním z účelů testování je odstranit chyby, které vznikly v průběhu vývoje. Během testování je zpravidla vyhodnocena řada chyb. Chybou rozumíme neočekávané chování aplikace či je toto chování dokonce v rozporu s požadavky klienta. Aby bylo ze strany zadavatele možné funkčnost akceptovat, je třeba objevené chyby opravit a vytvořit novou verzi systému, která je již neobsahuje. Chyby jsou nejvíce nacházeny a řešeny v období, kdy probíhá proces Provedení testů. Nalezené chyby jsou pak zaznamenány do databáze chyb (do bug trackingového nástroje), kde je sledován jejich průběh oprav. Obr. 15 Správa chyb Správa chyb

Výsledky testů

Zaznamenání chyb

Sledování zaznamenaných chyb

30

Databáze chyb

10.1.5.1 Zaznamenání chyb Způsob zadání chyby závisí na tom, kdo realizuje testy a na základě jakých podkladů. Manuální testy V případě, že jsou testy realizovány manuálně Testerem (na základě Testovacích scénářů), jsou chyby zaznamenány přímo testujícím do databáze chyb, které jsou pak řešeny v souladu s definovaným životním cyklem. Automatizované testy U automatizovaných testů jsou testy spouštěny Test analytikem, který vytvářel příslušné skripty. Test analytik na základě Výsledků testů prvním kroku vyhodnotí, zda se skutečně jedná o chybu testované aplikace či např. chybu ve skriptu, pak zadá zjištěnou chybu standardním způsobem do databáze chyb.

10.1.5.2 Sledování zaznamenaných chyb Součástí procesu správy chyb je sledování postupu řešení zaznamenaných chyb. Stav řešení chyby je součástí databáze, kterou Test koordinátor sleduje, vyhodnocuje a na základě získaných informací provádí aktualizaci Plánu testů. Pro efektivní řešení chyb je třeba je průběžně sledovat, v jakém stavu se nacházejí, jaké je jejich množství atd. Za sledování chyb je zodpovědný Test koordinátor, který musí udržovat neustálý přehled o chybách. Sleduje tedy: •

nové chyby, o

•

Sleduje je v určitém časovém intervalu (denně, týdně, ...).

chyby dle stavů , o

Kolik chyb se nachází v jakém stavu (např. kolik chyb je opraveno, kolik chyb je v řešení, ...).

•

trendy v řešení chyb. o

Sleduje poměr nově vzniklých chyb k uzavřeným chybám. Z tohoto poměru může odvodit, zda je vývojový tým schopen chyby včas zapracovat.

Test koordinátor na základě zjištěných informací případně aktualizuje Plán testů nebo podniká kroky směřující k minimalizaci nebo odstranění dopadu chyb na testování v rámci release.

10.1.6 Řízení testů Právě v oblasti řízení testů se odehrává koordinace dílčích aktivit a průběžné sledování a vyhodnocování procesu testování. Celý proces Řízení testů spadá do kompetence Test koordinátora a představují hlavní výkonnou složku jeho práce.

31

V úvodních fázích testování proběhne rovněž kompletace testovacího plánu, tj. je dokončena specifikace testů a kompletace akceptačních kritérií. S definitivní platností se rozhodne, jaké typy testů budou realizovány, v jakých kolech, průběžně jsou detailizovány harmonogramy jednotlivých testů a jsou jednoznačně určena akceptační kritéria. V návaznosti na postup a výsledky testování probíhá aktualizace a detailizace plánu testů. Na konci akceptace vzniká Akceptační protokol, který je podepisován klientem. Akceptační protokol je seznam akceptačních kritérií, kde klient svým podpisem stvrzuje, že byly všechny kritéria pro předání splněna a přebírá řešení od dodavatele řešení. Obr. 16 Řízení testů Řízení testů

Plán testů

Koordinace aktivit a monitorování testů

Aktualizovaný Plán testů

Kompletace specifikace testů

Výsledky testů

Postup testování

Kompletace Akceptačních kritérií

Řízení akceptace

Akceptační protokol

Chybovost

10.1.6.1 Koordinace aktivit a monitorování testů Test koordinátor provádí průběžné monitorování probíhajících činností (např. na základě reportů o testování, eskalovaných problémů apod.) a s využitím získaných informací provádí řízení činností při testování a řešení případných problémů a rizik.

10.1.6.2 Kompletace specifikace testů Test koordinátor upraví specifikaci testů v Plánu testů. To znamená, že zapracuje případné změny, které se týkají typů realizovaných testů, jejich stádií, organizací testů v sestavách, míry formalizace podkladů pro testování apod., jak již bylo popsáno v aktivitě Specifikace testů. Mělo by se jednat o průběžné finální úpravy.

32

10.1.6.3 Kompletace akceptačních kritérií V případě potřeby, na základě zpodrobňujících informací Test koordinátor doplní či upřesní akceptační kritéria, která byla specifikována v Plánu testů během aktivity Definice akceptačních kritérií. Tato kritéria je třeba odsouhlasit ze strany klienta, aby mohly sloužit jako podmínka akceptace. Definice akceptačních kritérií musí být dokončena před zahájením realizace testů.

10.1.6.4 Řízení akceptace Řízení akceptace není jednorázovou akcí na konci procesu testování, ale je dlouhodobější aktivitou. Je postavena na akceptačních kritérií před realizací testů a probíhá již od úvodních jednání s klientem, ohledně plánování a realizace akceptace. Řízení akceptace zahrnuje řadu činností, které směřují k bezproblémové komunikaci mezi zadavatelem, který požaduje funkcionalitu v konkrétní kvalitě, a dodavatelem řešení, který na základě definovaných kritérií obhajuje dodržení požadavků klienta. Za řízení akceptace je zodpovědný Test koordinátor, který především musí: •

určit způsob spolupráce mezi pracovníky IT a klientem;

•

vyjasnit, jakým způsobem budou připraveny podklady pro akceptační testy;

•

dohodnout případné využití existujících podkladů pro testování;

•

sledovat a vyhodnocovat výsledky akceptačních testů;

•

řešit případná rizika a související problémy během akceptačních testů;

•

zajistit formální schválení akceptace prostřednictvím akceptačního protokolu.

10.2 Organizační struktura V této kapitole charakterizuji jednotlivé role z procesu testování, kde specifikuji jejich požadované vlastnosti a aktivity, za které jsou zodpovědné. Tyto role pak zařadím do stávající organizační struktury k jednotlivým zaměstnancům.

10.2.1 Analytik Analytik je v rámci testování kompetentní za realizaci činností, pro které je nezbytná jeho znalost příslušného systému po funkční a business stránce. Analytik je kompetentní: •

za vytvoření vybraných podkladů pro testování, o

odhadnutí náročnosti testování před zařazením požadavku do release

o

zkompletování Analýzy požadavků

o

vytvoření Testovacích požadavků

33

•

za poskytnutí zpětné vazby pro Test koordinátora,

•

za komunikaci s Test analytikem při zpracovávání Testovacích scénářů či skriptů (ověření správnosti).

Předpokladem pro efektivní práci Analytika je: •

vynikající znalost funkční stránky příslušného systému,

•

výborná orientace v řešení business problematice,

•

manažerský pohled na řešení zadané změny,

•

organizační a komunikační schopnosti,

•

znalost v oblasti vytváření Testovacích požadavků. Obr. 17 Kompetence analytika

Analytik

Analýza požadavků

Testovací sestava

Testovací požadavky

Obr. 18 Realizované aktivity Realizované aktivity Plánování testů

Odhad Stanovení akceptačních náročnosti testů kritérií Provedení testů

Příprava Vytváření testovacích Vytváření analýzy požadavků požadavků testovacích sestav

10.2.2 Test koordinátor Test koordinátor představuje řídící roli v oblasti testování. Jeho hlavní pracovní náplň zahrnuje realizaci manažerských činností:

34

•

řízení a koordinace činnosti související s přípravou a realizací testů,

•

sledování a monitorování stavu testování,

•

průběžné monitorování postupu testování a jeho vyhodnocení oproti stanovenému plánu,

•

definice a sledování klíčových metrik (termíny, potřeba zdrojů, ...),

•

příprava reportů o stavu testování,

•

řešení a eskalace problémů či rizik během testů.

Test koordinátor je rovněž zodpovědný za naplánování testů: •

Na základě klíčových milníků realizace změny plánuje harmonogram testování.

•

Odhaduje náročnost realizace dílčích činností během testování.

•

Na základě komunikace s kompetentními pracovníky organizuje otestování požadavků prostřednictvím testovacích sad.

•

Stanoví nezbytnou míru formalizace podkladů pro testy.

•

Specifikuje kola testů.

•

Určuje nezbytné typy testů, které je třeba realizovat.

Test koordinátor během řízení akceptace komunikuje s klientem s cílem zajistit, aby akceptace proběhla v termínech. V souvislosti s akceptací musí ve spolupráci se zadavateli vymezit především: •

organizace akceptačního procesu,

•

způsob přípravy realizace akceptačních testů,

•

harmonogram akceptace,

•

formální dokumentaci akceptace.

Požadované znalosti: •

dobré znalosti oblasti testování softwaru,

•

manažerské dovednosti nezbytné pro řízení a koordinaci aktivit,

•

znalost testovacích nástrojů pro podporu automatizovaného testování (principy jejich používání a způsob jejich práce),

•

manažerská praxe v oblasti testování (plánování a organizace testů).

35

Obr. 19 Kompetence Test koordinátora

Test Koordinátor

Plán testů

Testovací prostředí

Záznam chyby

Test report

Akceptační protokol

Obr. 20 Realizované aktivity Realizované aktivity Plánování testů

Naplánování testů

Příprava testů

Specifikace testů

Vyhodnocení testů

Vytvoření reportů

Identifikace požadavků na testovací prostředí

Správa chyb

Sledování zaznamenaných chyb

Řízení testů

Koordinace aktivit a monitorování testů

Řízení Kompletace Kompletace akceptačních akceptace specifikace testů kritérií

10.2.3 Test analytik Test analytik je role, která je v oblasti testování spojena s využitím nástrojů pro podporu automatizovaného testování a testování podle scénáře. Test analytik je kompetentní: •

za rozpracování podkladů pro manuální testování do takové úrovně detailu, aby mohli systém bez problémů otestovat testeři, kteří nedisponují detailní znalostí systému; o

Je vhodné, když Test analytik pouze testovací scénáře vytváří a ne je přímo provádí, je to kontraproduktivní. Když Test analytik testuje podle vlastních scénářů, tak nabývá dojem, že všechny testovací kroky zná a nemusí se tedy podle scénáře řídit. Tím vzniká riziko přehlédnutí chyby v aplikaci.

36

•

za základní správu nástroje pro automatizované testování: o

za úkony nezbytné pro přípravu testů v nástroji,

o

za vytváření struktury testů.

•

za vytváření podkladů pro automatizované tetování v podobě Testovacích skriptů;

•

za ladění a úpravy Testovacích skriptů;

•

definice Testovacích sestav;

•

komunikaci s Analytikem při specifikaci cíle testovacích scénářů či skriptů a ověření jejich věcné správnosti;

•

identifikace testů (testovacích scénářů) vhodných pro automatizaci;

•

za vytvoření a spouštění automatizovaných testů.

Požadované znalosti: •

výbornou znalost zvoleného nástroje pro podporu automatizovaného testování,

•

z pohledu správy nástroje a jeho uživatelské úpravy,

•

z pohledu jeho funkčnosti, struktury záznamů, nastavení a praktického využití,

•

znalosti souvisejících softwarových nástrojů,

•

znalost skriptovacího jazyka pro případné úpravy automaticky generovaných skriptů,

•

znalost oblasti testování, především podoby standardizovaných dokumentů, tzn. Testovací scénáře, Testovací skripty a jejich obsahu,

•

znalost klíčových metodik testování. Obr. 21 Kompetence Test analytika

Test Analytik

Testovací scénář

Testovací skript

Testovací sestava

37

Záznam chyby

Výsledky testů

Obr. 22 Realizované aktivity Realizované aktivity Příprava testů

Vytváření testovacích scénářů/skriptů

Vytváření testovacích sestav

Provedení testů

Spuštění/provedení testů Správa chyb

Zaznamenání chyby

10.2.4 Tester Tester je role, která je kompetentní za samostatnou realizaci manuálních testů podle detailních testovacích scénářů, následný záznam chyb a restování opravených chyb. Znalosti požadované na této roli jsou základní znalosti testované aplikace a její účel používání klientem. Obr. 23 Kompetence Testera

Tester

Výsledky testů

Záznam chyby

Obr. 24 Realizované aktivity Realizované aktivity Provedení testů

Spuštění/provedení testů

38

Zaznamenání chyby

10.2.5 Zařazení rolí do organizační struktury společnosti Jak jsem již v kapitole 8.1.1

Projekt Docházka a výkony zmiňovala, tak na projektu pracují:

•

1 vedoucí projektu / analytik,

•

2 vývojáři,

•

2 testeři, z nich jeden na poloviční úvazek.

V této kapitole zařadím do organizační struktury role na projektu. Na tento projekt bych navrhovala přijmout jednoho zaměstnance, který by zastával roli Analytika na projektu. Tomuto nového zaměstnanci by vedoucí projektu postupně předával své know-how a povinnosti analytika. Tento nový zaměstnanec by vykonával pouze roli Analytika. Další zaměstnanec, který pracuje jako tester na plný úvazek by vykonával roli Test koordinátora a Test analytika. Musel by projít několika školeními na testování. Tento zaměstnanec by byl kompetentní

především

za

řízení

procesu

testování,

psaní

testovacích

manuálních

a

automatizovaných testů. Zaměstnanec na poloviční úvazek by měl roli testera, který testoval aplikaci podle testovacích scénářů napsaných Test analytikem, řídil se pokyny Test koordinátora a zaznamenával nalezené chyby. Obr. 25 Organizační struktura projektu

Vedoucí projektu

Nový zaměstnanec na projektu

Test Koordinátor

Test Designér

Analytik

Tester

10.3 Automatizované testování Některé funkčnosti, které se nemění, se musí testovat vícekrát, aby se ověřilo, že chyby z předcházejících testů byly skutečně opraveny a neobjevili se nové. Tomuto opakovanému procesu testování se říká regresní testování. Toto testování může provádět manuálně tester podle

39

testovacího scénáře. Opakování regresního testování určité funkčnosti může být vzhledem k harmonogramu nemožné nebo pro testera dost jednotvárná činnost, kde vzniká riziko přehlédnutí chyby. Eliminování tohoto rizika je výběr vhodného nástroje na automatizaci testů aplikace. Automatizovaný test se skládá z jednotlivých testovacích skriptů. Testovací skript je sada kroků a bodů ověření vedoucí k provedení testů pomocí SW aplikace. „Princip automatického testování spočívá v zaznamenání nebo vyvolání požadované činnosti v testované aplikaci pomocí určitého nástroje tj. jiné SW aplikace pro automatické testování softwaru a následné přehrání a vyhodnocení této činnosti. Lidský zásah je nutný pouze v počáteční fázi záznamu a tvorby automatického testu a případně při jeho vyhodnocení. Samotný test probíhá automaticky. Mezi výhody patří nízké náklady na samotný provoz, protože veškerou činnost obstarává samotný nástroj bez nutnosti lidského zásahu. Absence lidského faktoru v procesu testování také eliminuje případné chyby a omyly, které vznikají díky lidské nepozornosti. I přes zjevné výhody se automatické testování potýká s mnoha překážkami. Největší z nich jsou vysoké počáteční náklady, časová a organizační náročnost celého řešení a potřeba kvalifikovaných lidských zdrojů.“

2

Výhody manuálního testování: •

Na manuální testování není potřeba specializované pracovníky, stačí základní znalost aplikace jako má tester.

•

Na vytvoření testovacího scénáře nejsou třeba žádné pořizovací náklady. Test analytik tyto scénáře vytváří například do textového nebo tabulkového dokumentu.

•

Testovací scénáře se snadno používají (všechny kroky jsou detailně popsány).

Nevýhody manuálního testování: •

Když se testování funkčnosti opakuje vícekrát, tak je to časově náročné a je riziko, že se nestihnou všechny naplánované testy.

•

Pokud tester provádí testování vícekrát, tak ztrácí pozornost a podléhá dojmu, že scénář zná, tím vzniká riziko přehlédnutí chyby, která by mohla ohrozit akceptaci releasu klientem.

•

Během opakovaného testování určité funkčnosti se Tester nemůže věnovat jiným testům, které mu Test koordinátor naplánoval.

Výhody automatizovaného testování: •

Testování pomocí automatizovaného nástroje je mnoho násobně rychlejší než opakované provádění manuálního testování testerem.

•

Po spuštění automatizovaných testů se může Test analytik věnovat další práci, tj. práce je mnohem efektivnější.

2

BLAŽOVÁ, Romana. TST Automatické testy : Přednáška pro předmět Testování software [online]. s. 1

40

•

Automatizovaný test se může spustit mnohokrát a vždy test proběhne přesně, správně a za stejný časový úsek.

Nevýhody manuálního testování: •

Na trhu je spousty nástrojů pro automatizované testování, proto pořízení takové nástroje může mít vysoké pořizovací náklady.

•

Na používání tohoto nástroje je potřeba zkušené pracovníky, kteří budou umět pracovat s tímto nástrojem a v případě potřeba doprogramovat část skriptu.

•

Vytváření automatizovaných testů je časově náročné, proto se automatizovaně testují jen funkčnosti, které se nemění, jinak by práce byla neefektivní.l

•

Automatizované testování nemůže nahradit lidské oko a intuici. Automatizovaný test otestuje pouze to, co má naprogramováno.

•

Pomocí automatizovaných testů nelze testovat uživatelské rozhraní.

10.3.1 Testovací nástroje pro automatizované testování „HP QuickTest Professional

je nástroj pro automatizované testování funkčnosti aplikací,

především prostřednictvím uživatelského rozhraní. Vlastnosti produktu: •

Simuluje práci skutečného uživatele, zaznamenává chování aplikace a sleduje, zda se shoduje s očekávaným chováním.

•

Při nahrávání testovacího skriptu je prováděna tatáž činnost jako u skutečného uživatele.

•

Zaznamenává uživatelské činnosti do skriptu pomocí VBScriptu.

•

V místech, kde má QuickTest provést určitou kontrolu, vkládáme do skriptu kontrolní body. Kontrolní bod obsahuje předpis kontroly a očekávané hodnoty. Očekávanou hodnotou mohou být zobrazená data, vlastnosti nějakého objektu či výsledek SQL dotazu. Po spuštění testovacího skriptu dojde k porovnání a vyhodnocení hodnot očekávaných a skutečných. QuickTest vše zaznamená do podrobných, graficky zpracovaných, výstupních zpráv.“

3

CubicTest CubicTest je nástroj pro automatizované testování založený na grafickém editoru. Tento nástroj lze využít prakticky pro všechny webové aplikace, kde podporuje většinu uživatelských interakcí.

3

KOMIX, s. r. o. - HP QuickTest Professional [online].

41

Vlastnosti produktu: •

Podobně jako HP QuickTest simuluje skutečného uživatele, v podstatě přímo nahrává uživatelovo klikání do webové aplikace. Testovací skript lze také sestavit pomocí grafického editoru, kam se přidávají jednotlivé prvky stránky, na které se pak navazují uživatelské interakce.

•

CubicTest je to Open Source grafický modul Eclipsu (vývojové platformy určené pro programování v jazyce Java).

•

Tento nástroj lze spouštět v různých prohlížečích. Jako výchozí prohlížeč pro editaci a spouštění testů je Firefox nebo Opera. Po nainstalování watir plug-in lze testy spouštět i prohlížeči Internet Explorer.

Pro projekt Docházka a výkony bych doporučila nástroj CubicTest, protože se snadno ovládá přes grafický editor nebo jen nahrává kliky uživatele. Tento nástroj je open source, takže by nebyly žádné náklady na pořízení.

10.4 Testovací scénáře Testovací scénáře jsou skupina po sobě logicky následujících kroků a ověřovacích akcí, které mají za cíl otestovat vybranou funkčnost aplikace, např. přihlášení do aplikace: 1. zadání uživatelského jména 2. zadání hesla 3. potvrzení zadaných přihlašovacích údajů 4. načtení aplikace Jednotlivé testovací případy ve scénáři mohou na sebe navazovat a tím pádem je nutné je vykonávat v hierarchicky nebo na pořadí testování jednotlivých případů nezáleží. Testovací scénář může mít stejnou strukturu jako analýza požadavků. Testovací scénář má nejčastěji podobu dokumentu, který je tvořen v tabulkovém editoru. Způsoby testování: o

manuální testy - testy realizované manuálně podle testovacího scénáře

o

automatizované -

testy realizované s využitím automatizovaného nástroje na

podporu testování o

regresní testy - testy zaměřené na otestování celého systému, tzn. včetně již testovaných funkčností

Typy realizovaných testů: o

Funkční testy - testy jsouzaměřené na ověření správnosti funkcí aplikace, tj. zda odpovídá analýze,

42

o

Výkonnostní testy – tento typ testů slouží ke komplexnímu ověření, zda je aplikace schopna pracovat v zátěži nebo jakým způsobem reaguje na abnormální podmínky, např. jak se aplikace chová, když je přihlášeno více uživatelů nebo při velkém množství transakcí, jestli není celkově pomalá.

o

Platformové testy – testy ověřují, jak se chová aplikace na různých platformách – např. v různých internetových prohlížečích, operačních systémech apod.

o

Testy GUI (graphical user interface) – tento typ testů ověřuje uživatelské rozhraní aplikace, jestli odpovídá nadefinovaným standardům, např. grafickému manuálu.

43

11. Závěr Cílem bakalářské práce byl návrh metodiky testování přizpůsobené projektu Docházka a výkony, pomocí všeobecné metodiky vývoje softwaru IBM Rational Unified Proces. Zaměřila jsem se zejména na návrh řešení v oblasti procesu testování, které má zlepšit kvalitu výstupu modelové společnosti. Aby však tato metodika byla v reálném nasazení účinná, je třeba zajistit fungování i ostatních procesů, které vývoj SW zahrnuje, tzn. analýzu, správu požadavků, změnové řízení atd. V této práci uváděná fiktivní společnost je na trhu už od roku 1991. Během svého působení na trhu, kdy byly vynalezeny nové technologie a moderní

vývojové procesy, své procesy vývoje

softwaru nemění, ale s jistou setrvačností v nich pokračuje. Společnost má 7 poboček po celé České republice se sídlem v Praze. Ze začátku se společnost věnovala vývoji a implementaci vlastního

softwaru,

tj. mzdovým a HR systémům. Později rozšířila svou působnost i na poskytování mzdového outsourcingu, který poskytuje v 8 evropských zemích, protože se jevil jako vhodný doplňkový produkt j již nabízeným službám. Nyní má tato společnost největší příjmy právě ze mzdového outsourcingu a vývoj vlastního softwaru tvoří z hlediska příjmů malou část. V této bakalářské práci jsem se zaměřila hlavně na problémy s kvalitou výstupů jednoho jejího projektu Docházka a výkony. V metodice testování jsem tento proces rozdělila do jednotlivých podprocesů a to: 1. Plánování testů o

V plánování se odhaduje časová náročnost testování, odhad potřebných zdrojů, specifikují se testy a stanovují akceptační kritéria se zadavatelem.

2. Příprava testování o

Příprava je zaměřena na vytvoření podkladů a dalších materiálů (Analýza požadavků,

Testovací

požadavky,

Testovací

scénáře,

Testovací

skripty)

nezbytných pro efektivní provedení testů. 3. Provedení testů o

Provedení testů je realizováno s využitím podkladů a dalších materiálů vytvářených v procesu plánování. Tento proces má podobu samotného provedení manuálních testů a případné spuštění automatizovaných testů.

4. Vyhodnocení testů o

V tomto procesu jsou vytvářeny pravidelné reporty o postupu testování a kvalitě testované aplikace.

5. Správa chyb o

Správa chyb probíhá zároveň s procesem Provedení testů. Tento proces zaznamenává nalezené chyby manuálním nebo automatizovaným testováním a sleduje průběh jejich opravy.

44

6. Řízení testů o

Řízení probíhá zároveň se všemi procesy testování, plánování a správou chyb. Zde se odehrává koordinace dílčích aktivit a průběžné sledování a vyhodnocování procesu testování.

Jako nejdůležitější dokument této navržené metodiky považuji Plán testů, který obsahuje detailní rozpracování činností realizované při testování, jejich organizační zabezpečení a shrnutí dalších informací nezbytných pro koordinaci aktivit při testování. Podle mého názoru hlavní přínos této práce je v tom, že se mi podařilo navrhnout metodiku testování na modelové společnosti, je která použitelná v praxi, konkrétně ve společnosti, kde právě pracuji. K nasazení do reálného používání však bude třeba tuto metodiku upravit do jednodušší formy, protože vzhledem k menšímu týmu by její plné zavedení nebylo tak efektivní. Navíc zde pracují dlouholetí zaměstnanci, kteří jsou na tomto projektu zvyklí na své za běhané postupy práce a nebude jednoduché je přesvědčit o zavedení nových procesů, jež vyžadují více projektové dokumentace. Věřím, že pokud se mi alespoň částečně podaří zavést navrhnuté procesy testování do reálného použití, podaří se tím zlepšit kvalitu výstupů projektu, přispět k pozitivním referencím stávajících klientů a poskytnout lepší podmínky pro získání nových klientů.

45

12. Conclusion The primary objective of this Bachelor thesis was to define a testing methodology customized to special project Attendance and Workloads. This methodology is based on the IBM Rational Unified Process (RUP) and its main purpose is to improve testing area in a model company. To achieve a measurable effect on the real project it is necessary to ensure other SW development processes such analysis, requirements management, change management etc. The model company mentioned in this thesis represents a fictive company founded in 1991. During its time in the market, when new technologies and SW development approaches were invented, this company stays mainly without changes. The company has 7 branches in Czech Republic with registered place in Prague. From the beginning the company focused on pure SW development and improved its own payroll and HR systems. Later the company services were extended payroll outsourcing and this service is provided in 8 European countries now. Actually the payroll outsourcing services are the most profitable product of this model company and therefore the custom development presents just a small part of the company revenues. In this thesis, I focused mainly on the problems with the quality of the project's Attendance and Workloads outputs. The testing methodology defined in this thesis is divided into individual sub-processes: 1. Test Planning o

Planning estimated testing effort, estimation of required resources, tests specifications and acceptation criteria defined by the client.

2. Test Preparation o

The preparation of testing inputs and other materials (requirements analysis, test requirements, test scenarios, test scripts) necessary for performing planned tests.

3. Test Execution o

Execution of the prepared tests with the appropriate inputs and materials. This can be performed as a classical manual testing or an automated test run.

4. Test evaluation o

Evaluating and reporting test results.

5. Defect Tracking o

Primary objective is to capture and handle defects discovered during the Test Execution.

6. Test Management o

Coordination of all activities related to the testing, continuous supervision and evaluation of the testing effort.

46

The most important document related to the testing methodology is probably the Test Plan. This document consists of the detail description of the testing related activities, their organization and summarizing other information needed for the Test Management. In my opinion, the key benefit of this thesis is that the defined methodology is able to be deployed into a real project. I assume that I will be able to deploy this methodology into the company which I am currently working for. This methodology cannot be deployed “out-of-the-box” but needs some other custom modifications to be more efficient in our project team which is smaller than team described in the model company. In addition there are some long-term employees who can be a little bit confused by the new testing approach and necessity of the more and new documentation. I believe

even

a partial deployment of this methodology is performed in our company, then the project outputs quality rises and it can contribute on better client references and provide better conditions to obtain new clients.

47

13. Seznam použité literatury 1. PATTON, Ron. Testování softwaru. Praha: Computer Press, 2002. 1. vyd. 314 s. ISBN 807226-636-5 2. URBAN, Vít. Návrh softwarového informačního systému pro podporu řízení projektů [Diplomová práce]. České vysoké učení technické v Praze, Listopad 2006. 3. Rational Unified Process 2002.05.00. IBM Rational Software Corporation, 2002. 4. Elanor, spol. s r. o. – Specialista na mzdy a personalistiku [online]. Edit. 01.03.2010 [cit. 2010-03-10]. Dostupné z WWW: . 5. Wikipedia, otevřená encyklopedie [online]. Edit. 22.04.2010 [cit. 2010-04-23]. Dostupné z WWW: . 6. Testování softwaru : základy testování [online]. Publ.11.08.2009 [cit. 2010-04-28]. Dostupné z WWW: . 7. CubicTest : Confluence [online]. Edit. 11.04.2010 [cit. 2010-04-30]. Dostupné z WWW: . 8. KOMIX, s. r. o. : HP QuickTest Professional [online]. Edit. 05.04.2010 [cit. 2010-04-30]. Dostupné z WWW: . 9. Jobs.cz : Spojení s elitou – nabídka práce, volná pracovní místa i brigády [online]. Edit. 29.04.2010 [cit. 2010-04-29]. Dostupné z WWW: . 10. Testovací scénář : CleverAndSmart [online]. Edit. 29.04.2010 [cit. 2010-05-01]. Dostupné z WWW: . 11. BLAŽOVÁ, Romana. TST Automatické testy : Přednáška pro předmět Testování software [online]. Publ. 20.04.2010 [cit. 2010-04-30]. Komerčně dostupné z WWW: . 12. BLAŽOVÁ, Romana. TST KDO, CO a KDY v procesu testování : Přednáška pro předmět Testování software [online]. Přednáška. Publ. 07.02.2010 [cit. 2010-04-30]. Komerčně dostupné z WWW: . 13. BLAŽOVÁ, Romana. TST Jak provádět testy : Přednáška pro předmět Testování software [online]. Publ. 01.04.2010 [cit. 2010-04-30]. Komerčně dostupné z WWW: .

48

14. Seznam obrázků •

Obr. 1 Organizační struktura sídla v Praze, str. 11

•

Obr. 2 Využití modulů aplikace, str. 13

•

Obr. 3 Projekty společnosti, str. 14

•

Obr. 4 Personální složení projektu, str. 14

•

Obr. 5 Model „Programuj a opravuj“ , str. 15

•

Obr. 6 Proces rozvoje, str. 16

•

Obr. 7a Stavy záznamu chronologicky, str. 17

•

Obr. 7b Stavy záznamu chronologicky, str. 18

•

Obr. 8 Proces zadání, str. 19

•

Obr. 9 Proces testování, str. 22

•

Obr. 10 Plánování testů, str. 24

•

Obr. 11 Příprava testů, str. 26

•

Obr. 12 Testovací sestavy, str. 28

•

Obr. 13 Provedení testů, str. 29

•

Obr. 14 Vyhodnocení testů, str. 30

•

Obr. 15 Správa chyb, str. 30

•

Obr. 16 Řízení testů, str. 32

•

Obr. 17 Kompetence analytika, str. 34

•

Obr. 18 Realizované aktivity, str. 34

•

Obr. 19 Kompetence Test koordinátora, str. 36

•

Obr. 20 Realizované aktivity, str. 36

•

Obr. 21 Kompetence Test analytika, str. 37

•

Obr. 22 Realizované aktivity, str. 38

•

Obr. 23 Kompetence Testera, str. 38

•

Obr. 24 Realizované aktivity, str. 38

•

Obr. 25 Organizační struktura projektu, str. 39

49