Hogyan írjunk jó hibajelentést? Tippek és trükkök

szept 30, 2021
admin

Miért jó hibajelentés?

Ha a hibajelentésed hatékony, akkor nagyobb az esélye, hogy kijavítják. A hiba kijavítása tehát attól függ, hogy mennyire hatékonyan jelented a hibát. A hibajelentés nem más, mint készség, és elmagyarázom, hogyan lehet elérni ezt a készséget.

“A problémajelentés (hibajelentés) írásának lényege, hogy a hibákat kijavítsák.” – Cem Kaner. Ha egy tesztelő nem megfelelően jelent egy hibát, a programozó nagy valószínűséggel elutasítja ezt a hibát, mondván, hogy nem reprodukálható.

Hogyan írjunk jó hibajelentést

Ez sértheti a tesztelő erkölcsét és néha az egóját is. (Javaslom, hogy ne tartsunk fenn semmiféle egót. Az olyan egókat, mint “Helyesen jelentettem a hibát”, “Tudom reprodukálni”, “Miért utasította el a hibát?”, “Nem az én hibám” stb.,).

Melyek a jó szoftverhibajelentés tulajdonságai?

Bárki tud hibajelentést írni. De nem mindenki tud hatékony hibajelentést írni.

Meg kell tudnia különböztetni egy átlagos hibajelentést egy jó hibajelentéstől. Hogyan lehet különbséget tenni egy jó és egy rossz hibajelentés között? Nagyon egyszerű, alkalmazza a következő jellemzőket és technikákat a hibajelentéshez.

A jellemzők és technikák a következők

#1) Egyértelműen meghatározott hibaszámmal rendelkezik: Mindig rendeljen egyedi számot minden egyes hibajelentéshez. Ez viszont segít a hibajegyzék azonosításában. Ha bármilyen automatizált hibabejelentő eszközt használ, akkor ez az egyedi szám minden alkalommal automatikusan generálódik, miközben a hibát jelenti.

Jegyezze fel a számot és minden egyes bejelentett hiba rövid leírását.

#2) Reprodukálhatóság: Ha a hiba nem reprodukálható, akkor soha nem lesz javítva.

Egyértelműen meg kell említenie a hiba reprodukálásának lépéseit. Ne feltételezz vagy hagyj ki egyetlen reprodukálási lépést sem. Egy lépésről lépésre leírt hiba könnyen reprodukálható és javítható.

#3) Légy konkrét: Ne írjon esszét a problémáról.

Legyen konkrét és lényegre törő. Próbálja meg minimális szavakkal, mégis hatásosan összefoglalni a problémát. Ne kombinálj több problémát, még akkor sem, ha hasonlónak tűnnek. Minden egyes problémáról írjon külön jelentést.

Effektív hibajelentés

A hibajelentés a szoftvertesztelés fontos aspektusa. A hatékony hibajelentés jól kommunikál a fejlesztőcsapattal, és elkerüli a zavart vagy félreértést.

A jó hibajelentésnek világosnak és tömörnek kell lennie, anélkül, hogy hiányoznának a kulcspontok. Az egyértelműség hiánya félreértésekhez vezet, és lelassítja a fejlesztési folyamatot is. A hiba megírása és jelentése az egyik legfontosabb, de elhanyagolt terület a tesztelési életciklusban.

A jó írás nagyon fontos a hiba bejelentéséhez. A legfontosabb pont, amit egy tesztelőnek szem előtt kell tartania, hogy ne használjon parancsoló hangnemet a jelentésben. Ez megtöri a morált és egészségtelen munkakapcsolatot teremt. Használjon szuggesztív hangnemet.

Ne feltételezze, hogy a fejlesztő hibázott, és ezért használhat durva szavakat. A jelentés előtt ugyanilyen fontos ellenőrizni, hogy ugyanazt a hibát jelentették-e már vagy sem.

A duplikált hiba teher a tesztelési ciklusban. Ellenőrizze az ismert hibák teljes listáját. Előfordulhat, hogy a fejlesztők már ismerték a problémát, és egy későbbi kiadásnál figyelmen kívül hagyták. Az olyan eszközök, mint a Bugzilla, amelyek automatikusan keresik a duplikált hibákat, szintén használhatók. A legjobb azonban, ha kézzel keressük meg a duplikált hibákat.

A hibajelentésnek a “Hogyan?” és a “Hol?” fontos információkat kell közölnie. A jelentésnek egyértelműen választ kell adnia arra, hogy a tesztet hogyan hajtották végre, és hogy a hiba pontosan hol keletkezett. Az olvasónak könnyen reprodukálnia kell a hibát, és meg kell találnia, hogy hol van a hiba.

Tartsuk szem előtt, hogy a hibajelentés megírásának célja, hogy a fejlesztő képet kapjon a problémáról. A hibajelentésből világosan meg kell értenie a hibát. Ne feledje, hogy minden lényeges információt megadjon, amit a fejlesztő keres.

Azt is tartsa szem előtt, hogy a hibajelentés megmarad a későbbi felhasználásra, és jól meg kell írni a szükséges információkkal. Használjon értelmes mondatokat és egyszerű szavakat a hibák leírásához. Ne használjon zavaros kijelentéseket, amelyek a bíráló idejét pazarolják.

Minden hibát külön problémaként jelentsen be. Abban az esetben, ha egy hibajelentésen belül több probléma van, azt csak akkor zárhatja le, ha az összes probléma megoldódott.

Ezért a legjobb, ha a problémákat külön hibákra bontja. Ez biztosítja, hogy minden egyes hiba külön kezelhető legyen. Egy jól megírt hibajelentés segít a fejlesztőnek reprodukálni a hibát a saját terminálján. Ez segít nekik a probléma diagnosztizálásában is.

Hogyan kell hibát jelenteni?

A következő egyszerű hibajelentéssablont használja:

Ez egy egyszerű hibajelentés formátum. Az Ön által használt hibajelentő eszköztől függően változhat. Ha kézzel írja a hibajelentést, akkor néhány mezőt külön meg kell említeni, például a hibaszámot, amelyet kézzel kell hozzárendelni.

Riporter: Az Ön neve és e-mail címe.

Termék:

Version: A termék verziója, ha van.

Komponens:

Platform: Említse meg a hardverplatformot, ahol ezt a hibát találta. A különböző platformok, mint például ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ stb.

Operációs rendszer: Említse meg az összes operációs rendszert, ahol a hibát megtalálta. Olyan operációs rendszerek, mint a Windows, Linux, Unix, SunOS, Mac OS. Adott esetben említse meg a különböző operációs rendszerek verzióit is, például Windows NT, Windows 2000, Windows XP stb.

Prioritás: Mikor kell a hibát kijavítani? A prioritás általában P1-től P5-ig terjed. A P1 a “javítsuk ki a legmagasabb prioritású hibát”, a P5 pedig a ” Javítsuk ki, ha az idő engedi”.

Súlyosság: Ez a hiba hatását írja le.
Súlyossági típusok:

  • Blokkoló: További tesztelési munka nem végezhető.
  • Kritikus:
  • Súlyos:
  • Minor: Kisebb funkcióvesztés.
  • Triviális: Néhány UI javítás.
  • Fejlesztés: Új funkcióra vagy a meglévő funkció némi javítására irányuló kérés.

Státusz:
Később a hiba különböző szakaszokon megy keresztül, mint például Javítva, Ellenőrzött, Újranyitva, Nem javítjuk, stb.

=> Kattintson ide, ha többet szeretne megtudni a részletes hibaéletciklusról.

Assign To: Ha tudja, hogy melyik fejlesztő felelős azért az adott modulért, amelyben a hiba előfordult, akkor megadhatja annak a fejlesztőnek az e-mail címét. Ellenkező esetben hagyja üresen, mivel ez a hibát a modul tulajdonosához rendeli, ha nem, akkor az Ügyintéző a fejlesztőhöz rendeli a hibát. Esetleg adja hozzá a CC-listához a menedzser e-mail címét.

URL: Az oldal URL címe, amelyen a hiba előfordult.

Summary: A hiba rövid összefoglalása, többnyire 60 szóban vagy annál rövidebben. Ügyeljen arra, hogy az összefoglaló tükrözze, hogy mi a probléma és hol van.

Description: A hiba részletes leírása.

A leírás mezőhöz a következő mezőket használja:

  • Reprodukciós lépések: Világosan említse meg a hiba reprodukálásának lépéseit.
  • Várható eredmény: Hogyan kellene viselkednie az alkalmazásnak a fent említett lépések esetén.
  • Tényleges eredmény: Mi a tényleges eredménye a fenti lépések futtatásának, azaz a hiba viselkedésének.

Ezek a hibajelentés fontos lépései. A “Jelentés típusa” mezőt is hozzáadhatja egy további mezőként, amely a hiba típusát írja le.

A jelentés típusai a következők:

1) Kódolási hiba
2) Tervezési hiba
3) Új javaslat
4) Dokumentációs probléma
5) Hardverprobléma

Fontos jellemzők a hibajelentésedben

A következőkben a hibajelentés fontos jellemzői szerepelnek:

#1) Hibaszám/id

A hibaszám vagy egy azonosító szám (például swb001) megkönnyíti a hibabejelentést és a hibára való hivatkozást. A fejlesztő könnyen ellenőrizheti, hogy egy adott hibát kijavítottak-e vagy sem. Ez gördülékenyebbé és könnyebbé teszi az egész tesztelési és újratesztelési folyamatot.

#2) A hiba címe

A hiba címét gyakrabban olvassák el, mint a hibajelentés bármely más részét. Mindent el kell mondania arról, hogy mi jön a hibában.

A hiba címének elég szuggesztívnek kell lennie ahhoz, hogy az olvasó megértse. Egy világos hibacím könnyen érthetővé teszi a hibát, és az olvasó tudhatja, hogy a hibát korábban már jelentették-e, vagy javították-e már.

#3) Prioritás

A hiba súlyossága alapján lehet prioritást adni a hibának. Egy hiba lehet Blocker, Critical, Major, Minor, Trivial vagy javaslat. A hiba prioritása P1-től P5-ig adható meg, így a fontos hibákat tekintik meg először.

#4) Platform/Környezet

A hibabejelentés egyértelműségéhez szükséges az operációs rendszer és a böngésző konfigurációja. Ez a legjobb módja annak, hogy közöljük, hogyan reprodukálható a hiba.

A pontos platform vagy környezet nélkül az alkalmazás másképp viselkedhet, és a tesztelőnél lévő hiba nem biztos, hogy megismétlődik a fejlesztőnél. Ezért a legjobb, ha egyértelműen megemlítjük a környezetet, amelyben a hibát észleltük.

#5) Leírás

A hiba leírása segít a fejlesztőnek a hiba megértésében. Leírja a felmerült problémát. A rossz leírás zavart okoz, és a fejlesztők és a tesztelők idejét is pazarolja.

A leírás hatásáról világosan kell kommunikálni. Mindig hasznos teljes mondatokat használni. Jó gyakorlat, ha minden egyes problémát külön-külön írunk le ahelyett, hogy összemorzsoljuk őket. Ne használjon olyan kifejezéseket, mint “azt hiszem” vagy “azt hiszem”.

#6) A reprodukálás lépései

A jó hibajelentésnek egyértelműen meg kell említenie a reprodukálás lépéseit. A lépéseknek tartalmazniuk kell a hibát okozó műveleteket. Ne tegyen általános kijelentéseket. Legyen konkrét a követendő lépésekben.

Egy jól megírt eljárásra jó példa az alábbiakban

Lépések:

  • Válassza ki az Abc01 terméket.
  • Kattintson a Kosárba helyezés gombra.
  • Kattintson az Eltávolítás gombra a termék kosárból való eltávolításához.

#7) Várható és tényleges eredmény

Egy hibaleírás nem teljes a várt és tényleges eredmények nélkül. Szükséges felvázolni, hogy mi a teszt eredménye, és mire számíthat a felhasználó. Az olvasónak tudnia kell, hogy mi a teszt helyes eredménye. Világosan említse meg, hogy mi történt a teszt során, és mi volt az eredmény.

#8) Pillanatkép

Egy kép többet ér ezer szónál. Készítsen képernyőfotót a hiba esetéről megfelelő felirattal, hogy kiemelje a hibát. Világosvörös színnel emelje ki a váratlan hibaüzeneteket. Ez felhívja a figyelmet a szükséges területre.

Néhány bónusz tipp a jó hibajelentés megírásához

Az alábbiakban további tippeket adunk a jó hibajelentés megírásához:

#1) Jelentse a problémát azonnal

Ha tesztelés közben talál bármilyen hibát, akkor nem kell várnia, hogy később részletes hibajelentést írjon. Ehelyett azonnal írd meg a hibajelentést. Ez biztosítja a jó és reprodukálható hibajelentést. Ha úgy dönt, hogy később írja meg a hibajelentést, akkor nagy az esélye, hogy kihagyja a fontos lépéseket a jelentésben.

#2) Reprodukálja a hibát háromszor, mielőtt megírja a hibajelentést

A hibának reprodukálhatónak kell lennie. Győződj meg róla, hogy a lépéseid elég robusztusak ahhoz, hogy a hibát félreérthetetlenül reprodukáld. Ha a hibád nem reprodukálható minden alkalommal, akkor is írhatsz hibabejelentést, megemlítve a hiba időszakos jellegét.

#3) Teszteld ugyanazt a hibaelőfordulást más hasonló modulokon

Néha a fejlesztő ugyanazt a kódot használja különböző hasonló modulokhoz. Így nagyobb az esélye annak, hogy az egyik modulban lévő hiba más hasonló modulokban is előfordul. Megpróbálhatod akár a megtalált hiba súlyosabb változatát is megkeresni.

#4) Írj egy jó hibaösszefoglalót

A hibaösszefoglaló segít a fejlesztőknek a hiba természetének gyors elemzésében. Egy rossz minőségű jelentés szükségtelenül megnöveli a fejlesztési és tesztelési időt. Kommunikáljon jól a hibajelentés összefoglalójával. Tartsa szem előtt, hogy a hibaösszefoglalót referenciaként használják a hiba kereséséhez a hibaleltárban.

#5) Olvassa el a hibajelentést, mielőtt megnyomja a Küldés gombot

Olvassa el az összes mondatot, megfogalmazást és lépést, amelyet a hibajelentésben használ. Nézd meg, hogy valamelyik mondat nem okoz-e kétértelműséget, ami félreértelmezéshez vezethet. A félrevezető szavakat vagy mondatokat kerülni kell a világos hibajelentés érdekében.

#6) Ne használjon gyalázkodó kifejezéseket

Szép, hogy jó munkát végzett és talált egy hibát, de ne használja ezt az elismerést a fejlesztő kritizálására vagy bármely személy támadására.

Következtetés

Kétségtelen, hogy a hibajelentésednek minőségi dokumentumnak kell lennie.

Fókuszálj a jó hibajelentések megírására, és fordíts egy kis időt erre a feladatra, mert ez a fő kommunikációs pont a tesztelő, a fejlesztő és a vezető között. A vezetőknek tudatosítaniuk kell a csapatukban, hogy a jó hibajelentés megírása minden tesztelő elsődleges felelőssége.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.