Proč dobré hlášení o chybě?

Je-li vaše hlášení o chybě efektivní, pak je větší šance, že bude opraveno. Oprava chyby tedy závisí na tom, jak efektivně ji nahlásíte. Nahlášení chyby není nic jiného než dovednost a já vám vysvětlím, jak této dovednosti dosáhnout.

„Smyslem psaní hlášení o problému (bug reportu) je, aby byly chyby opraveny.“ – Cem Kaner. Pokud tester nenahlásí chybu správně, programátor tuto chybu s největší pravděpodobností odmítne s tím, že je neopravitelná.

To může poškodit morálku testera a někdy i jeho ego. (Doporučuji nechovat si žádný typ ega. Ega typu „Nahlásil jsem chybu správně“, „Umím ji reprodukovat“, „Proč on/ona chybu odmítl/a?“, „Není to moje chyba“ atd.).

Jaké jsou vlastnosti dobrého hlášení o chybě softwaru?

Hlášení o chybě může napsat každý. Ale ne každý dokáže napsat efektivní hlášení o chybě.

Měli byste být schopni rozlišit mezi průměrným hlášením o chybě a dobrým hlášením o chybě. Jak rozlišit mezi dobrou a špatnou zprávou o chybě? Je to velmi jednoduché, při hlášení chyby použijte následující charakteristiky a techniky.

Mezi charakteristiky a techniky patří

#1) Mít jasně specifikované číslo chyby: Každému hlášení chyby vždy přiřaďte jedinečné číslo. To vám následně pomůže identifikovat záznam o chybě. Pokud používáte nějaký automatizovaný nástroj pro hlášení chyb, pak se toto jedinečné číslo vygeneruje automaticky pokaždé, když hlásíte chybu.

Poznamenejte si číslo a stručný popis každé nahlášené chyby.

#2) Reprodukovatelnost:

Měli byste jasně uvést kroky k reprodukci chyby. Nepředpokládejte ani nevynechávejte žádný krok reprodukce. Chybu, která je popsána krok za krokem, lze snadno reprodukovat a opravit.

#3) Buďte konkrétní:

Buďte konkrétní a věcní. Pokuste se shrnout problém v minimu slov, a přesto účinným způsobem. Nespojujte více problémů, i když se zdají být podobné. Pro každý problém napište jinou zprávu.

Efektivní hlášení chyb

Hlášení chyb je důležitým aspektem testování softwaru. Efektivní hlášení chyb dobře komunikuje s vývojovým týmem a zabraňuje zmatkům nebo nedorozuměním.

Dobré hlášení chyb by mělo být jasné a stručné, bez chybějících klíčových bodů. Jakákoli nejasnost vede k nedorozumění a také zpomaluje proces vývoje. Psaní a hlášení chyb je jednou z nejdůležitějších, ale opomíjených oblastí životního cyklu testování.

Dobrý písemný projev je pro podání chyby velmi důležitý. Nejdůležitějším bodem, který by měl mít tester na paměti, je nepoužívat v hlášení rozkazovací tón. To narušuje morálku a vytváří nezdravé pracovní vztahy. Používejte sugestivní tón.

Nepředpokládejte, že vývojář udělal chybu, a proto můžete použít ostrá slova. Před nahlášením je stejně důležité zkontrolovat, zda stejná chyba již nebyla nahlášena.

Duplicitní chyba je zátěží v testovacím cyklu. Zkontrolujte celý seznam známých chyb. Občas se může stát, že vývojáři o problému věděli a ignorovali ho pro budoucí vydání. Lze také použít nástroje jako Bugzilla, které automaticky vyhledávají duplicitní chyby. Nejlepší je však každou duplicitní chybu vyhledat ručně.

Důležité informace, které musí hlášení chyby sdělit, jsou „Jak?“ a „Kde?“. Zpráva by měla jasně odpovědět, jak byl test proveden a kde přesně se závada vyskytla. Čtenář by měl snadno reprodukovat chybu a najít, kde se chyba vyskytuje.

Mějte na paměti, že cílem psaní zprávy o chybě je umožnit vývojáři představit si problém. Z hlášení chyby by měl jasně pochopit, o jakou závadu se jedná. Nezapomeňte uvést všechny důležité informace, které vývojář hledá.

Také mějte na paměti, že hlášení o chybě by se uchovávalo pro budoucí použití a mělo by být dobře napsané s požadovanými informacemi. K popisu chyb používejte smysluplné věty a jednoduchá slova. Nepoužívejte matoucí výroky, které plýtvají časem recenzenta.

Každou chybu nahlaste jako samostatný problém. V případě více problémů v jednom hlášení chyby jej nemůžete uzavřít, dokud nejsou všechny problémy vyřešeny.

Proto je nejlepší rozdělit problémy na samostatné chyby. Tím zajistíte, že každou chybu bude možné řešit samostatně. Dobře napsané hlášení chyby pomáhá vývojáři reprodukovat chybu na svém terminálu. To jim pomůže problém také diagnostikovat.

Jak nahlásit chybu?

Použijte následující jednoduchou šablonu hlášení chyby:

Jedná se o jednoduchý formát hlášení chyby. Může se lišit v závislosti na nástroji pro hlášení chyb, který používáte. Pokud hlášení o chybě píšete ručně, pak je třeba některá pole uvést konkrétně, například číslo chyby, které by mělo být přiřazeno ručně.

Hlášení: Vaše jméno a e-mailová adresa.

Produkt:

Verze: V jakém produktu jste tuto chybu našli: Verze produktu, pokud existuje.

Komponenta:

Platforma: Jedná se o hlavní dílčí moduly produktu: Uveďte hardwarovou platformu, na které jste tuto chybu zjistili. Různé platformy jako „PC“, „MAC“, „HP“, „Sun“ atd.

Operační systém: Uveďte všechny operační systémy, ve kterých jste chybu našli. Operační systémy jako Windows, Linux, Unix, SunOS, Mac OS. Případně uveďte také různé verze operačních systémů, jako jsou Windows NT, Windows 2000, Windows XP atd.

Priorita: Kdy by měla být chyba opravena? Priorita se obecně stanovuje od P1 do P5. P1 jako „opravit chybu s nejvyšší prioritou“ a P5 jako „opravit, až to čas dovolí“.

Severity: Oprava chyby s nejvyšší prioritou se provádí podle priority: Popisuje dopad chyby.
Typy závažnosti:

• Blokující: Nelze provádět žádné další testovací práce.
• Kritický: V případě, že se jedná o závažný problém, je nutné jej odstranit:
• Závažný: Pád aplikace, ztráta dat:
• Menší: Ztráta funkce:
• Triviální: Některá vylepšení uživatelského rozhraní.
• Vylepšení:

Stav: Požadavek na novou funkci nebo nějaké vylepšení stávající funkce:

=> Klikněte sem a přečtěte si více o podrobném životním cyklu chyby.

Přiřadit k: Při záznamu chyby do jakéhokoli systému sledování chyb bude ve výchozím nastavení stav chyby „Nová“: Pokud víte, který vývojář je zodpovědný za daný modul, ve kterém se chyba vyskytla, můžete zadat e-mailovou adresu tohoto vývojáře. V opačném případě ponechte tuto položku prázdnou, protože tím bude chyba přiřazena vlastníkovi modulu, pokud ne, Správce chybu přiřadí vývojáři. Případně přidejte e-mailovou adresu správce do seznamu CC.

URL: Adresa URL stránky, na které se chyba vyskytla.

Summary: Stručné shrnutí chyby většinou v rozsahu 60 slov nebo méně. Ujistěte se, že vaše shrnutí odráží, v čem problém spočívá a kde se vyskytuje.

Popis: Podrobný popis chyby.

Pro pole popisu použijte následující pole:

• Reprodukovat kroky:
• Očekávaný výsledek:
• Skutečný výsledek: Jak by se měla aplikace chovat při výše uvedených krocích:

Toto jsou důležité kroky v hlášení chyby. Můžete také přidat „Typ hlášení“ jako další pole, které bude popisovat typ chyby.

Mezi typy hlášení patří:

1) Chyba kódování
2) Chyba návrhu
3) Nový návrh
4) Problém s dokumentací
5) Hardwarový problém

Důležité funkce v hlášení chyby

Níže jsou uvedeny důležité funkce v hlášení chyby:

#1) Číslo/id chyby

Číslo chyby nebo identifikační číslo (například swb001) usnadňuje hlášení chyby a odkazování na chybu. Vývojář může snadno zkontrolovat, zda byla konkrétní chyba opravena, nebo ne. Díky tomu je celý proces testování a opakovaného testování plynulejší a jednodušší.

#2) Název chyby

Název chyby se čte častěji než jakákoli jiná část hlášení chyby. Měl by říkat vše o tom, co v chybě přichází.

Název chyby by měl být dostatečně sugestivní, aby jej čtenář pochopil. Jasný název chyby usnadňuje pochopení a čtenář může vědět, zda byla chyba nahlášena již dříve nebo zda byla opravena.

#3) Priorita

Na základě závažnosti chyby lze pro ni stanovit prioritu. Chyba může být blokační, kritická, závažná, méně závažná, triviální nebo návrh. Lze zadat prioritu chyby od P1 do P5, aby se nejdříve zobrazily ty důležité.

#4) Platforma/prostředí

Pro přehledné hlášení chyby je nutná konfigurace operačního systému a prohlížeče. Je to nejlepší způsob, jak sdělit, jak lze chybu reprodukovat.

Bez přesné platformy nebo prostředí se aplikace může chovat jinak a chyba na straně testera se nemusí opakovat na straně vývojáře. Proto je nejlepší jasně uvést prostředí, ve kterém byla chyba zjištěna.

#5) Popis

Popis chyby pomáhá vývojáři chybu pochopit. Popisuje problém, který se vyskytl. Špatný popis způsobí zmatek a ztrátu času vývojářů a také testerů.

Je nutné jasně sdělit, jaký účinek má popis. Vždy je užitečné používat úplné věty. Dobrou praxí je popisovat každý problém zvlášť, místo abyste je drobili dohromady. Nepoužívejte výrazy jako „myslím si“ nebo „domnívám se“.

#6) Kroky k reprodukci

Dobrá zpráva o chybě by měla jasně uvádět kroky k reprodukci. Kroky by měly zahrnovat činnosti, které chybu způsobují. Nevytvářejte obecná prohlášení. Buďte konkrétní v krocích, které je třeba provést.

Dobrý příklad dobře napsaného postupu je uveden níže

Kroky:

• Vyberte produkt Abc01.
• Klikněte na Přidat do košíku.
• Kliknutím na Odebrat odeberte produkt z košíku.

#7) Očekávaný a skutečný výsledek

Popis chyby je neúplný bez uvedení očekávaných a skutečných výsledků. Je nutné nastínit, jaký je výsledek testu a co má uživatel očekávat. Čtenář by měl vědět, jaký je správný výsledek testu. Jasně uveďte, co se během testu stalo a jaký byl výsledek.

#8) Snímek obrazovky

Obrázek vydá za tisíc slov. Pořiďte snímek obrazovky případu selhání s patřičným popiskem, abyste na závadu upozornili. Neočekávaná chybová hlášení zvýrazněte světle červenou barvou. Tím upozorníte na požadovanou oblast.

Několik bonusových tipů, jak napsat dobré hlášení o chybě

Níže uvádíme několik dalších tipů, jak napsat dobré hlášení o chybě:

#1) Nahlaste problém okamžitě

Pokud při testování zjistíte nějakou chybu, nemusíte čekat s pozdějším psaním podrobného hlášení o chybě. Místo toho okamžitě napište hlášení o chybě. Tím zajistíte kvalitní a reprodukovatelné hlášení o chybě. Pokud se rozhodnete napsat hlášení o chybě později, pak je vysoká pravděpodobnost, že ve svém hlášení vynecháte důležité kroky.

#2) Před napsáním hlášení o chybě třikrát chybu reprodukujte

Vaše chyba by měla být reprodukovatelná. Ujistěte se, že vaše kroky jsou dostatečně robustní, abyste mohli chybu reprodukovat bez jakýchkoli nejasností. Pokud vaše chyba není pokaždé reprodukovatelná, můžete přesto podat hlášení chyby se zmínkou o periodické povaze chyby.

#3) Otestujte stejný výskyt chyby na jiných podobných modulech

Někdy vývojář použije stejný kód pro různé podobné moduly. Existuje tedy vyšší pravděpodobnost, že se chyba v jednom modulu vyskytne i v jiných podobných modulech. Můžete se dokonce pokusit najít závažnější verzi nalezené chyby.

#4) Napište dobrý souhrn chyby

Souhrn chyby pomůže vývojářům rychle analyzovat povahu chyby. Nekvalitní hlášení zbytečně prodlouží dobu vývoje a testování. Shrnutím hlášení o chybě dobře komunikujte. Mějte na paměti, že shrnutí chyby slouží jako odkaz pro vyhledání chyby v evidenci chyb.

#5) Před stisknutím tlačítka Odeslat si přečtěte hlášení chyby

Přečtěte si všechny věty, formulace a kroky, které jsou v hlášení chyby použity. Zjistěte, zda některá věta nevytváří nejasnosti, které by mohly vést k nesprávné interpretaci. Měli byste se vyhnout zavádějícím slovům nebo větám, aby bylo hlášení o chybě jasné.

#6) Nepoužívejte urážlivé výrazy

Je hezké, že jste odvedli dobrou práci a našli chybu, ale nepoužívejte tuto zásluhu ke kritice vývojáře nebo k napadání nějaké osoby.

Závěr

Není pochyb o tom, že vaše hlášení o chybě by mělo být kvalitním dokumentem.

Soustřeďte se na psaní dobrých hlášení o chybě a věnujte tomuto úkolu nějaký čas, protože je to hlavní bod komunikace mezi testerem, vývojářem a manažerem. Manažeři by měli ve svém týmu vytvořit povědomí o tom, že psaní dobrého hlášení o chybách je hlavní povinností každého testera.