Účelem provádění testů je vyhledávání defektů. Tester by neměl předpokládat, že v systému vše funguje, jak má, ale naopak by se měl zaměřit na to, co je v rozporu s očekávaným chováním. Pokud tester na rozpor aktuálního a očekávaného chování narazí, je potřeba jej nejdříve důkladně prošetřit, určit, zda se skutečně jedná o defekt a v případě, že ano, je nutné jej nahlásit.

Často se stává, že testeři ihned po nalezení anomálie zakládají defekt report, aniž by prověřili, zda se jedná o defekt v systému, nebo jen o chybně provedený test. Takové defekt reporty potom zbytečně zatěžují vývojáře, kteří se marně snaží defekt navodit a když zjistí, že problém je v testu, označí defekt report jako neplatný. Ano, defekty je třeba oznamovat co nejdříve, ale ne ledabyle. Pokud si tester nepřeje, aby byl vývojáři vnímán jako nespolehlivý, měl by se zastavit a než založí defekt report, měl by si nejprve odpovědět na následující čtyři otázky [Software testing help, 2008]:

1.    Co nefunguje?

2.    Proč to nefunguje?

3.    Jak zajistit, aby to fungovalo?

4.    Jaké jsou možné důvody selhání?

Tester by se měl snažit vypátrat příčinu selhání a poskytnout vývojářům veškerá východiska pro opravu defektu. Pokud je vývojářům jasné, v čem defekt spočívá a ve kterých místech systému a jak se selhání projevuje, budou mnohem ochotnější defekt opravit, než když musí ještě zjišťovat, při jaké situaci přesně selhání nastává. A cílem testera je, aby defekty byly opraveny.

Jako první je třeba vyloučit defekt či omyl na straně testovacího týmu. To znamená zkontrolovat, zda je korektně nastaveno testovací prostředí, zda jsou korektní parametry samotného testu a zda kroky testu byly skutečně provedeny tak, jak je požadováno.

Často se stává, že se tester na provádění testů plně nekoncentruje a neprovede vše tak, jak je požadováno v testovacím skriptu. Dospěje k jinému výsledku testu než k očekávanému a neví, zda se jedná o defekt. Zde je třeba být ostražitý, selhání se pokusit znovu nasimulovat a ubezpečit se, že se jednalo jen o omyl při provádění testu a že při korektním provedení testu systém reaguje správně.

Jinými příčinami selhání, které ve skutečnosti nejsou defektem, mohou být například chybějící konfigurační soubory, chybějící tabulky v databázi, chyby v automatizovaných skriptech, neplatné přihlašovací údaje, neplatná verze systému nebo nesplnění požadavků na hardware a software. [Software testing help, 2008]

Aby testeři předešli nevalidním defekt reportům a ztrátě důvěryhodnosti ze strany vývojářů, je dobré na tyto možné příčiny selhání pamatovat a důkladně prošetřit, zda se nejedná o jednu z nich.

Dalším problémem, na kterém závisí oprava defektu, je reprodukovatelnost selhání. Reprodukovatelnost znamená, že je možné popsat, jak se program dostane do známého stavu a potom každý, kdo je obeznámen s programem může podle tohoto popisu postupovat a dostane se do daného stavu taktéž [Kaner, 1993, s. 79]. Tester by se měl vždy snažit reportovat defekty tak, aby byly reprodukovatelné. Pokud jsou pro vývojáře nereprodukovatelné, raději jejich opravu odloží na později nebo je ignorují úplně.

Někdy však tester neví, co způsobilo selhání a jak přesně selhání navodit. Nedokáže ho navodit znovu, aby popsal kroky, které k selhání vedly. Je třeba vycházet z předpokladu, že každé selhání je ve skutečnosti reprodukovatelné a i když se objevuje zřídkakdy, vždy nastává za stejných podmínek. Úkolem testera je odhalit tyto podmínky, při kterých se selhání objevuje. V takové situaci je dobré si nejdříve sepsat, co všechno si tester pamatuje, že dělal, čím si je naprosto jistý a co jsou domněnky. Dále je třeba vzít do úvahy, co předcházelo sérii kroků vedoucích k selhání, včetně detailů. Pokud se stále nelze dopátrat příčiny selhání, je vhodné dále vzít v úvahu následující hypotézy [Kaner, 1993, s. 84-88]:

·      Při prvotním navození selhání byly kroky testu prováděny rychle, kdežto při snaze o znovunasimulování selhání byl test prováděn pomaleji.

·      Při provádění neskriptovaných testů se může snadno zapomenout na nějakou maličkost, kterou tester udělal a která je příčinou selhání.

·      Tester nedělal to, co si myslí, že dělal a dokud nezopakuje stejný omyl, kterého se dopustil poprvé, selhání znovu nenastane.

·      Selhání způsobí, že už není možné podruhé dospět do stejného stavu.

·      Selhání je závislé na dostupnosti paměti.

·      Selhání se může vyskytovat pouze před inicializací programu. Jakmile je program inicializován, selhání se přestane vyskytovat.

·      Program mohou poškodit přímo jeho vlastní data na disku nebo v paměti, resp. chybná data může do programu zadat tester.

·      Selhání může být vedlejším efektem ostatních problémů.

·      Selhání může být způsobeno chvilkovým selháním hardwaru.

·      Důvodem selhání mohou být časové závislosti jako například selhání pouze na přestupný rok nebo závislosti na zdrojích.

·      Omyl nemá okamžitý dopad, ale projeví se až za nějaký čas.

·      V kódu programu mohou být kritické podmínky, o kterých tester neví.

·      Mezitím, co se tester na chvíli vzdálil od počítače, mohl někdo zadat do programu nová data, vypnout tiskárnu, apod. 

Pokud ani tyto úvahy nestačí pro znovunavození selhání, potom je nutné defekt nahlásit jako nereprodukovatelný a snažit se ho přitom co nejpřesněji popsat. Nezbývá než doufat, že příčinu selhání vypátrá vývojář podle popisu.

Kromě potíží s reprodukovatelností defektů mohou testeři narazit také na komplikované defekty, kde k selhání vede dlouhá série kroků, nebo jejichž důsledky je těžké popsat. V těchto případech je třeba defekt report zjednodušit nebo ho rozdělit do více reportů. Cílem analýzy defektů je dle [Kaner, s. 79]:

·     nalézt nejzávažnější důsledky problému, které vzbudí zájem defekt opravit,

·     nalézt co možná nejjednodušší, nejkratší a nejobecnější podmínky, které vyvolají selhání,

·     nalézt alternativní cesty k navození stejného problému,

·     nalézt problémy s daným defektem související.

Jak má defekt report vypadat, je popsáno v pracovním produktu defekt report. Zde uvedené postupy a náměty pro analýzu a reportování defektů je třeba brát jako užitečné rady a nikoliv jako dogma. Je samozřejmé, že čím precizněji jsou defekt reporty zapsány, tím lépe se budou vývojářům opravovat. Tester má ovšem na provádění testů vyhrazen často velmi úzký časový limit, ve kterém musí stihnout projít mnoho testů. Kdyby každé nalezené selhání do detailu analyzoval, nezbyde mu čas na provedení ostatních testů. Je třeba se vyvarovat extrémům na jednu či druhou stranu a k analýze defektů přistupovat racionálně s ohledem na časová omezení testera. Pokud se například tester neorientuje dobře v logu aplikace, je efektivnější log pouze přiložit do defekt reportu, než aby tester trávil hodiny procházením logu a hledáním informace o selhání, kterou by vývojář našel během pěti minut.