Každý defekt report prochází určitým životním cyklem, od nahlášení defektu testerem, přes opravu defektu vývojáři, až po uzavření defektu. U popisu pracovního produktu defekt report uvedena typická struktura defekt reportu. Jednou z položek defekt reportu je pole „Status“, ve kterém se mapuje a sleduje stádium životního cyklu defektu.
ISTQB neuvádí žádná doporučení, jak by měl životní cyklus defektu vypadat. Každá organizace má jinou kulturu, pravidla i organizační strukturu a neexistuje žádná standardizovaná podoba životního cyklu defektu. Nicméně každý tester se v praxi s nějakým životním cyklem defektu setkává a je nutné, aby jej organizace měla nadefinovaný a všichni členové projektového týmu aby byli obeznámeni s tím, do jakých stavů se defekt může dostat, které stavy jsou počáteční a koncové a jaké jsou přechody mezi jednotlivými stavy. Protože tato metodika vychází především z mezinárodních standardů a praktik, inspirovala jsem se životním cyklem defektu, který uvádí ve své knize Rex Black [2002, s. 135], uznávaný odborník, který je mimo jiné členem pracovní skupiny organizace ISTQB.
Schéma uvedné níže znázorňuje jednotlivé stavy a přechody mezi nimi. Výchozím stavem je „Nový“. Koncové stavy jsou označeny tučným orámováním a jedná se o stavy, kdy se defekt stane neaktivním a už nejsou vyžadovány ani se neočekávají další změny stavů, ačkoliv možné jsou. I uzavřený defekt report je možné znovu otevřít, pokud se například spolu s opravou jiných defektů daný defekt opětovně zanese. Přechody mezi jednotlivými stavy jsou značeny šipkami.
Životní cyklus defektu, zdroj: upraveno podle [Black, 2002, s. 135] |
Následující tabulka uvádí použití jednotlivých stavů dle výše uvedeného schématu. Vychází ze zdroje [Black, 2002, s. 133-134], ale byla upravena pro potřeby této metodiky podle zkušeností autorky práce.
Stavy v životním cyklu defektu a jejich použití, zdroj: inspirováno [Black, 2002, s. 133-134]
Stav |
Kdy se používá |
Nový |
Jakmile tester založí do systému nový defekt report. V tomto stavu není defekt report viditelný členům mimo testovací tým a čeká na schválení odpovědným členem testovacího týmu.
(Schvalování je zapotřebí zejména u začínajících testerů, zkušení testeři mají oprávnění defekt report posunout do dalšího stavu sami). |
Zamítnutý |
Pokud schvalovatel defekt reportu uzná za vhodné, aby byl defekt report přepracován, tzn. doplněn o další informace, znovu ověřen nebo přeformulován. Defekt je zamítnut a předán zpět testerovi, který musí defekt report přepracovat a znovu přepnout do stavu „Nový“ pro další schválení. |
Otevřený |
Pokud tester defekt kompletně charakterizoval a izoloval daný problém, schvalovatel defekt report posune do stavu „Otevřený“, kdy je viditelný všem členům projektového týmu. |
Přidělený |
Člen projektového týmu, který má na starost přidělování defekt reportů, přidělí defekt report na manažera vývojového týmu a ten jej předá k řešení vývojáři. Pokud vývojář nebo manažer vývoje zjistí, že je potřeba aby testeři defekt report doplnili, mohou jej předat zpět na testera k doplnění. |
Opravený |
Jakmile vývojáři defekt opraví, předají ho testerům k potvrzení, že oprava proběhla v pořádku a defekt byl kompletně odstraněn. |
Znovu otevřený |
Pokud testeři při potvrzení opravy defektu zjistí, že defekt přetrvává, nebo nebyl odstraněn kompletně, předají defekt report zpět na vývojáře, aby defekt kompletně odstranili. |
Uzavřený |
Jakmile jsou opravy defektů testery potvrzeny, je možné defekt report uzavřít. |
Odložený |
Pokud členové projektového týmu uznají, že se o defekt se skutečně jedná, ale má buď malou prioritu, nebo se jeho oprava naplánuje až na následující release, je defekt report odložen. Do stavu „Odložený“ je možné přejít kdykoliv během životního cyklu. |
Při přechodu mezi jednotlivými stavy je vhodné používat komentáře, aby osoba, na kterou je defekt report aktuálně přiřazen, věděla, co se od ní očekává. Při dokumentaci přechodů ve formě komentářů je možné v případě potřeby také zpětně dohledat historii defektu (např. pokud se již uzavřený defekt za nějaký čas objeví znovu).
|