5.5 Bug ticket írása – reprodukálható és hasznos leírás

Áttekintő

Minden fejlesztő életében eljön a pillanat, amikor kap egy bug ticketet, amelyen ennyi áll: _„nem működik"_ vagy _„elromlott a bejelentkezés"_. Semmi más. Nincs reprodukálási lépés, nincs kontextus, nincs semmi.

Ez az alfejezet arról szól, hogyan NE legyen ilyen a te bug ticketed.

Egy jól megírt bug report nemcsak azt mondja meg, hogy valami rossz – megmutatja HOGYAN lehet előidézni a hibát, mit vártunk, mit kaptunk helyette, és milyen környezetben történt. Ez az a különbség, ami eldönti, hogy a hibát másnap javítják-e, vagy egy hétig mindenki azon veszekedik, hogy képes-e valaki egyáltalán reprodukálni.

Ez miért számít az első munkahelyen?

Két ok:

Te is fogsz bug ticketeket írni – nem csak megkapni.
Seniorjaid gyorsan megjegyzik, ha tőled mindig hasznos, reprodukálható leírást kapnak. Ez komoly szakmai pont.

Részletes leírás

Mi tesz egy bug ticketet jóvá?

A legjobb bug ticket az, amit a fejlesztő úgy tud elolvasni, hogy azután ő maga is reprodukálni tudja a hibát – anélkül, hogy bárkit meg kellene kérdeznie.

Öt összetevőre bontható:

1. Reprodukálási lépések (Reproduce steps)

Ez a legfontosabb rész. Lépésről lépésre, konkrétan, számozva. Nem „bejelentkeztem és elromlott", hanem:

1. Megnyitom a /login oldalt
2. Beírom a felhasználónevet: testuser@example.com
3. Beírom a jelszót: ********
4. Rákattintok a "Bejelentkezés" gombra
5. A rendszer visszadob a /login oldalra hibaüzenet nélkül

Ha a lépések nem egyértelműek, a fejlesztő nem tudja reprodukálni. Ha nem tudja reprodukálni, nem tudja javítani.

Tipp: Képzeld el, hogy egy idegen olvassa a ticketet. Van elég információja, hogy ugyanezt a hibát ő is előidézze?

2. Várt vs. tényleges viselkedés (Expected vs. Actual behavior)

Sok fejlesztő ezt kihagyja, holott ez az egyik legértékesebb rész.

Várt viselkedés: Mi kellett volna, hogy történjen? Tényleges viselkedés: Mi történt helyette?

Példa:

Várt: Sikeres bejelentkezés után a rendszer átirányít a /dashboard oldalra.
Tényleges: A rendszer visszanavigál a /login oldalra, hibaüzenet nem jelenik meg.

Miért fontos? Mert előfordulhat, hogy a fejlesztő másképp értelmezi, mi lenne a „helyes" viselkedés. Ha leírod, nincs vita – mindenki ugyanarra gondol.

3. Környezeti információk (Environment info)

Egy hiba nagyon másképp néz ki különböző környezetekben. Az alábbi infók legyenek benne:

Operációs rendszer és verzió (pl. Windows 11, macOS 14.3, Ubuntu 22.04)
Böngésző és verzió (ha webalkalmazás: pl. Chrome 123, Firefox 124)
Alkalmazás verzió / build szám / branch neve
Környezet (local, staging, production?)
Releváns adatok (pl. milyen felhasználói fiókkal reprodukálható?)

Ha kihagyod ezeket, a fejlesztő megkérdezi – de ez plusz időt vesz el mindenkinél.

4. Bizonyítékok: screenshot, log, hibaüzenet

Egy kép száz szót ér – főleg, ha látható rajta a hibaüzenet, amit a te képernyőd mutat.

Mit érdemes csatolni:

Screenshot a hibáról (főleg UI bugok esetén)
Konzolban megjelenő hibaüzenet (F12 → Console böngészőben)
Szerver oldali log részlet (ha hozzáférsz)
Pontos hibaüzenet szövege (ne csak leírd, hogy „valami hiba van", másold be a szöveget)

Hogyan másold be a log részletet: Ne screenshotot csinálj a logból – másold be szövegként, így kereshető marad.

5. Prioritás meghatározása

Nem minden hiba egyforma. Egy jó bug ticket jelzi a súlyosságot is:

Szint	Mikor?	Példa
Kritikus	Rendszer nem használható, adatvesztés	A fizetési folyamat 500 hibával végződik
Magas	Fő funkció nem működik, nincs kerülőút	Bejelentkezés sikertelen minden felhasználónál
Közepes	Funkció nem működik, de van kerülőút	Export gomb nem működik, de manuálisan le lehet tölteni
Alacsony	Kosmetikai hiba, kellemetlen de nem blokkoló	Gomb elcsúszott mobilon

Fontos: Ne minden hibát jelölj kritikusnak. Ha minden kritikus, akkor semmi sem az. Ez gyorsan elveszti a hitelességedet a csapatban.

A „nem működik" ticketek anatómiája – miért nem elég?

Képzeld el, hogy te kapod ezt a ticketet:

Cím: Bejelentkezés nem működik
Leírás: Nem tudok bejelentkezni. Kérem javítsák.

Mit tudsz ebből megállapítani?

Melyik felhasználóval reprodukálható?
Mi a konkrét hiba?
Mikor kezdődött?
Staging-en is van?
Mi az elvárt viselkedés?

Semmit. Előbb meg kell kérdezni a bejelentőt – és ezzel mindenki veszít 30 percet. Meg fogod ezt csinálni másokkal is? Igen. De ha te tudod, hogyan kell jól megírni egy bug ticketet, te leszel az a fejlesztő, akire nem kell visszakérdezni.

A jó bug ticket sablon

**Cím:** [Rövid, konkrét, aktív ige] – pl. "Bejelentkezés után a rendszer visszadob a login oldalra"

**Környezet:**
- OS: 
- Böngésző/kliens: 
- Alkalmazás verzió / branch: 
- Környezet (local / staging / production): 

**Reprodukálási lépések:**
1. 
2. 
3. 

**Várt viselkedés:**
[Mit kellett volna hogy történjen]

**Tényleges viselkedés:**
[Mi történt helyette]

**Bizonyítékok:**
[Screenshot, log részlet, hibaüzenet – kód formátumban]

**Prioritás:** Kritikus / Magas / Közepes / Alacsony

**Megjegyzés:**
[Bármilyen extra kontextus – pl. csak bizonyos felhasználóknál reprodukálható, csak Chrome-ban, stb.]

Ezt a sablont le lehet menteni a projekthez, és minden bug reportnál csak ki kell tölteni.

Életszerű példák

Példa 1: Rossz vs. jó bug ticket

❌ Rossz:

Cím: Profil oldal bugos
Leírás: A profil oldal nem töltődik be megfelelően amikor rámegyek.

✅ Jó:

Cím: Profil oldal 500-as hibával törik be, ha a felhasználónak nincs avatar képe beállítva

Környezet:

OS: macOS 14.3

Böngésző: Chrome 123.0

Branch: main (commit: a3f92b1)

Környezet: staging

Reprodukálási lépések:

Létrehozok egy új felhasználói fiókot avatar feltöltése nélkül

Bejelentkezem az új fiókkal

A felső navigációs sávban a nevemre kattintok

Megpróbálom megnyitni a /profile oldalt

Várt viselkedés: Megjelenik a profil oldal alapértelmezett avatarral (ahogy a tervekben szerepel).

Tényleges viselkedés: A szerver 500-as hibát dob. A böngésző konzolban a következő üzenet látható:
GET /api/users/42/avatar 500 Internal Server Error
Uncaught TypeError: Cannot read properties of null (reading 'url')
Prioritás: Közepes (avatart nem mindenki tölt fel, de ez a regisztrációs folyamat természetes része)

Megjegyzés: Avatarral rendelkező felhasználóknál nem reprodukálható. Az admin felhasználó pl. nem érintett.

Példa 2: Környezeti különbség fontossága

Egy csapattag jelent egy bugot: „A kosár összege rosszul jelenik meg."

Jó lenne tudni:

Csak Safariban, vagy Chrome-ban is?
Csak production-on, vagy staging-en is?
Csak bejelentkezett felhasználóknál?
Milyen pénznemben?

Ha ezek nincsenek benne, a fejlesztő 20 percet tölt azzal, hogy minden kombinációt kipróbál. Vagy nem reprodukálja és lezárja a ticketet „cannot reproduce" megjegyzéssel – ami frusztráló mindenkinek.

Példa 3: Prioritás túlbecslése – amikor minden kritikus

Egy junor fejlesztő minden bugot „Kritikus"-nak jelöl, mert úgy érzi, fontos. Néhány hét után:

A csapat figyelmen kívül hagyja a prioritást, mert nem megbízható
A valóban kritikus bugok elvesznek a zajban
A junior elveszti a hitelességét

Szabály: Kritikus = a rendszer nem használható élesben, vagy adatvesztés történik. Minden más kevesebb.

Tesztfeladatok

1. feladat – Felismerés

Melyik bug ticket leírás a hasznosabb fejlesztői szempontból?

Az email mező nem fogadja el a helyes email-t.

Az email validáció elutasítja a user+alias@example.com formátumú email-t a regisztrációs űrlapon. Várt: sikeres validáció. Tényleges: „Érvénytelen email-cím" hibaüzenet jelenik meg. Chrome 123, staging, reprodukálható minden esetben.

a) A
b) B
c) Mindkettő egyformán jó
d) Egyik sem jó

Helyes válasz: b)

2. feladat – Prioritás meghatározás

Egy webes banki alkalmazásban az alábbi hibákat jelzik. Sorold be őket prioritás szerint (Kritikus / Magas / Közepes / Alacsony):

Az egyenleg oldalon az összeg nem frissül automatikusan, de manuális újratöltéssel megjelenik a helyes adat.
Átutaláskor a rendszer levon kétszer összeget a számláról.
A számlakivonat letöltés gombja mobilon 2 pixellel el van csúszva.
Az ügyfélszolgálati chat ablak nem nyílik meg Firefox 120-as verzióban.

Helyes válaszok:

Közepes
Kritikus
Alacsony
Közepes

3. feladat – Hiányzó információk azonosítása

Az alábbi bug ticketből mi hiányzik? (Jelöld meg az összes hiányzó elemet.)

Cím: Keresés nem működik
Leírás: Rákerestem egy termékre és nem jött ki semmi. Próbáltam másik szóval is.

a) Reprodukálási lépések
b) Várt vs. tényleges viselkedés
c) Környezeti információk
d) Prioritás
e) Konkrét keresési szó, amivel próbálta
f) Semmi nem hiányzik

Helyes válasz: a, b, c, d, e – szinte minden hiányzik.

4. feladat – Igaz/Hamis

Döntsd el, melyik állítás igaz és melyik hamis:

Ha a bug csak production-on reprodukálható, nem kell megadni staging infót.
A prioritást mindig a bejelentő határozza meg, és a fejlesztők azt nem változtathatják meg.
Ha valami csak egy adott böngészőben reprodukálható, ezt kötelező megjegyezni a ticketben.
Egy screenshotot soha nem kell csatolni, elég leírni szövegesen a hibát.
Az Expected vs. Actual viselkedés rész segít elkerülni a félreértéseket arról, mi a „helyes" működés.

Helyes válaszok:

Hamis – érdemes staging infót is megadni, még ha nem reprodukálható is
Hamis – a prioritást módosíthatják mások is (pl. PM, tech lead) kontextus alapján
Igaz
Hamis – UI bugok esetén a screenshot rendkívül hasznos
Igaz

5. feladat – Ticket javítása

Az alábbi bug ticket leírást alakítsd át egy hasznos, teljes formátumba. (A feladat szövege alapján találj ki reális részleteket.)

Cím: Hiba a feltöltésnél
Leírás: Amikor feltöltök egy képet, valami hiba van.

Írj egy teljes bug ticketet a sablon alapján! A hiányzó részeket saját logikád szerint töltsd ki (pl. feltételezd, hogy 5 MB-os PNG fájl esetén reprodukálható, staging-en, Chrome-ban).

Ez nyílt végű feladat – értékelési szempontok: megvannak-e a kötelező részek, egyértelmű-e a leírás, reális-e a prioritás.

6. feladat – Szituációs döntés

Egy kolléga azt mondja: „Megtaláltam a hibát a kódban, de nem tudok reprodukálni a ticketből. Mit tegyek?"

Mi a helyes lépés?

a) Javítsd meg a hibát, mert te már tudod, mi a probléma
b) Kérd meg a bejelentőt, hogy egészítse ki a ticketet reprodukálási lépésekkel
c) Zárd le a ticketet „cannot reproduce" megjegyzéssel
d) Nyiss egy új ticketet te magad

Helyes válasz: b) – A fix esetleg helyes, de dokumentáció és reprodukálhatóság nélkül nem biztos, hogy ugyanazt a hibát javítod, amit a bejelentő tapasztalt. Kérd az infót.

7. feladat – Log részlet értelmezése

Az alábbi hibaüzenet egy bug tickethez csatolva érkezett. Mit tudsz belőle megállapítani, és hogyan segíti a fejlesztőt?

[2026-04-28 14:32:11] ERROR: NullPointerException at UserService.java:142
  caused by: user.getProfile() returned null
  user_id: 9823
  endpoint: GET /api/users/9823/profile
  environment: production

a) Semmit, mert ez szerver oldali log, amit a felhasználó nem láthat
b) Megadja a pontos fájlt, sort, user ID-t, endpoint-ot és környezetet – a fejlesztő azonnal tudja, hol keresse a hibát
c) Csak akkor hasznos, ha mellé van csatolva screenshot is
d) A log helytelen, mert nem tartalmaz stack trace-t

Helyes válasz: b) – Ez egy kiváló log részlet. Pontosan megmutatja, mit, hol, kinek, mikor.

8. feladat – Sablonkitöltés rangsorolása

Az alábbi három fejlesztő különböző módon töltötte ki a bug ticket sablont. Rangsorold őket a leghasznosabbtól a legkevésbé hasznosig.

Fejlesztő A:

Reprodukálási lépések:
1. Megnyitom az alkalmazást
2. Csinálom a dolgot
3. Hiba van

Fejlesztő B:

Reprodukálási lépések:
1. Bejelentkezem admin@example.com fiókkal (jelszó: [tesztadatok a .env-ben])
2. Navigálok az /admin/users oldalra
3. A keresőbe beírom: "test"
4. Az "Export CSV" gombra kattintok
Várt: CSV letöltés indul
Tényleges: A gomb nem reagál, konzolban: "Uncaught ReferenceError: exportCSV is not defined"

Fejlesztő C:

Reprodukálási lépések: Exportálni próbáltam, de nem ment.
Várt: Működjön
Tényleges: Nem működik

Helyes sorrend: B → A → C
(B: teljes, konkrét, kész; A: legalább számozva, de nem konkrét; C: teljesen haszontalan)

9. feladat – Miért számít az "Expected behavior" rész?

Egy fejlesztő úgy érvel: „Felesleges leírni, mi kellett volna hogy történjen – az nyilvánvaló."

Mi az ellenérv? (Válassz ki minden helyes választ.)

a) Nem mindig nyilvánvaló – a fejlesztő másképp értelmezheti a „helyes" viselkedést
b) Az Expected behavior rész a tesztelők számára is segítség az elfogadási kritériumhoz
c) Ha nincs leírva az elvárt viselkedés, a fix utáni ellenőrzés szubjektív lesz
d) Az Expected behavior csak UI bug esetén számít
e) Jogi szempontból kötelező megadni

Helyes válasz: a, b, c

10. feladat – Komplex szituáció

Egy bejelentő ezt írja Slacken: „@fejlesztő csapat – a rendelési folyamat teljesen elromlott! Sürgős!"

Mi a következő lépésed, mielőtt elkezdel bármit is keresni a kódban?

a) Azonnal elkezdeni debuggolni, mert sürgős
b) Megkérni a bejelentőt, hogy nyisson egy bug ticketet a sablonnak megfelelően
c) Megkérni a bejelentőt, hogy adja meg legalább: reprodukálási lépések, böngésző, és hogy melyik lépésnél romlott el
d) Leállítani a production szervert, amíg nincs több info

Helyes válasz: c) – Sürgős esetben sem érdemes vaktában beleugorni. 2 perc info-gyűjtés megspórolhat 2 óra vakdebuggolást. De b) helyett c) a reálisabb – Slacken gyorsan lehet infót kérni, nem kell visszaküldeni a sablonhoz formálisan.