Jak hlásit chybu
Hodnocení uživatelů: / 0
NejhoršíNejlepší 

Způsob, jakým tester hlásí nalezené chyby se liší projekt od projektu, firma od firmy, tester od testera. Přesto bych tu rád uvedl pár základních pravidel, která se mi osvědčila.

Především si musíme říct, že podoba a formát nahlášené chyby zásadním způsobem záleží na použité metodice, použitém nástroji a v neposlední řadě interní domluvě v týmu. Nahlášená chyba by měla obsahovat některé základní informace, které můžeme označit za povinné. Jinak řečeno, tyto údaje nalezneme u většiny chyb napříč projekty, firmami, týmy.

Název (titul, předmět, summary atd.) 

Většina nástrojů, se kterými jsem pracoval, umožňuje (nebo spíše vyžaduje) pojmenování chyby. Název má sloužit k rychlé orientaci v přehledech chyb a obvykle je přes tuto hodnotu prováděno i hledání a filtrování. 

Já do názvu obvykle vložím základní údaje, které danou chybu jednoznačně identifikují ve vztahu k testované funkčnosti a použitým datům. Do názvu tak vkládám na prvním místě identifikaci testu, v rámci kterého byla chyba nalezena. Buď v podobě číselného označení Test Casu (v případě, že vývojář má k přístup k testovací dokumentaci), Use Casu nebo slovní označení testované oblasti (například Vytváření nového záznamu). 

Pokud daný test existuje ve více variantách lišících se vstupními daty, je vhodné použitá testovací data uvést i v názvu chyby. Opět možné formou číselné identifikace nějakého souboru s testovacími daty, případně slovně (například Zákazník-Fyzická osoba).

Následovat by mělo stručné pojmenování chyby. Celkově by název neměl být moc dlouhý (bugtrackingové nástroje obvykle ani dlouhé názvy neumožňují), ale mělo by z ně být jasné, čeho se chyba týká. Můžu například chybu popsat jako Chyba validace pole Datum narození. Samozřejmě při větším počtu podobných chyb je vhodnější popsat chybu podrobněji, aby nedocházelo k jejich záměně.

Závažnost (severita, důležitost atd.)

Důležitý údaj, který by měl být zohledněn při opravách chyb (závažnější chyby mají přednost) a který hraje důležitou roli při vyhodnocení výsledků testů. Právě počet chyb určité závažnosti je obvykle kritériem pro ukončení jedné fáze testů a postoupení do fáze další.

Klíč, podle kterého se chyby označují stupněm závažnosti, by měl být vytvořen již před začátkem testů. Stupnice závažností chyb muže mít různou "hrubost" v závislosti na nastavení projektu. Základní stupně se ale vesměs opakují. Chyby tak můžeme většinou označit za Blokující další práci, Velmi závažné, Málo závažné a Triviální. Samozřejmě pojmenování jednotlivých stupňů závažnosti je věc maximálně proměnlivá a tvořivosti se meze nekladou.

Popis chyby 

Popis chyby je logicky tím nejdůležitějším, co nahlášená chyba obsahuje. Jeho úkolem je co nepřesněji popsat okolnosti, které k vyvolání dané chyby vedou. A samozřejmě také popsat chybu samotnou. Tedy spíše naopak, nejprve popsat chybu následně a způsob, jak jí dosáhnout.

Popsat chybu neznamená jen uvést, jaké je chování aplikace, které tester považuje za chybné. Důležité je také říci, jaké bylo očekávané chování, kterého mělo být v rámci testu dosaženo. Popis chybného chování je vhodné doložit textem případné chybové hlášky z aplikace.

Popis chyby by měl obsahovat také všechny informace, které jsou nezbytné pro reprodukci chyby. Mezi tyto informace řadíme:

Testovací prostředí - v případě, že existuje víc prostředí, musí být zřejmé, na kterém z nich test proběhl

Verze aplikace - tento údaj má smysl v okamžiku, kdy testování není prováděno na "zmražené" verzi aplikace. Myslím tím situaci, kdy i v době testů dochází na aplikaci k vývoji nebo jsou průběžně opravovány chyby. V případě vícekolových testů je možné s pomocí označení verze aplikace identifikovat, v rámci kterého releasu byla chyba do aplikace "zavlečena".

Místo výskytu - není úplně nezbytný údaj, pokud je chyba dostatečně dobře popsaná. Pro upřesnění je ale někdy dobré uvést zde například název formuláře, označení funkčnosti, identifikaci rozhraní a podobně. 

Testovací data - což je trochu široký pojem. Jako testovací data můžeme na jedné straně označit Konfiguraci aplikace, kterou pro testování použijeme, ale na straně druhé jde samozřejmě o data, která používáme přímo na vstupu při testu. I tato data můžeme dále rozdělit - existují data, která jsou nutná pro spuštění testu, ale nejsou přímou podstatou chyby. Například některé testy vyžadují přihlášení do aplikace pod určitým typem uživatele. Tento uživatel musí v aplikaci existovat ještě před spuštěním testu a chyba nalezené v průběhu testu může, ale nemusí mít souvislost právě s použitým uživatelem a jeho nastavením. A posledním, a možná nejdůležitějším, typem testovacích dat jsou samozřejmě ta data, která jsem použil jako vstup při testu, ve kterém nastala chyba.

Abych tu do problému testovacích dat zbytečně nezabředával, mělo by být jasné toto - jakákoli relevantní testovací data (ať už konfigurační, data nutná pro spuštění testu a vstupní data) by měla být při hlášení chyby uvedena.

Kroky nutné k reprodukci chyby - je docela dobrý nápad v nějaké přehlednější podobě popsat kroky, které je nutné udělat, aby se v aplikaci chybné chování projevilo. Může jít o čistě bodový seznam jednotlivých činností. Pokud je testovací dokumentace dostatečně dobře připravená, je možné použít sled kroků z ní. Případně je možné se na tuto dokumentaci pouze odkázat (pokud je vývojářům přístupná).

Použité nástroje - pokud nějaké použité byly. U webových aplikací je použit minimálně webový prohlížeč. Je vhodné uvést jeho typ a verzi.

Lokální nastavení - některé chyby mohou být důsledkem konkrétního nastavení na počítači, na kterém jsou testy prováděny. Pro jejich identifikaci je vhodné uvádět právě lokální nastavení tohoto počítače.

Přílohy

Přílohy tvoří důležitou část při hlášení chyby. Mnoho "důkazů" o chybném chování aplikace má takovou podobu, že není možné je jednoduše převést na text. Proto by měly být k hlášené chybě přidány ve formě příloh. Jako přílohy je vhodné vkládat například:

Logy - důležitá příloha. Pokud je logování dobře uděláno má právě log mnohem lepší vypovídací schopnost než jakýkoli testerský popis.  

Screenshoty - u chyb, které mají nějaký GUI projev (nebo přímo chyby v GUI) je to nezbytnost. V ostatních případech je snímek obrazovky spíše jakýmsi důkazem, že si tester danou situaci nevymyslel a skutečně nastala. U webových aplikací je kromě zachycení samotného chybného chování vhodné zachytit také celkový pohled na okno prohlížeče, protože je to jednak důkaz o použitém prohlížeči, ale při zobrazení adresového řádku je možné doložit i použité testovací prostředí.

Vstupní soubory - v případě, že vstupem do testu je nějaký soubor. Vložení vstupních souboru jednak usnadňuje reprodukci chyby, ale umožňuje také odhalit případnou chyby na úrovni vstupních dat (tedy chybu přímo ve vstupním souboru).

 

Nejbližší události


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