5.2 Ticket anatómiája – hogyan olvasd és értelmezd

Áttekintő

Kaptál egy ticketet. Megnyitod, és azt látod: „Javítsd a login oldalt." Semmi más. Nem tudod, mi a konkrét hiba, mi számít elfogadható megoldásnak, ki döntött erről, és mikor kell kész lenni. Ez a rossz ticket – sajnos rengeteg ilyet fogsz látni.

De van jó ticket is. Ez az alfejezet megmutatja, hogyan néz ki egy jól megírt ticket belülről, mit jelent az acceptance criteria, és mit tegyél, ha a ticketed hiányos vagy érthetetlen.

Részletes leírás

Egy jó ticket anatómiája

Egy professzionálisan megírt ticket néhány kulcselemet mindig tartalmaz. Ismerd meg ezeket – fejlesztőként olvassz, írsz és értékelsz is ticketeket majd.

Cím

A cím rövid, konkrét és cselekvés-orientált. Nem azt mondja, hogy „login probléma" – hanem azt, hogy „Jelszó visszaállító email nem érkezik meg Gmail-fiókokra".

Rossz cím	Jó cím
„Fix a bug"	„Profil képfeltöltés 500-as hibát dob 5 MB feletti JPG fájloknál"
„Bejelentkezés javítása"	„Kétfaktoros hitelesítés SMS kód nem érkezik meg Vodafone számokra"
„Dashboard lassan tölt"	„Dashboard első betöltése >4 mp, ha a felhasználónak 100+ aktív projektje van"

Típus

Minden ticket valamelyik kategóriába esik:

Bug – valami törve van, ami korábban működött (vagy soha nem működött helyesen)
Feature / Story – új funkció, amit meg kell valósítani
Chore / Task – technikai feladat, ami nem közvetlenül felhasználói értéket ad (pl. dependency frissítés, refaktoring, log szint módosítása)
Improvement / Enhancement – meglévő funkció fejlesztése, de nem bugfix

Miért fontos tudni a típust? Mert a prioritás, az elvárások és a kommunikáció más-más. Egy bughoz reprodukálható lépések kellenek; egy feature-höz acceptance criteria; egy chore-hoz technikai kontextus.

Leírás

A leírás a tickett tartalma. Bug esetén tartalmazza:

Reproduce steps – lépések, amelyekkel pontosan előidézhető a hiba
Expected behavior – mit kellene csinálnia a rendszernek
Actual behavior – mit csinál valójában
Environment – böngésző, operációs rendszer, verzió, felhasználói szerepkör

Feature esetén tartalmazza:

Kontextust – miért kell ez, milyen üzleti igényt old meg
Részletes leírást – mit kell pontosan megvalósítani
Acceptance criteria-t – mikor tekintjük elkészültnek

Acceptance criteria – a legfontosabb rész

Az acceptance criteria (elfogadási feltételek, AC) megmondja, mikor kész a feladat. Ez az egyetlen objektív mérce, amivel eldönthető: „elkészült-e a ticket, vagy nem?"

Jó acceptance criteria-t általában így írnak:

Elfogadási feltételek:
- [ ] A felhasználó be tud tölteni JPG, PNG és WebP formátumú képet
- [ ] A maximális fájlméret 10 MB; 10 MB felett hibaüzenet jelenik meg
- [ ] A feltöltött kép megjelenik a profiloldalon 2 másodpercen belül
- [ ] Sikertelen feltöltés esetén a felhasználó a korábbi képét látja változatlanul
- [ ] Mobil eszközön (iOS Safari, Android Chrome) is működik

Minden sor ellenőrizhető, konkrét állítás. Nincs benne „szépen működjön" vagy „legyen gyors" – ezek szubjektívek. Jó AC objektív és tesztelhető.

Prioritás

A prioritás megmutatja, mennyire sürgős és fontos a feladat. A legtöbb rendszerben 4-5 szint létezik:

Critical / Blocker – production le van állva, vagy egy kulcsfunkció teljesen működésképtelen. Azonnal foglalkozni kell vele.
High – fontos funkció sérül, de van kerülő megoldás. Soron következő sprintbe kerül.
Medium – kellemetlenséget okoz, de nem akadályoz. Normál ütemezéssel haladjon.
Low – apró fejlesztés, szépítés, „nice to have". Ha van rá idő.

Juniorként általában nem te állítod be a prioritást – de tudnod kell olvasni, és ha nem értesz egyet (mert pl. súlyosabb a hiba, mint ahogy le van értékelve), szólj.

Assignee, Reporter, Sprint, Story point

Reporter – ki nyitotta a ticketet (PM, felhasználó, fejlesztő)
Assignee – ki dolgozik rajta (te)
Sprint – melyik iterációba lett beütemezve
Story point – becsült komplexitás (erről részletesebben a következő alfejezetben)
Labels / Tags – szabad kategorizálás (pl. frontend, api, urgent, tech-debt)

Hogyan értelmezd az acceptance criteriát?

Az acceptance criteria a megállapodás a fejlesztő és a PM között. Ha valami nincs benne az AC-ban, akkor technikailag nem kötelező elvégezni – de praktikusan egy jó fejlesztő gondol az edge case-ekre és szól, ha valami hiányzik.

Olvasás közben mindig kérdezd meg magadtól:

Értem pontosan, mit kell csinálnia a rendszernek? Ha nem, kérdezz – ne találj ki.
Tudok-e minden feltételt ellenőrizni? Ha egy AC nem tesztelhető, kérd, hogy pontosítsák.
Hiányzik valami nyilvánvaló? Ha pl. az AC nem mention-öli a mobil nézetet, de a feature logikusan mobilon is kellene – kérdezz rá, ne feltételezz.
Van-e ellentmondás az AC-ban? Ha egy feltétel kizárja a másikat, azonnal jelezd.

Mit tegyél, ha a ticket nem egyértelmű?

Ez valószínűleg az első munkaheteden is előfordulni fog. Nem kell pánikba esni – sőt, a kérdés maga értékes tevékenység.

1. lépés: Próbálj meg egyedül megérteni

Olvasd el a ticketet kétszer. Nézd meg a kapcsolódó ticketeket (linkelve vannak?). Ellenőrizd, van-e hasonló, korábban lezárt ticket. Keress a kódbázisban a ticket titlusában szereplő szavakra.

Érdemes 10-15 percet szánni arra, hogy önállóan próbálod értelmezni.

2. lépés: Írj kommentet a ticketre

Ne Slacken kérdezz (az eltűnik), ne emailben (senki sem olvassa). Írj kommentet magára a ticketre. Fogalmazd meg konkrétan, mi az, amit nem értesz:

„Nem egyértelmű számomra az 'érvénytelen állapotban lévő rekordok' kifejezés. Ez azokra a sorokra vonatkozik, ahol a status mező NULL, vagy ahol a deleted_at ki van töltve, vagy mindkettőre? Mielőtt nekiállok, kérem pontosítást."

Ez jobb, mint „nem értem a ticketet" – mert megmutatja, hogy gondolkodtál rajta, és konkrét kérdésed van.

3. lépés: Döntsd el, kit kérdezz

Kérdés típusa	Kérdezd ezt
Üzleti logika, prioritás, felhasználói elvárás	PM (Product Manager)
Technikai megközelítés, architektúra, hol nyúljak a kódba	Teamlead / Senior fejlesztő
Tesztelési elvárás, acceptance criteria pontosítása	PM vagy QA
Hozzáférés, környezeti probléma, eszköz kérdés	Teamlead

Általános ökölszabály: ami az ÜZLETI célra vonatkozik → PM; ami a TECHNIKAI megvalósításra → teamlead.

Néha mindkettőnek kell szólni – ez is rendben van.

Ticket típusok és elvárások különbsége

Bug ticket

A jó bug ticket reprodukálható. Ez azt jelenti, hogy te, aki most kaptad, pontosan megismételheted a hibát a leírás alapján. Ha nem tudod reprodukálni, jelezd a ticketen – lehet, hogy environment-specifikus probléma, vagy már javítva lett.

Elvárt tartalom:

Típus: Bug
Cím: [Konkrét, mit ront el, hol]
Reproduce steps:
  1. ...
  2. ...
Expected: [Mit kellene látni]
Actual: [Mit látsz]
Environment: [Böngésző, OS, user role, verzió]
Screenshot/log: [Ha van]

Feature / Story ticket

A feature ticketben az üzleti kontextus a legfontosabb. Miért kell ez a feature? Kinek szól? Milyen problémát old meg?

Elvárt tartalom:

Típus: Feature
Cím: [Mit kell megvalósítani]
Kontextus/Indoklás: [Miért kell ez]
Leírás: [Részletes elvárások]
Acceptance criteria:
  - [ ] ...
  - [ ] ...
Design: [Figma link, screenshot – ha van]

Chore / Task ticket

Technikai feladat, kevesebb szertartással:

Típus: Chore
Cím: [Mit kell megtenni]
Leírás: [Miért kell, mi az elvárt kimenet]
Definition of Done: [Hogyan tudod, hogy kész]

Életszerű példák

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

Rossz ticket:

Cím: Login nem működik
Leírás: A felhasználó nem tud bejelentkezni. Legyen javítva.
Prioritás: High

Mi a baj ezzel? Nem reprodukálható – melyik felhasználó? Milyen körülmény? Mi pontosan „nem működik" – hibakód, redirect, üres oldal? Mit kellene csinálnia? Ez a ticket napokat vehet el a fejlesztő idejéből, mire kideríti, mi a tényleges hiba.

Jó ticket:

Cím: Bejelentkezési próbálkozás után az oldal fehéren marad és nem irányít át
Típus: Bug
Prioritás: High

Reproduce steps:
1. Nyisd meg a /login oldalt Chrome 121 böngészőben
2. Add meg a helyes emailt és jelszót
3. Kattints a "Bejelentkezés" gombra
4. Várj 3 másodpercet

Expected: Átirányítás a /dashboard oldalra
Actual: Az oldal fehér marad, nincs hibaüzenet, a console-ban: "TypeError: Cannot read properties of undefined (reading 'token')"

Environment: Chrome 121, macOS 14, Tesztkörnyezet
Érintett felhasználó: test@example.com (minden felhasználónál reprodukálható)

Ez a ticket percek alatt munkába állítja a fejlesztőt.

2. példa: Hiányos acceptance criteria

Anna kap egy feature ticketet: „Implementáld a CSV export funkciót a tranzakciók oldalon."

Az acceptance criteria:

- [ ] A felhasználó le tudja tölteni a tranzakcióit CSV-ben
- [ ] A letöltés gomb látható a tranzakciók oldalon

Anna olvasás közben felismeri, hogy hiányoznak fontos dolgok:

Melyik tranzakciókat exportálja? Az aktuális szűrés szerint, vagy összeset?
Van-e méretkorlát? Ha 50.000 sor van, az is megy egyszerre?
Milyen oszlopok legyenek a CSV-ben?
Milyen dátumformátum? 2024-01-15 vagy 15/01/2024?
Kódolás: UTF-8, hogy az ékezetes nevek helyesen jelenjenek meg?

Anna kommentet ír a ticketre ezekkel a kérdésekkel. A PM válaszol, pontosítja az AC-t. Ez 10 perc munka Anna részéről – de megment 2 napnyi félreimplementálást és egy csúnya review visszaküldést.

3. példa: Hova tedd a kérdést?

Béla kap egy ticketet: „Implementáld az audit log funkciót a felhasználókezeléshez."

Kérdés 1: „Pontosan milyen eseményeket kell naplózni?" – Ez PM kérdés. Az üzleti elvárás, hogy mi számít audit szempontból lényegesnek.

Kérdés 2: „Hova kerüljön az audit log – külön táblába, vagy az existing events táblába?" – Ez teamlead kérdés. Technikai döntés, ami érinti az architektúrát.

Kérdés 3: „Mi a maximálisan elvárt tárolási időszak?" – Ez PM kérdés. Üzleti és compliance döntés.

Kérdés 4: „Hogyan fér hozzá a jelenlegi rendszer a bejelentkezett felhasználó adataihoz?" – Ez senior fejlesztő kérdés. Codebase-specifikus technikai részlet.

Feladatok

Gyakorlati feladat: Hiányos ticket kiegészítése

Az alábbi ticket hiányos és nem egyértelmű. Feladatod: írd le, milyen kérdéseket tennél fel (komment formájában), és milyen elemeket egészítenél ki, ha te lennél a fejlesztő!

Cím: Profil szerkesztés javítása
Típus: Bug
Prioritás: Medium
Assignee: Te
Reporter: Márton (PM)

Leírás:
A felhasználók jelezték, hogy nem tudják szerkeszteni a profiljukat.
Legyen javítva mielőbb.

Acceptance criteria:
- [ ] A profil szerkesztés működjön

A feladatod:

Sorolj fel legalább 4 konkrét kérdést, amit kommentbe írnál a ticketre (a PM-nek és/vagy a teamleadnek).
Írj egy javított, teljes ticket leírást a saját feltételezéseid alapján (jelöld, hogy ezek feltételezések, amiket pontosítani kell).
Egészítsd ki az acceptance criteria-t legalább 5 tesztelhető feltétellel.

Tesztkérdések

1. Mi a szerepe az acceptance criteria-nak egy feature ticketben?

a) Megmondja, ki a felelős a fejlesztésért
b) Objektív feltételeket ad, amelyek teljesülése esetén a ticket lezárható
c) Meghatározza, melyik sprintbe kerüljön a feladat
d) Dokumentálja a korábbi hasonló bugokat

2. Melyik ticket leírás jelenti a jó bug ticketet?

a) „A login nem működik. Sürgős!"
b) „A bejelentkezési oldal fehéren marad Chrome-ban, reprodukálható lépésekkel, hibaüzenettel és environment infóval dokumentálva."
c) „Valaki jelzett egy problémát, nézze meg valaki."
d) „Javítsuk meg az összes logint."

3. Egy ticket acceptance criteriájában szerepel: „A rendszer legyen gyors." Ez milyen szempontból problémás?

a) Nem egyértelmű, hogy milyen funkciót kell implementálni
b) Nem tesztelhető – nincs konkrét, mérhető feltétel
c) Túl sok munkát igényel
d) Nem valódi üzleti igény

4. Fejlesztés közben rájössz, hogy a ticket leírásában nincs megadva, melyik felhasználói szerepkörre vonatkozik a feature. Mit teszel?

a) Megvalósítod minden szerepkörre, hogy biztosan jó legyen
b) Csak a saját feltételezésed alapján döntesz
c) Kommentet írsz a ticketre, és kéred a pontosítást a PM-től
d) Visszaadod a ticketet és nem foglalkozol vele

5. Melyik kérdést a PM-nek kell feltenni (nem a teamleadnek)?

a) „Milyen adatbázis táblát használjunk az audit log tárolásához?"
b) „Pontosan milyen felhasználói eseményeket kell naplózni audit szempontból?"
c) „Hogyan érhető el a bejelentkezett felhasználó session token-je a jelenlegi kódbázisban?"
d) „Érdemes-e Redis-t használni a caching réteghez?"

6. Mi a különbség a Bug és a Chore ticket típus között?

a) A bug csak frontendre vonatkozik, a chore backendre
b) A bug törött viselkedést dokumentál, a chore technikai feladat, ami nem közvetlenül felhasználói értéket ad
c) A chore sürgősebb, mint a bug
d) Nincs különbség, csak más eszközök hívják őket máshogy

7. Melyik szituációban HELYES Slacken kérdezni egy ticket kapcsán ahelyett, hogy a ticketre kommentelnél?

a) Ha a kérdésed fontos, és szeretnéd, hogy megmaradjon dokumentálva
b) Ha gyors visszaigazolásra van szükséged egy már a ticketben megválaszolt kérdésre
c) Soha – ticket kérdések mindig a ticketre kerüljenek
d) Ha valaki nem olvas Jirát

8. Egy jó ticket cím melyik formában van megírva?

a) „Login probléma"
b) „Jelszóvisszaállítás emailje nem érkezik meg Gmail-fiókokra 2 percen belül"
c) „Fix everything"
d) „Feladat a loginhoz"

9. Az acceptance criteria melyik tulajdonsága a legfontosabb?

a) Hosszú legyen, hogy minden részletet lefedjen
b) Minden pont tesztelhető és konkrét legyen
c) A fejlesztő írja, ne a PM
d) Legfeljebb 3 pont lehet benne

10. Ha egy ticket nem tartalmazza a reproduce steps-t (újra előidézési lépések), mi a legvalószínűbb következmény?

a) A fejlesztő gyorsabban meg tudja oldani, mert rugalmasabb
b) A fejlesztő értékes időt veszít azzal, hogy kideríti, hogyan reprodukálható a hiba
c) A PM szóban is el fogja mondani
d) A tesztelés során úgyis kiderül minden

Helyes válaszok

b – Acceptance criteria objektív, tesztelhető feltételeket ad a lezáráshoz
b – Jó bug ticket: konkrét, reprodukálható, environment infóval
b – „Legyen gyors" nem tesztelhető – nincs mérhető feltétel
c – Komment a ticketre, PM-nek szóló pontosítási kéréssel
b – Üzleti/funkcionális elvárás → PM; technikai megvalósítás → teamlead
b – Bug: törött viselkedés; chore: technikai feladat felhasználói értéke nélkül
b – Gyors visszaigazolás már megválaszolt kérdésre; minden fontos kérdés a ticketre menjen
b – Konkrét, specifikus, egy olvasással érthető
b – Minden pont legyen tesztelhető és konkrét
b – Reproduce steps hiányában a fejlesztő maga keresi a hibát, ami időbe kerül