Ako napísať efektívny bug report – hlásenie o chybách

Identifikácia chýb (angl. bug) je v procese testovania kľúčová. Keď nájdeš pri testovaní chybu, je nevyhnutné ju nahlásiť, aby mohla byť opravená. Napísanie hlásenia o chybe (bug report) je teda kľúčovou fázou životného cyklu chyby, ktorá prichádza hneď po jej identifikácii.

Čo je bug report – definícia

Keď sa v priebehu procesu zabezpečenia kvality zistí chyba (bug), musí sa zdokumentovať a poslať vývojárom na opravu. Vzhľadom na to, že softvér je v súčasnom digitálnom prostredí mimoriadne zložitý, viacvrstvový a plný funkcií, väčšina testovacích procesov generuje viacero chýb.

Okrem toho vývojári často pracujú na viacerých vývojových projektoch súčasne, čo znamená, že majú značný počet chýb, ktoré si vyžadujú pozornosť. Musia pracovať pod značným tlakom a bez správnych zdrojov môžu byť preťažení. IT testeri prirodzene trávia značný čas skúmaním toho, ako nahlásiť chybu spôsobom, ktorý je prínosom pre vývojárov a pomáha im odstraňovať chyby rýchlo a efektívne.

Jedným z týchto zdrojov sú dobre štruktúrované a primerane podrobné hlásenia chýb. Dobré hlásenia chýb vývojárom presne povedia, čo je potrebné opraviť a pomôžu im to urobiť rýchlejšie. Zabraňuje to oneskoreniu vydania softvéru a ponúka rýchlejší čas uvedenia na trh bez toho, aby sa znížila kvalita.

Výhody dobrého bug reportu

Dobre napísaný report o chybe obsahuje všetky dôležité informácie, ktoré možno použiť v procese debuggovania:

• Pomáha pri podrobnej analýze chyby.
• Poskytuje lepší prehľad o chybe a pomáha nájsť správny smer a prístup k ladeniu.
• Šetrí náklady a čas tým, že pomáha odstraňovať chyby v skoršej fáze.
• Zabraňuje tomu, aby sa chyby dostali do produkcie a narušili skúsenosti koncových používateľov.
• Funguje ako návod, ktorý pomáha vyhnúť sa rovnakej chybe v budúcich verziách.
• Informuje všetky zainteresované strany o chybe a pomáha im prijať nápravné opatrenia.

Elementy v dobre napísanom bug reporte

Pri štúdiu toho, ako vytvoriť naozaj dobrý report o chybe, začni otázkou: Čo má tento report developerovi povedať?

Správa o chybe by mala byť schopná odpovedať na nasledujúce otázky:

• V čom spočíva problém?
• Ako môže vývojár problém reprodukovať (aby sa o ňom presvedčil)?
• Kde v softvéri (na ktorej webovej stránke alebo v ktorej funkcii) sa problém objavil?
• Aké je prostredie (prehliadač, zariadenie, operačný systém), v ktorom sa problém vyskytol?

Ako napísať efektívny bug report

Efektívna správa o chybe by mala obsahovať:

• Názov/identifikátor chyby (Title/Bug ID)
• Prostredie (Environment)
• Kroky na reprodukciu chyby (Steps to reproduce a Bug)
• Očakávaný výsledok (Expected Result)
• Skutočný výsledok (Actual Result)
• Vizuálny dôkaz chyby – snímky obrazovky, videá, text (Visual Proof – screenshots, videos, text)
• Závažnosť/priorita (Severity/Priority)
• Logy z konzoly
• Ostatné polia

1.     Názov/identifikátor chyby

Názov by mal slúžiť ako stručné zhrnutie toho, o akú chybu ide. Názvy reportov začínajú problémom základnej funkcie v zátvorkách na samom začiatku názvu.  Priradenie ID chybe tiež pomáha uľahčiť jej identifikáciu. Napríklad: „[APP] Zväčšený text v časti FAQ na domovskej stránke <názov>“.

Zle: „Keď pridávam produkt, nevidím ho z nejakého dôvodu v košíku. PREČO? Opravte to čo najskôr.“

• nejasné
• agresívne
• žiada o implementáciu riešenia

2.     Prostredie a popis

Prostredie pre každú aplikáciu sa môže veľmi líšiť, ale buď čo najkonkrétnejší. Ak nie je uvedené inak, testeri by sa mali vždy riadiť danou šablónou hlásenia chyby – pomáha to obmedziť množstvo zbytočných informácií. . Chyba sa môže objaviť v určitom prostredí a v iných nie. Napríklad chyba sa objaví pri spustení webovej stránky vo Firefoxe alebo aplikácia nefunguje správne len pri spustení na iPhone X. Tieto chyby možno identifikovať len pomocou testovania naprieč prehliadačmi alebo testovania naprieč zariadeniami.

Pri nahlasovaní chyby musia testeri uviesť, či sa chyba vyskytuje v jednom alebo viacerých konkrétnych prostrediach. Na spresnenie použi nižšie uvedenú šablónu:

• Prostredie: DEV, TEST, PROD (produkčné prostredie), BETA
• Typ zariadenia: Hardvér a konkrétny model zariadenia
• OPERAČNÝ SYSTÉM: Názov a verzia operačného systému
• Verzia softvéru: Verzia testovaného softvéru, v ktorej sa chyba objavila.
• Sila spojenia: Ak chyba závisí od internetového pripojenia (4G, 3G, WiFi, Ethernet), uveď jeho silu na adrese v čase testovania.
• Miera reprodukcie: Počet opakovaní chyby s uvedením presných krokov pri každom opakovaní napr. 5/5.
• Použitý účet: Toto je dôležité, ak klient poskytne testerom testovacie účty. Najlepšie je potom v hlásení o probléme uviesť e-mail + heslo. Keď vývojári dostanú chybu, pochopia, ktorý účet bol použitý na odhalenie problému.

Zlý príklad: „Minule som sa snažil pridať veci do košíku a nič sa mi nezobrazilo, keď som to urobil alebo klikol na tlačidlo.“, „Text návrhu na stránke s cenami vyzerá zvláštne a nezdá sa byť správny. Nemal by byť tak veľký a mal by byť v inej farbe.“

3.     Kroky na reprodukciu chyby

Kroky jasne očísluj od prvého po posledný, aby ich vývojári mohli rýchlo a presne dodržať a sami si chybu overiť. Tu je príklad, ako sa dá chyba reprodukovať v krokoch:

• Prejdi do nastavení > Profil (používateľ sa tak dostane na novú obrazovku)
• Klepni na Ďalšie možnosti > Odstrániť účet

4.     Očakávaný výsledok

Táto zložka správy o chybe opisuje, ako má softvér fungovať v danom scenári. Vývojár sa z očakávaných výsledkov dozvie, aká je požiadavka. Pomôže mu to posúdiť, do akej miery chyba narúša používateľský zážitok.

Opíš ideálny scenár koncového používateľa a snaž sa poskytnúť čo najviac podrobností. V prípade uvedeného príkladu by mal byť očakávaný výsledok takýto:

„Váš účet bol odstránený.“

5.     Skutočný výsledok

Podrobne opíš, čo chyba v skutočnosti robí a ako skresľuje očakávaný výsledok.

• Rozpracuj problém
• Dochádza k pádu softvéru?
• Je to len pozastavenie činnosti?
• Objavuje sa chyba?
• Alebo jednoducho nereaguje?

Konkrétnosť v tejto časti bude vývojárom najviac nápomocná. Výrazne zdôrazni, čo sa deje zle. Uveď ďalšie podrobnosti, aby mohli začať skúmať problém s ohľadom na všetky premenné, ako napr:

• „Odkaz nevedie na očakávanú stránku. Zobrazuje chybu 404.“
• „Po kliknutí na tlačidlo sa vôbec nič nedeje.“
• „Hlavný obrázok na domovskej stránke je na konkrétnej kombinácii zariadenia a prehliadača skreslený.“

Pokračujúc vo vyššie uvedenom príklade bude skutočný výsledok v prípade chyby takýto

„Síce je odstránenie účtu potvrdené, je možné sa s ním opätovne prihlásiť bez registrácie.“

6.     Vizuálny dôkaz chyby

Je potrebné pripojiť všetky relevantné snímky obrazovky, videá alebo súbory. Ak si problém vyžaduje kroky na spustenie chyby, vyžaduje sa video. Ak je chyba napríklad drobný problém s používateľským rozhraním, ktorý je prítomný vždy, potom postačí snímka obrazovky. Bez ohľadu na problém sa vyžadujú aj protokoly.

V prípade pádov aplikácií sa vyžadujú systémové protokoly aj výpisy protokolov o páde, inak vývojári budú hľadať ihlu v kope sena. Pri testovaní pomocou aplikácie BrowserStack možno využiť viaceré možnosti debuggovania, ako sú textové protokoly, vizuálne protokoly (snímky obrazovky), videozáznamy, konzolové protokoly a sieťové protokoly.

Rozsah debugovacích nástrojov, ktoré ponúkajú produkty na testovanie mobilných aplikácií a webových stránok spoločnosti BrowserStack, je nasledovný:

• Live: Predinštalované vývojárske nástroje na všetkých vzdialených desktopových prehliadačoch a vývojárske nástroje Chrome na skutočných mobilných zariadeniach.
• Automate: Snímky obrazovky, nahrávanie videí, synchronizácia videozáznamov, textové protokoly, sieťové protokoly, protokoly Selenium, konzolové protokoly
• App Live: Logy zariadení v reálnom čase z aplikácie Logcat alebo konzoly
• App Automate: screenshoty, nahrávanie videa, textové logy, sieťové logy, Appium logy, logy zo zariadenia…

7.     Závažnosť chyby

Každej chybe musí byť priradená úroveň závažnosti a zodpovedajúca priorita. Tým sa zistí, do akej miery chyba ovplyvňuje systém a následne, ako rýchlo ju treba opraviť.

Úrovne závažnosti chyby:

• Nízka (Low): Chyba nebude mať za následok žiadne viditeľné zlyhanie systému.
• Malá (Minor): Má za následok určité neočakávané alebo nežiaduce správanie, ale nie natoľko, aby narušilo funkciu systému.
• Závažné (Major): Chyba, ktorá môže spôsobiť kolaps veľkých častí systému.
• Kritický (Critical): Chyba schopná vyvolať úplné zlyhanie systému.

Úrovne priority chyby:

• Nízka (Low): Chyba môže byť opravená neskôr. Iné, závažnejšie chyby majú prioritu.
• Stredná (Medium): Chybu je možné opraviť v priebehu bežného vývoja a testovania.
• Vysoká (High): Chyba sa musí vyriešiť čo najskôr, pretože negatívne ovplyvňuje systém a spôsobuje, že až do jej odstránenia je nepoužiteľný.

8.     Logy z konzoly

Tieto protokoly zobrazujú vývojárom všetky chyby, ktoré sa vyskytli na danej webovej stránke. Protokoly môžu obsahovať aj informácie, ktoré sledujú určité akcie používateľov. Vo všeobecnosti môže byť pre vývojárov zahrnutie konzolových protokolov užitočné, pretože im to môže pomôcť hlbšie preniknúť do problému a identifikovať jeho príčinu. Pri debuggovaní im to ušetrí množstvo času pri akomkoľvek probléme. Mnohé pády aplikácie alebo chyby sa ťažko replikujú, takže mať k dispozícii protokoly môže byť poľahčujúce.

9.     Ostatné polia

Vady nie sú statické. Ani sa len tak všetky nezaradia do jednej neprehľadnej skupiny. Potrebujeme spôsob, ako sledovať históriu (kto problém nahlásil, kto ho aktualizoval, kto ho bude opravovať atď.) Potrebujeme tiež spôsob, ako pochopiť, akých oblastí funkcií sa táto chyba týka (funkčná oblasť, modul, oblasť podnikania atď.). Preto chyby môžu mať a majú nasledujúce ďalšie dátové polia:

• Reported By (nahlásil)
• Dátum nahlásenia
• Priradené
• Stav
• Modul/oblasť činnosti

Tieto polia pomáhajú pri sledovaní závady v rôznych fázach a stavoch, aby sme ju mohli ľahko aktualizovať. Celý tento proces sa označuje aj ako životný cyklus chyby alebo defektu. Veľké tímy používajú rôzne druhy softvéru na správu chýb, aby tento proces uľahčili a zefektívnili.

Bug report – najlepšie postupy a tipy

Vo všeobecnosti je dobré mať na pamäti tieto základné pokyny:

• Jedna chyba = jeden problém. Nezahŕňaj viacero chýb do jedného reportu!
• Vyhni sa duplicitám. Vždy sa snaž vyhľadávať v aktuálnom nástroji na sledovanie problémov existujúce hlásenia.
• Pred vytvorením hlásenia o chybe ju zreprodukuj. Je tak väčšia pravdepodobnosť, že vývojár bude schopný problém aj reprodukovať a identifikovať, odkiaľ pochádza.
• Nezabúdaj na KISS: keep it stupid simple. Udržuj všetko čo najjednoduchšie. Pomôcť ti môže používanie odrážok alebo očíslovaných zoznamov.
• Používaj profesionálny nástroj na sledovanie chýb. Pomôže ti to mať všetko na jednom mieste a vyhneš sa strate súborov a hlásení o chybách.
• Buď láskavý. Aj vývojári sú ľudia a chyby sa stávajú. Sú súčasťou procesu tvorby skvelých konečných produktov a webových stránok.

Testovanie na zariadeniach

Netreba dodávať, že bez testovania na skutočných zariadeniach nie je možné odhaliť všetky možné chyby. Okrem toho je potrebné vedieť, ako často sa chyba vyskytuje a aký je jej vplyv na softvér. Testeri nemôžu nahlasovať chyby, ktoré počas testov nezachytili.

Najlepší spôsob, ako odhaliť všetky chyby, je spustiť softvér v reálnych zariadeniach a prehliadačoch. Zabezpeč, aby bol softvér spustený prostredníctvom manuálneho testovania aj automatizovaného testovania. Automatizované testovanie Selenium by malo dopĺňať manuálne testy, aby testeri v procese zabezpečenia kvality neprehliadli žiadne chyby.

Ak nemáš k dispozícii vlastné laboratórium zariadení, najlepšou možnosťou je zvoliť si cloudovú službu testovania, ktorá poskytuje reálne prehliadače zariadení a operačné systémy. Služba BrowserStack ponúka viac ako 2000 reálnych prehliadačov a zariadení na manuálne a automatizované testovanie. Používatelia sa môžu zaregistrovať, vybrať si požadované kombinácie zariadení, prehliadačov a operačných systémov a začať testovať.

To isté platí aj pre aplikácie. BrowserStack ponúka aj skutočné zariadenia na testovanie mobilných aplikácií a automatizované testovanie aplikácií. Stačí nahrať aplikáciu do požadovanej kombinácie zariadenie-OS a skontrolovať, ako funguje v reálnom svete.

Ak vieš po nemecky a si IT tester alebo automatizovaný tester, pozri si naše firemné benefity a reaguj na voľné pracovné miesta.

O autorovi

Michaela Kojnoková

Agile Test Engineer

Po štúdiu informatiky na ŽU a TUKE som sa najviac ponorila do oblasti automatizácie testovania. Okrem toho sa venujem tvorbe webov, databázam, dátovej analytike, umelej inteligencii a strojovému učeniu. Mám rada cestovanie, šport a najviac si užívam čas strávený v prírode s mojimi blízkymi. LinkedIn