Chyba není náhoda

Dnes bych chtěl jen velice stručně nakousnout téma identifikace a reportování chyb. K nahlášení chyby by nemělo stačit jen pouhé konstatování, že testovaná aplikace se chová jinak, než čekáme. Měli bychom být také schopni přesně popsat rozsah chyby. Provést vlastně jakousi lokalizaci chyby v aplikaci.

Existuje jeden strašák testerů a vývojářů. Jmenuje se náhodná chyba. Je to chyba, ke které prokazatelně dochází, ovšem nejsme schopní jednoznačně popsat vstupní podmínky a kroky vedoucí k této chybě. Kvůli tomu nejsme schopni ji ani ji v rozumné podobě reprodukovat. To představuje problém pro testera při hlášení takové chyby, vývojáře při jejím odstraňování a opět pro testera při retestu opravy této chyby. Stává se, že se podobné chyby neopraví, protože tester není schopný ji zreprodukovat a vývojář najít její zdroj a to přestože tato chyba prkazatelně nastala (a existuje o tom například důkaz v podbě logu).

Každopádně výskyt podobných chyb není příliš častý. Mnohem častějším problém je, že tester nedostatečným způsobem popíše chybu. Tím nemyslím to, že při reportování chyby v příslušném nástroji použije příliš málo slov. V okamžiku, kdy tester narazí na chování, které označí za chybné, měl by ještě před reportováním této chyby provést její lokalizaci. Měl by zkrátka toto chybné chování nějak ohraničit. V podstatě to znamená, že za použití známých testovacích technik najdu hodnotu, která vyvolá ještě validní chování, a zárověň za ní následuje hodnota, která vede k chování chybnému.

Dejem tomu, že budeme testovat import souboru do nějaké aplikace. Základní funkčnost si vyzkouším na nějakém malém souboru a následně to samé na souboru, který obsahuje reálná data (nebo data reálným odpovídající). Může se stát, že malý testovací soubor se importuje bez problémů ale import reálných dat vede k pádu.  To je pochopitelně chyba a já bych ji takto mohl nahlásit. Ovšem v tuto chvíli nevím přesně, proč pád nastal. Můžeme předpokládat, že za chybou je velikost souboru. V rámci průzkumu této chyby zkusíme velikost souboru s reálnými daty změnšovat (pokud je to možné, jinak můžeme naopak zvětšovat velikost našeho testovacího souboru) až do okamžiku, kdy najdeme předěl mezi správným a chybným chováním. Můžeme tak například zjistit, že nejde přímo o velikost souboru, ale o množství dat v souboru. Třeba se ukáže, že aplikace je schopná z nějakého důvodu zpracovat dejme tomu tisíc řádků a tisísícím prvním řádku spadne. Nebo naopak zjistíme, že problém vůbec nesouvisí s velikostí souboru. Může se ukázat, že soubor s reálnými daty obsahuje konkrétní záznam, který z určitého důvodu způsobuje pád testované aplikace.

Tento průzkum chyby není důležitý jen pro její opravu a další zpracování. Může se stát, že celý problém začíná už u testování. Tester například z nějakého důvodu očekává určité chování, ale aplikace se ve skuečnosti chová jinak. Tedy typická chyba. Jenže dlaším průzkumem se může ukázat, že tester pouze jinak pochopil zadání (analýzu, požadavek atd.) Případně může být chyba v použitých testovacích datech. Na to vše může tester přijít v okamžiku, kdy se pokouší chybu lokalizovat.

V okamžiku, kdy tester hlásí nalezenou chybu, musí především on sám vědět, v čem chyba spočívá. Musí být schopný ji reprodukovat a dodat vývojáři, který ji bude opravovat, případné další informace. Je tedy v jeho zájmu chybu prozkoumat.

 

Nejbližší události


Testování software, Powered by Joomla!; Joomla templates by SG web hosting