Egy időben hetente tartottunk bug scrub nevű rendezvényeket, ahol összeültek a projekt vezetői és elolvasták, majd priorizálták az adott időszakban riportolt bugokat. A probléma az volt, hogy aki vezette a meetinget és felolvasta a bugokat, az
- nem értett a termékhez,
- diszlexiás volt, nehezen értette meg a leírt szöveget.
Ott tanultam meg jól bugokat írni. Az a bug volt jól megírva, amit a terméket nem ismerő, diszlexiás igazgató is azonnal megértett. Ennek két titka volt:
- A description rész elején elhelyezett rövid, nagyon jól érthető indoklás
- Screenshot, amin a hibát nagy, piros ellipszissel jelöltem meg. Ha van pozitív ellenpélda, azt egy másik screenshoton nagy, zöld ellipszissel jelöltem meg.
A jó screenshot hasznosságát talán nem kell magyarázni, ahogy mondani szokták: egy kép többet mond ezer szónál. Ebben az esetben gyorsan és hatékonyan megmutatja, hogy pontosan hol és mivel van probléma.
Az indoklás rész már bonyolultabb. A Description kitöltése amúgy is mindenkinek gondot okoz, mert szabad szöveges mező, nincs a többi mezőre jellemző fogódzó, választási lehetőség. Mit kell oda írni egyáltalán? Steps to reproduce, Expected results, Actual result – ez a szentháromság, és a többség ezzel meg is elégszik.
A személyes felfedezésem az volt, hogy a bug életciklusában résztvevő minden kollégának (projektvezető, fejlesztők) segít, ha megindoklod, miért hiszed a riportolt jelenséget problémának. Leginkább az „impact” faktort érdemes körülírni:
- a jelenség kinek okoz problémát (végfelhasználónak > belsős adminisztrátornak > tesztelőknek)
- mekkora problémát okoz (anyagi vagy reputációs kár a cégnek > nehezíti az életet, de nem állítja meg > nem okoz gondot, de javíthatná a terméket)
- mekkora eséllyel, milyen gyakran fordul elő (élesben is jó eséllyel bekövetkezik > kicsi az előfordulás esélye > speciális esetben fordul elő)
Mert mindenki azt hiszi, hogy ha a mezőket alapszinten kitöltötte, az már elég, abból már mindenki másnak is értenie kell, hogy milyen súlyos problémát fedeztünk itt fel. A valóságban viszont mindenki más ellenérdekelt abban, hogy hibákat fedezzünk fel a termékben és azok javításával időt, energiát töltsünk. Éppen ezért, ha mégis el rá akarjuk venni a csapatot a hiba javítására, érdemes alaposan megindokolni, miért jelent ez a dolog problémát, miért lenne fontos mégiscsak kijavítani.