Concept: Definice defektu a příbuzných termínů
Souvislosti termínů používaných napříč metodikou
Relationships
Main Description

V odvětví testování se lze setkat s různými termíny pro chyby v softwaru. V této metodice jsou používány pojmy dle termininologie ISTQB: anomálie (anomaly), defekt (defect), selhání (failure) a omyl (error).

Při provádění testů testeři srovnávají aktuální výsledky s očekávanými. Anomálie (taktéž nazývaná jako incident) je dle [ISTQB, 2012c, s. 9] „každý rozdíl aktuálního chování systému oproti očekáváním založeným na základě specifikací požadavků, designových dokumentů, uživatelských příruček, standardů atd. nebo na základě vnímání a zkušeností testera“. Každou anomálii je třeba důkladně prošetřit a zjistit, zda se jedná o selhání způsobené defektem v systému či komponentě, nebo jen o omyl na straně testovacího týmu. Anomálie tedy může, ale i nemusí být přímo defektem.

Pokud se zjistí, že příčinou rozdílu aktuálního a očekávaného chování je skutečně defekt, je zapotřebí založit defekt report [1] a daný problém dále řešit. Defekt je dle [ISTQB, 2012c, s. 18] definován jako „chyba v komponentě nebo v systému, která může způsobit, že systém selže při vykonávání požadované funkce, jako například nekorektní příkaz nebo definice dat“. V tomto pojetí je pojem defekt ekvivalentní s pojmem vada, popř. chyba (fault). Český výraz defekt má foneticky blíže k anglickému pojmu defect, používanému v materiálech ISTQB, a proto je jeho použití v této metodice vhodnější oproti alternativám vada či chyba.\s

S pojmem defekt je úzce spjat i pojem selhání. Pokud se při běhu komponenty či systému narazí na odchylku oproti očekávané dodávce, službě nebo výsledku, jedná se o selhání, které zhoršuje či znemožňuje používání systému [ISTQB, 2012c, s. 22]. Většina defektů je odhalena právě při pátrání po příčině selhání.

Jak ovšem tester pozná, že pozorované chování je v rozporu s chováním očekávaným? Způsob, jakým lze identifikovat, že se jedná o selhání softwaru, velice dobře vystihuje definice softwarové chyby, kterou uvádí Patton:

 „O softwarové chybě hovoříme tehdy, je-li splněna jedna nebo více z následujících podmínek:

1.      Software nedělá něco, co by podle specifikace produktu dělat měl.

2.      Software dělá něco, co by podle údajů specifikace produktu dělat neměl.

3.      Software dělá něco, o čem se produktová specifikace nezmiňuje.

4.      Software nedělá něco, o čem se produktová specifikace nezmiňuje, ale měla by se zmiňovat.

5.      Software je obtížně srozumitelný, těžko se s ním pracuje, je pomalý, nebo – podle názoru testera – jej koncový uživatel nebude považovat za správný.“ [2002, s. 14]

Podle této definice je chyba (ve smyslu selhání) stav, kdy se software zachová jinak, než předepisuje specifikace, nebo jinak než je očekáváno [Šplíchalová, 2008, s. 49]. Je zde zároveň vidět dvojí perspektiva při hledání chyb a určování správnosti chování software. První čtyři body představují selhání nalezená při verifikaci software. Cílem procesu verifikace je potvrdit, že software vyhovuje zadané specifikaci (systém je vytvořen správně) [Patton, 2002, s. 42]. Pátý bod se zaměřuje na selhání nalezená na základě validace software, což je kontrola, zda software vyhovuje požadavkům uživatele (je vytvořen správný systém) [Patton, 2002, s. 42]. Při hledání chyb a určování, zda se jedná či nejedná o selhání softwaru, musí tester pamatovat na verifikaci, ale i na validaci.

Příčinou defektů, selhání a anomálií jsou lidské omyly. Omyl je dle [ISTQB, 2012c, s. 20] definován jako „akce člověka, která způsobuje nekorektní výsledek“. Může se jednat například o nesprávné pochopení požadavků, kdy vývojář implementuje požadavek v kódu jinak, než bylo zamýšleno a tak vznikne defekt. Na druhé straně se omylu může dopustit i tester, když vyhodnotí chování softwaru jako selhání, ale ve skutečnosti se o selhání nejedná.


[1] Specifikace pracovního produktu defekt report je uvedena v pracovním produktu defekt report.