Redesign procesu testů a test management

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 <http://www.unicorncollege.cz/>
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].
<http://sitecore.cz/Produkty/Software/Testovaci_nastroje/HP_QTP.aspx>
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: <http://www.elanor.cz/>.
5. Wikipedia, otevřená encyklopedie [online]. Edit. 22.04.2010 [cit. 2010-04-23]. Dostupné z
WWW: <http://wikipedia.cz>.
6. Testování softwaru : základy testování [online]. Publ.11.08.2009 [cit. 2010-04-28].
Dostupné z WWW: <http://testovanisoftwaru.blogspot.com/2009/08/zakladytestovani.html>.
7. CubicTest : Confluence [online]. Edit. 11.04.2010 [cit. 2010-04-30]. Dostupné z WWW:
<http://boss.bekk.no/display/BOSS/CubicTest>.
8. KOMIX, s. r. o. : HP QuickTest Professional [online]. Edit. 05.04.2010 [cit. 2010-04-30].
Dostupné z WWW:
<http://sitecore.cz/Produkty/Software/Testovaci_nastroje/HP_QTP.aspx>.
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: <http://www.jobs.cz/>.
10. Testovací scénář : CleverAndSmart [online]. Edit. 29.04.2010 [cit. 2010-05-01]. Dostupné z
WWW: <http://www.cleverandsmart.cz/testovaci-scenar/>.
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:
<http://www.unicorncollege.cz/>.
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: <http://www.unicorncollege.cz/>.
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:
<http://www.unicorncollege.cz/>.
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