Hogyan írjunk hibajelentést példákkal

Mi az a hibajelentés? Miért van szüksége egy jó hibajelentésre?

A hibajelentés egy fontos dokumentum az STLC-ben, amely számos előnyt kínál a tesztelő csapat számára. Nyomon követi a szoftvertesztelés során talált összes hibát, többszörös hibát, hibát és egyéb eltérést, és jelentést készít.

Ennek az utótesztelési dokumentációnak az a célja, hogy tájékoztatást nyújtson az érintett szakértői csapatnak a tesztelési folyamat során tapasztalt hibák szintjéről.

A te szoftverfejlesztő mérnök Az ilyen típusú jelentés segítségével a szoftverben jelen lévő összes hibáról és problémáról tudomást szerezhet. Azt is lehetővé teszi, hogy kitalálja, mi a hiba a hibával, így a legjobb módszert használhatja a javításra. Ezenkívül időt és pénzt takaríthat meg azáltal, hogy segít elkapni a hibákat és problémákat.

Miért kellene törődni a jó hibamagyarázatokkal?

Itt van az a pont, amelyet figyelembe kell vennie egy jó, részletes szoftverhiba-jelentés megírásához:

• Útmutatóként szolgál, hogy elkerülje ugyanazt a hibát a jövőbeli kiadásokban.
• Takarítson meg időt a kommunikációra (e-mailek, hívások).
• Less dolgozzon a fejlesztőknek (pontosan azt fogják csinálni, amit akar).
• Kevesebb szűk keresztmetszete lesz a projektben; a hibákat gyorsabban és hatékonyabban javítják ki.

Hibajelentés írása (Hibajelentés sablon)

Nincs pontos hibajelentési sablon, mivel az a hibakövető rendszertől függ. A sablonod eltérő lehet.

A következő gyakori mezőkre azonban mindig szükség van, ha hibajelentést szeretne írni:

• Hibaazonosító/cím.
• Súlyosság és prioritás.
• Leírás
• Környezet
• A szaporodás lépései.
• Várható eredmény.
• Valós eredmény.
• Mellékletek (képernyőképek, videók, szöveg)

Nézzük meg ezeket a hibaelhárítási összetevőket egyenként:

1) Cím/hibaazonosító:

Minden hibának egyedi azonosító számot kell adni. A hibabejelentő eszközöknek egyedi számoknak kell lenniük az újonnan felmerült hibákhoz, hogy könnyen azonosíthassuk a hibát.

Példák:

❌ Rossz: "Nem látom újra a terméket, de nem látom."

• Homályos
• Agresszív
• Túl bőbeszédű

megoldás megvalósítását kéri.

✅ Jó: „KOSÁR – Új termékek kerültek a kosárba, amelyek nem jelennek meg”.

• Ez a fajta cím azonnal megtalálja a problémát (CART)
• A tényleges műszaki problémára összpontosít.

2) A hiba súlyossága:

A hiba súlyossága nagyon fontos tényező a hibajelentésben. Leírja a hiba hatását az alkalmazás teljesítményére.

• Blokkoló: Ez a hiba az alkalmazás meghibásodását okozza.
• Jelentősebb: A kritikus hiba az üzleti logika jelentős változását jelzi.
• Kisebb: Olyan probléma, amely nem befolyásolja az alkalmazás működését, de hatással van a várt eredményekre.
• Jelentéktelen: Nem befolyásolja az alkalmazás működését vagy működését. Lehet, hogy nyomdahiba.

3) Hibaprioritás:

A hibaprioritás meghatározásához a következő általános fokozatok láthatók:

• Magas: Mindenre kiterjed, ami befolyásolja az áramlást vagy blokkolja az alkalmazás használatát.
• Medium: Ez hátrányosan befolyásolja a felhasználói élményt.
• Kisebb: Minden egyéb hiba, például (elírási hibák, hiányzó ikonok, elrendezési problémák stb.).

4) Környezet:

A hiba egy adott környezetben jelenhet meg, másokban nem. Például néha hiba jelenik meg a webhely futtatásakor Firefox, vagy az alkalmazás hibája csak akkor működik, ha egy Android készülék és jól működik iPhone-on.

Ezeket a hibajelentéseket csak böngésző- vagy eszközteszttel lehet azonosítani. Tehát a hiba bejelentésekor a minőségbiztosítási szerveknek meg kell tudniuk határozni, hogy a hibát egy vagy több meghatározott környezetben kell-e megfigyelni.

5) Összegzés:

A hibajelentésben azonban csak a cím hozzáadása nem szolgálja a célt. Tehát, ha a cím nem elég, hozzáadhat egy rövid jelentés összefoglalót.

Az összefoglaló a lehető legkevesebb szóban, beleértve, hogy mikor és hogyan történt a hiba. A címet és a hibaleírást is fel kell használni a keresésekben, ezért gondoskodnia kell arról, hogy a fontos kulcsszavakat lefedje.

Példák:

• Bad: „Megpróbáltam hozzáadni dolgokat a teszthez, de semmi sem jelent meg, amikor ezt megtettem vagy a gombra kattintottam.”
• Helyes: "Amikor megpróbáltam hozzáadni a [TERMÉK] terméket a bevásárlókosárhoz, de semmi sem történt, amikor a "hozzáadás" gombra kattintottam az adott termék áttekintő oldalán."

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

A hiba bejelentésekor fontos meghatározni a reprodukálás lépéseit. Olyan műveleteket is tartalmaznia kell, amelyek a hibát okozhatják. Itt ne tegyünk általános kijelentéseket.

Legyen pontos a követendő lépések tekintetében:

Íme egy példa egy jól megírt eljárásra:

Lépések:

1. Válassza ki a terméket X1.
2. Kattintson a Kosárba helyezés gombra.
3. Kattintson az Eltávolítás gombra a termék eltávolításához a kosárból.

7) Várható eredmény:

A hibajelentéseknél fontos a várható eredmény leírása a műszaki feladat, a teszteset kimenetelének tervezése vagy a tesztelő véleménye szerint. Mindez segít a fejlesztőknek abban, hogy a szükséges információk gyors megtalálására összpontosítsanak.

Például:

A kötelezően kitöltendő mezőket a „Küldés” gombra kattintás után pirossal kell kiemelni.

8) Tényleges eredmény:

Ahogy a neve is sugallja, ez a mező a hiba tényleges hatását írja le. Nagyon fontos, hogy világos leírást írjunk a tényleges eredményről.

Például:

A kötelezően kitöltendő mezők a „Küldés” gomb megnyomása után zöld színnel vannak kiemelve.

9) Mellékletek (képernyőképek és videók):

A hibajelentéseknél a legjobb gyakorlat, ha fájlokat csatol a hibajelentésekhez, ami megkönnyíti az információk észlelését, amikor vizuálisan kell megjeleníteni őket:

Például:

• Screenshot: A képernyőképek könnyen kidolgozhatják a program hibáit; Ez kényelmes, ha a hiba egy adott megjegyzéssel, körrel vagy nyíllal van kiemelve).
• Video: Néha nehéz szavakkal leírni a hibát, ezért érdemesebb videót készíteni, hogy a fejlesztő kijavíthassa a program hibáját).

10) Érintett verzió:

A hibát az érintett szoftververzió jelenti.

11) Javítási verzió:

Ez az a szoftververzió, amelyben a hibát kijavították. Tehát amikor a hibát jelentő QA ellenőrzi, hogy javítva van-e, akkor a megfelelő szoftververziót használja.

12) Target változat:

A célverzió, ahol a hibát meg kell célozni a javításhoz. Tehát amikor a fejlesztőcsapat egy hiba kijavításán dolgozik, többnyire egy adott alkalmazásverziót céloz meg.

13) Lezárás dátuma:

Ez az a dátum, amikor a szoftvertesztelő csapat lezárja a hibát. A hiba bezárása a szoftverteszt létfontosságú és szerves része.

14) Állapot:

Új hiba létrehozásakor az állapotának nyitottnak kell lennie. Ezt követően olyan szakaszokon megy keresztül, mint Folyamatban, Javítva, Futás, Újranyitás stb.

Tippek a hibajelentések írásához

Íme néhány fontos tipp, amelyeket emlékeznie kell a hatékony hibajelentés írása során:

• Legyen pontos a hibajelentések létrehozásakor. Ügyeljen arra, hogy ne adjon meg semmiféle haszontalan vagy lényegtelen tényt.
• A hibát azonnal jelentenie kell, amint észleli.
• Készítse el részletesen a jelentést, hogy a fejlesztő fel tudja használni a tényeket és az információkat a probléma hibakeresésére.
• Az érvényesítéshez tesztelni kell ugyanazt a hiba előfordulását más hasonló modulokon.
• Revlegalább egyszer nézze meg a hibajelentést, mielőtt elküldi.
• Győződjön meg arról, hogy a hibajelentés csak egy hiba leírását tartalmazza.
• Végül, ne féljen segítséget kérni a projektmenedzsertől, ha valamiben bizonytalannak érzi magát.

Hibajelentési eszközök

A manuálisan végrehajtott hibajelentési folyamat jelenleg a piacon elérhető különféle hibajelentési eszközökkel történik.

• TÚRA
• Zoho hibakövető
• Bugzillából

Megtekintheti részletes áttekintésünket a legjobb hibajelentési eszköz.

Gyakori probléma és megoldás hibajelentés írása közben:

Íme néhány gyakori probléma és megoldásuk hibajelentés írása közben:

Példa hibajelentésre	Probléma
Ha 2-t megszorozunk 3-mal, a válasz pozitív lesz.	Jelentse a mintát, ne egy példát.
Ennek elkerülése érdekében a lista ábécé sorrendben lesz új elem hozzáadásakor.	Ne csak azt írja le, hogy mi a baj
Például: A létezéshez meg kell nyitnia a böngészőt, és be kell írnia a webhely URL-címét. Az első mező, a "felhasználónév" elírással jelenik meg.	Mindig irányítsd a lényeget (soha ne mondd el a történetet!).
Az ügyfél neve a jelentésben hibásan van írva. Prioritás: Magas, Súlyosság: Magas	Soha ne keverje össze a prioritást és a súlyosságot.
Az adószámítási képlet HELYTELEN!!??	Nem használ CAPS-t, piros betűket, piros köröket, '!'
Szerintem nem jó a kezdőlap Ul dizájnja.	Ne használd az ítélőképességedet.
Példa a nem egyértelmű leírásra: A mai vitánkkal kapcsolatban, kérjük, hajtsa végre a szükséges lépéseket ezen az oldalon.	Leírását tegye mindenki számára érthetővé.
Az oldal háttere legyen kék, narancssárga vagy zöld, vagy feketére vagy fehérre is tehetjük. Ez nem jó, mert nem világos, mire van szükség a webfejlesztő és -tervező csapattól	Minimalizálja a lehetőségeket
Az adószámítási képlet néha nem a várt módon működik.	Az aranyszabály: Ne használja a „néha” szót.

Példa a hibajelentésre

Íme egy kis példa a hibajelentésre:

[MY ACCOUNT] Aláhúzás jelenik meg, ha az egérmutatót a Frissítés gombra viszi.

Description: El kell távolítanunk az aláhúzást, amikor az egeret a Fiókom szakasz Frissítés gombjára viszi.

Link: http://test.com/mv-account/

Böngésző/OS: Chrome 25. OSX Yosemite 10.10.2

A szaporodás lépései:

1. Nyissa meg a www.test.com webhelyet

2. Jelentkezzen be a bejelentkezési adatokkal

3. Lépjen a Saját fiók oldalra

4. Vigye az egeret a Frissítés gombra

Valós eredmény: van egy aláhúzás.

Várható eredmény: nincs aláhúzás.

Bejelentkezési adatok: test@test.com / mysecretpass12

Kerülni kell a hibákat a hibajelentés írása során

Íme néhány fontos hiba, amelyeket el kell kerülnie hibajelentés írása során:

• Ne írj az elégedetlenségedről, és soha ne írj bele személyes érzéseidbe.
• Idegesíti azokat az embereket, akik a feladatra akarnak összpontosítani, ha sok hangulatjellel túlterheli a bejegyzést.
• Soha ne terhelje túl a bejegyzést felkiáltójelekkel; nem gyorsítja a munkát.
• Senki sem akarja magát megsértve érezni. Lerombolja a motivációt és lelassítja a probléma felismerését.