Artifact: Defekt report

Main Description

Jádrem provádění testů je srovnávání aktuálního chování systému s očekávaným. Pokud se skutečné chování od očekávaného liší, je třeba neočekávaný výskyt (tzv. anomálii) blíže prozkoumat. Když se prokáže, že anomálie je selhání způsobené defektem, je třeba založit defekt report [1] a nalezený defekt vyřešit.

Dle [ISTQB, 2012c, s. 18] je defekt report definován jako „dokument, který reportuje nějaký nedostatek v komponentě nebo v systému, který může způsobit, že daná komponenta či systém selže při vykonávání požadované funkce“.

Účelem defekt reportu je

· upozornit vývojáře a ostatní osoby zainteresované na projektu o defektu a poskytnout jim dostatečné informace pro identifikaci, izolaci a opravu defektu,

· poskytnout test manažerovi prostředky pro hodnocení kvality testovaného systému a kontrolu pokroku testování,

· poskytnout výchozí bod pro další release [Ramdeo, 2011],

· poskytnout podněty pro zlepšení procesu testování.

Dle Pattona je cílem softwarového testera vyhledávat chyby (v této práci nazývané termínem defekty), vyhledávat je co nejdříve a zajistit jejich nápravu [2002, s. 17]. Defekty nemusí být nalézány a reportovány až při samotném provádění testů, ale již mnohem dříve. Test analytik může objevit a nahlásit defekty už během přípravy testování při revizi a analýze podkladů pro testování. Čím dříve jsou defekty objeveny a nahlášeny, tím nižší náklady vyžaduje jejich oprava. Pokud je například během analýzy testů identifikován nekorektní požadavek a je opraven ještě předtím, než ho vývojáři implementují do kódu, předejde se ztrátě času na implementaci a otestování nekorektního požadavku v pozdějších fázích projektu. Nehledě na to, že pokud by byl požadavek zachycen až během akceptačních testů uživatelem, hrozí i narušení důvěry uživatele v daný systém.

Hlavní zodpovědnost za zakládání defekt reportů mají testeři, kteří objevují nejvíce defektů při provádění testů. Pokud ovšem defekty naleznou i jiní členové projektového týmu, mohou defekt report buď sami založit, nebo defekt předat testerům, kteří jej prověří a následně defekt report založí. Standard IEEE 829 definuje strukturu pro report o anomálii. Tato struktura rovněž platí i pro defekt report. Uspořádání polí reportu o anomálii ve standardu IEEE je příliš obecné a v praxi používaným šablonám defekt reportu vzdálené. Místo typických položek defekt reportu závažnost a priorita jsou zde položky s názvy dopad (impact) a hodnocení naléhavosti defektu z pohledu zakladatele defekt reportu (originator´s assessment of urgency). Do položky dopad jsou mimo jiné zahrnuty i odhady času, úsilí a rizik na opravu defektu, což obvykle bývá samostatná položka. Také se neztotožňuji se zde navrženou položkou kontext (context), která slučuje mnoho informací na jednom místě (identifikaci softwaru, proces životního cyklu softwaru, verzi testované položky, úroveň testování a odkazy na testovací skript, testovací případ a test log). Z těchto důvodů zde uvedená tabulka popisuje strukturu defekt reportu dle zdrojů [Kaner, 1993, s. 68-76; Šplíchalová, 2008, s. 55-56; Ramdeo, 2011; Software testing fundamentals, 2011], která je dle mého názoru praxi bližší a názornější.

Položky defekt reportu, zdroj: [Kaner, 1993, s. 68-76; Šplíchalová, 2008, s. 55-56; Ramdeo, 2011; Software testing fundamentals, 2011]

Položka defekt reportu	Popis
Identifikace defektu	Jedinečný identifikátor daného defektu, který je obvykle automaticky přidělen systémem pro správu defektů.
Shrnutí	Stručný a výstižný popis defektu. Ze shrnutí musí být jasné, k čemu se defekt vztahuje a jak je kritický. Často se jedná spolu s prioritou a závažností defektu o jedinou část, která zajímá manažery. Ke shrnutí je proto třeba přistupovat jako k titulku v novinách.
Produkt	Specifikace produktu, na kterém byl defekt nalezen.
Komponenta	Specifikace komponenty nebo modulu produktu, kde byl defekt nalezen. U komplexních produktů, kde je mnoho komponent či modulů, mohou manažeři podle určení konkrétní komponenty snadno předat defekt na odpovědnou osobu.
Identifikace verze a release	Identifikace kódu, který je na testu. Například identifikátor verze může být 1.01m a produkt může být nasazen jako release 1.01. Písmeno verze m značí, že se jedná o třináctý draft release 1.01 uvolněné pro testování.
Datum nálezu	Datum nalezení defektu (většinou se shoduje s datem zadání defektu reportu do systému). Datum nálezu je důležitý, zejména když nejsou dostupné informace o verzi produktu.
Typ reportu	Určení, zda se jedná skutečně o defekt jako je chyba v kódu, chyba návrhu, chyba ve specifikaci, hardwarová chyba, anebo se nejedná přímo o defekt, ale např. o návrh na vylepšení nebo o dotaz, pokud si tester není jistý, zda je chování systému korektní či nikoliv.
Závažnost	Dopad defektu na produkt vyjádřený v pětistupňové škále s hodnotami méně významná (minor), středně významná (normal), velmi významná (major), kritická (critical), blokující (blocker). Podrobnější popis je uveden v konceptu klasifikace defektů.
Priorita	Dopad defektu na byznys uživatele, podle kterého se určuje priorita prací. Je určena hodnotami v třístupňové škále nízká (low), střední (medium), vysoká (high). Podrobnější popis je uveden v konceptu klasifikace defektů.
Popis defektu	Podrobný popis defektu. Uvádí, zda je defekt reprodukovatelný a poskytuje dostatek informací k tomu, aby jej vývojáři i testeři mohli znovu nasimulovat. Součástí popisu defektu by měl být přesný popis kroků, které vedou k chybovému stavu včetně vstupních údajů, aktuální výsledky po provedení popsaných kroků, očekávané výsledky a prostředí, na kterém byl daný defekt nalezen (konfigurace počítače, databáze, operační systém, webový prohlížeč).
Autor reportu	Jméno osoby, která založila defekt report.
Aktuálně přiděleno na	Jméno osoby, na kterou je defekt momentálně přiřazen. Nejčastěji se jedná o vývojáře, který má na starosti opravu defektu, nebo o testera, který má za úkol defekt retestovat.
Status defektu	Identifikace současného stavu defektu. Základní sekvence stavů defektu může být následující: Nový, otevřený, přidělený, opravený, uzavřený. Podrobnější popis je uveden v konceptu životní cyklus defektu.
Přílohy	Jakákoliv dodatečná informace, která pomáhá developerům při pochopení problému a nasimulování selhání. Může se jednat o logy aplikace, testovací data, zachycení stisku kláves, printscreeny, výpisy z databáze, apod.
Komentáře	Prostor pro další komentáře vztahující se k defektu. Obvykle se zde k defektu vyjadřují vývojáři, testeři, technická podpora, produktový manažer, popř. další osoby. Řeší se zde, zda bude defekt opraven a jak, resp. důvody zamítnutí opravy defektu nebo důvody pro opětovné otevření defektu.

Dobrý defekt report by dle [Kaner, 1993, str. 76-78] měl být v psané podobě, očíslovaný, jednoduchý (neslučovat více defektů do jednoho defekt reportu), srozumitelný, reprodukovatelný (viz úloha analýza a reportování defektů), čitelný a nekritický (držet se pouze objektivních faktů a vypustit emoce).

V nástroji IBM Rational Quality Manager implicitně není k dispozici záložka s defekt reporty. Poskytovatelem defekt reportů je aplikace Change and Configuration Management (CCM). Z aplikace Quality Management je možné pouze defekt report založit a nikoliv jej dále spravovat. Pro správu defektů přímo z Quality Management je nejprve nutné integrovat Quality Management s Change and Configuration Management. Poté je v Quality Management k dispozici záložka „Defects“, kde lze defekty spravovat a propojovat s ostatními pracovními položkami stejně jako v Change and Configuration Management. [IBM, 2012]

Struktura polí defekt reportu v IBM Ratinal Quality Manager je neměnná, ale je obdobná jako výše uvedená vzorová struktura. Pro představu je k pracovnímu produktu defekt report přiložen jednak formulář pro vytváření nového defekt reportu, který nabízí aplikace Quality Management a jednak již vytvořený defekt report, který je umístěn v aplikaci Change and Configuration Management. Oproti struktuře defekt reportu navržené zde jsou v založeném defekt reportu navíc odhady času potřebného k opravě a předpokládané datum nasazení opravy (doplňuje se až dodatečně, po vytvoření defekt reportu). Pole pro identifikaci verze je rozděleno na verzi, ve které byl defekt nalezen a verzi, ve které bude, resp. je nasazena oprava. Také zde není přímo kolonka na specifikaci produktu a jeho komponenty, ale naopak je zde kolonka na určení projektové oblasti, ke které se defekt vztahuje a možnost defekt oštítkovat.

[1] Použití pojmu report je v oboru testování běžnější, než synonymní český výraz hlášení. Testeři při hlášení defektů často využívají nástroje pro podporu řízení testů a správu defektů, ve kterých je funkce založení defekt reportu (popř. incident reportu). Pojem defekt report je tedy v souladu se zvyklostmi testerů.