Hibakövetés és sikeres projektmenedzsment? Így fér össze a kettő!

Bármilyen fejlesztési feladatba is vágjuk a fejszénket, a folyamat végén működő, megbízható eredményt szeretnénk látni. A szoftverfejlesztésben azonban nem reális elvárás, hogy egy összetettebb rendszerben soha ne jelenjen meg hiba. Sokkal fontosabb kérdés, hogy hogyan vesszük észre, dokumentáljuk, rangsoroljuk és javítjuk a problémákat.

Ebben segít a hibakövetés, angolul bug tracking. Egy jól kialakított hibakövetési folyamat nem egyszerűen a fejlesztők „hibalistája”: összekapcsolja a tesztelést, a fejlesztést, a projektmenedzsmentet és sok esetben az üzemeltetést is. Megmutatja, milyen problémák vannak nyitva, melyik mennyire súlyos, ki foglalkozik vele, és hol tart a megoldása.

A hibakövetés ezért egy szoftverfejlesztési projekt átláthatóságához is hozzájárulhat. Nem az a célja, hogy bebizonyítsa: valaki hibázott, hanem az, hogy egy felmerülő problémából kezelhető, nyomon követhető feladat legyen.

Mit jelent pontosan a hibakövetés?

A hibakövetés olyan folyamat, amelyben a szoftverben azonosított hibákat rögzítjük, kategorizáljuk, priorizáljuk, felelőshöz rendeljük, majd a javítást és annak ellenőrzését is nyomon követjük.

A gyakorlatban tehát jóval többről van szó annál, hogy valaki felírja: „nem működik a fizetés”. Egy használható hibajegy – gyakran ticket vagy issue – lehetőség szerint tartalmazza azokat az információkat, amelyek alapján a fejlesztő reprodukálni és megérteni tudja a problémát. Ilyen lehet például:

• mi történt és mi lett volna az elvárt működés;

• milyen lépésekkel idézhető elő a hiba;

• melyik rendszerben, verzióban vagy környezetben jelentkezett;

• milyen eszközön vagy böngészőben tapasztalták;

• milyen hibaüzenet vagy naplóbejegyzés kapcsolódik hozzá;

• milyen súlyos a probléma;

• ki felel a kivizsgálásáért vagy javításáért;

• milyen állapotban van a feladat.

Nem minden adatot kell kézzel megadni. A modern hibamonitorozó és alkalmazásmegfigyelő megoldások bizonyos technikai információkat automatikusan is összegyűjthetnek. Ilyen lehet például a stack trace, vagyis a hiba kialakulásához vezető függvényhívások lánca, az alkalmazás verziója, a futtatási környezet, illetve a hibához kapcsolódó technikai kontextus. Ez azonban már átvezet egy fontos különbséghez: a hibakövető rendszer és az automatikus hibamonitorozás nem feltétlenül ugyanaz.

Hibakövető szoftver vagy automatikus hibamonitorozás?

A két fogalom a gyakorlatban összekapcsolódhat, de más feladatot oldanak meg. Egy klasszikus hibakövető vagy issue tracking rendszer elsősorban a problémák kezelésére szolgál. Ebben jön létre a hibajegy, itt lehet felelőst kijelölni, prioritást megadni, kommentelni, státuszt változtatni és követni a javítás folyamatát. Az automatikus hibamonitorozó rendszer ezzel szemben magából az alkalmazásból gyűjt technikai információkat. Észlelheti például, ha egy alkalmazás futás közben kivételt dob, és a fejlesztő számára megmutathatja, melyik kódrész környezetében következett be a probléma.

A kettő együtt különösen hasznos. A monitorozás segít észlelni és diagnosztizálni, az issue tracking pedig segít megszervezni a megoldást. Ez azért lényeges pontosítás, mert nem minden hibakövető szoftver képes automatikusan megmondani, milyen adatbázis-lekérdezés vagy kérési paraméterek vezettek egy problémához. Az ilyen technikai kontextus összegyűjtése az alkalmazás megfigyelésétől, naplózásától és a választott eszközök integrációjától függ.

Miért éri meg hibakövető rendszert használni?

Az emberi erőforrás csodákra képes, de egy összetettebb fejlesztésnél rengeteg információt kell egyszerre kezelni. Ha a problémák e-mailekben, chatüzenetekben, szóban és különálló jegyzetekben jelennek meg, hamar nehézzé válik megállapítani, melyik hiba van még nyitva, ki dolgozik rajta és melyik változatban kellene javítani.

A hibakövető rendszer egy közös információs pontot ad a csapatnak. Így kisebb az esélye annak, hogy egy probléma egyszerűen eltűnik a kommunikációban. A hibák felismerése és rögzítése persze önmagában még nem jelenti azt, hogy azok szinte azonnal javításra is kerülnek. Egy komoly probléma kivizsgálása időigényes lehet, és előfordulhat, hogy előbb reprodukálni kell a hibát, meg kell találni a kiváltó okot, majd a javítást tesztelni is szükséges. A hibakövetés valódi előnye inkább az, hogy láthatóvá és irányíthatóvá teszi ezt a folyamatot.

Hogyan kapcsolódik a hibakövetés a projektmenedzsmenthez?

Első pillantásra a bug tracking technikai feladatnak tűnhet. Valójában közvetlen projektmenedzsment-következményei vannak. Egy fejlesztési projektben folyamatosan döntéseket kell hozni arról, hogy a rendelkezésre álló időt és fejlesztői kapacitást mire fordítsuk. Új funkció készüljön? Egy régebbi funkciót fejlesszünk tovább? Technikai adósságot csökkentsünk? Vagy egy hibát javítsunk?

Ha a hibák strukturáltan szerepelnek a rendszerben, a projektmenedzser, product owner vagy más döntéshozó pontosabb képet kaphat arról, milyen problémák terhelik a terméket.

A hibakövetés ezért jól kapcsolódik a feladatkezelő rendszerek használatához. A két terület között jelentős átfedés van: egy hiba végső soron olyan feladat, amelynek van felelőse, prioritása, állapota és életciklusa. A különbség inkább abban rejlik, hogy a hibajegy a szoftver egy konkrét rendellenes működését írja le, ezért a kezeléséhez speciális technikai információkra is szükség lehet.

A hibák priorizálása nem egyszerűen technikai kérdés

Nem minden hiba ugyanolyan fontos. Tegyük fel, hogy egy webáruház adminisztrációs felületén egy ikon néhány pixellel elcsúszik. Kellemetlen, de valószínűleg nem állítja meg az értékesítést. Ha viszont bizonyos vásárlók nem tudják befejezni a fizetést, egészen más súlyú problémáról beszélünk.

Éppen ezért hasznos különválasztani a hiba súlyosságát és prioritását. A súlyosság azt fejezi ki, hogy technikai vagy felhasználói szempontból mekkora hatása van a hibának. A prioritás azt mutatja meg, hogy az adott problémát milyen sürgősen szeretnénk megoldani. A kettő gyakran összefügg, de nem feltétlenül azonos. Egy ritkán használt funkció súlyos hibája például kisebb üzleti prioritást kaphat, mint egy kevésbé súlyos, de naponta több száz felhasználót zavaró probléma. A projektmenedzsment feladata éppen az ilyen kompromisszumok kezelése.

Hogyan néz ki egy hiba életciklusa?

A hibakövetés akkor igazán használható, ha a csapatnak van közösen értelmezhető folyamata arra, mi történjen egy új hibával. A konkrét státuszok szervezetenként eltérhetnek, de a folyamat jellemzően valahogy így alakul:

1. Hiba észlelése. A problémát megtalálhatja egy tesztelő, fejlesztő, ügyfél vagy automatikus monitorozó rendszer.

2. Rögzítés. Létrejön a hibajegy a reprodukcióhoz és kivizsgáláshoz szükséges információkkal.

3. Értékelés. A csapat megvizsgálja, valóban hibáról van-e szó, mennyire súlyos és milyen prioritást kapjon.

4. Felelős kijelölése. A problémát hozzárendelik ahhoz a személyhez vagy csapathoz, amelyik ki tudja vizsgálni.

5. Javítás. A fejlesztő feltárja a kiváltó okot és elkészíti a módosítást.

6. Ellenőrzés. A javítást tesztelni kell, mert attól, hogy a kódban történt változtatás, még nem biztos, hogy a probléma valóban megszűnt.

7. Lezárás. Ha a javítás megfelelően működik, a hibajegy lezárható. Ha a probléma továbbra is fennáll, visszakerülhet fejlesztésre.

Ez az életciklus azért is hasznos, mert minden résztvevő számára láthatóvá teszi, hol tart egy adott probléma. Nem kell külön megkérdezni a fejlesztőtől, hogy „mi lett azzal a hibával?”, ha a rendszerben naprakészen követhető az állapota.

Milyen egy jó hibajegy?

A „nem működik” típusú bejelentés ritkán elegendő. A fejlesztőnek először meg kell értenie, mi történt, majd lehetőség szerint reprodukálnia kell ugyanazt a helyzetet. Minél pontosabb a hibajegy, annál kevesebb idő mehet el a körülmények tisztázására.

Vegyünk egy egyszerű példát. A „Nem működik a belépés” bejelentésből nem derül ki, hogy a felhasználó milyen eszközön próbálkozott, milyen művelet után jelentkezett a hiba, kapott-e hibaüzenetet, és minden felhasználót érint-e a probléma.

Sokkal használhatóbb információ például az, hogy egy adott böngészőben a bejelentkezési gomb megnyomása után hibaüzenet jelenik meg, miközben egy másik böngészőben ugyanazzal a fiókkal sikeres a belépés. Ez már segít leszűkíteni a vizsgálatot. Egy jó hibajegynek azonban nem kell regénynek lennie. Annyi információt érdemes rögzíteni, amennyi a probléma egyértelmű azonosításához és reprodukálásához szükséges.

Mi történik, ha ugyanazt a hibát többször jelentik?

Nagyobb rendszereknél természetes, hogy ugyanazt a problémát több felhasználó vagy csapattag is észleli. Ha minden bejelentést külön hibaként kezelünk, a lista gyorsan megtelhet duplikációkkal. Ezért a hibakövetés része a hasonló hibák felismerése és összekapcsolása is. Egyes rendszerek ebben automatikus csoportosítással is segíthetnek, más esetekben a csapatnak kell felismernie, hogy két hibajegy ugyanarra a kiváltó okra vezethető vissza. Ez azért is számít, mert száz hibaesemény nem feltétlenül száz különböző hibát jelent. Előfordulhat, hogy ugyanaz a programhiba száz alkalommal jelentkezett.

Hibakövetés, tesztelés és minőségbiztosítás

A hibakövetés nem helyettesíti a tesztelést. A két folyamat más kérdésre válaszol. A tesztelés célja többek között annak ellenőrzése, hogy a rendszer az elvárt módon működik-e. A hibakövetés pedig gondoskodik arról, hogy az azonosított problémák ne vesszenek el, és végigkövethetők legyenek a javításig.

A javítás után ráadásul szükség lehet regressziós tesztelésre is. Ennek lényege, hogy ellenőrizzük: a módosítás nem rontott-e el egy korábban megfelelően működő funkciót. Egy összetettebb rendszerben ugyanis egy látszólag kis változtatás több komponensre is hatással lehet. Ha például egy közös jogosultságkezelési funkció módosul, nem elég azt ellenőrizni, hogy az eredeti hiba megszűnt-e; azt is meg kell nézni, hogy más felhasználói szerepkörök továbbra is megfelelően működnek-e.

Manuális és automatikus hibafelismerés

Nem minden probléma észlelhető ugyanúgy. A felhasználói felület hibáit, félreérthető folyamatokat vagy egy speciális használati helyzetben jelentkező problémát gyakran ember veszi észre. Más hibák viszont automatikusan detektálhatók az alkalmazás naplóiból és monitorozási adataiból. A kettőt ezért nem érdemes egymás alternatívájaként kezelni.

Az automatikus megfigyelés előnye, hogy olyan hibáról is értesítheti a csapatot, amelyet a felhasználó nem jelentett be. Az emberi tesztelés és visszajelzés viszont olyan problémákat is képes feltárni, amelyek technikailag nem generálnak hibát. Egy funkció például működhet pontosan úgy, ahogy leprogramozták, mégis lehet nehezen használható vagy félreérthető. Ez már részben felhasználói élmény kérdése, amit egy exception-monitorozó rendszer önmagában nem fog felismerni.

Milyen információt gyűjtsünk egy hibáról?

A hibák diagnosztizálásához minél több technikai kontextus hasznos lehet, de itt sem igaz, hogy minden adatot korlátlanul gyűjteni kell. Egy alkalmazás naplózhat például hibaüzenetet, időpontot, alkalmazásverziót, szerveroldali eseményeket vagy egy kérés technikai paramétereit. Ezekből sokszor rekonstruálható, mi vezetett a problémához.

Az adatgyűjtésnél azonban figyelni kell arra, hogy érzékeny adatok, jelszavak, hozzáférési tokenek vagy szükségtelen személyes adatok ne kerüljenek hibajegyekbe és naplókba. A részletesebb naplózás tehát nem automatikusan jobb naplózást jelent. Ez különösen lényeges, ha a hibakövető vagy monitorozó rendszer külső szolgáltatáshoz továbbít adatokat. Ilyenkor a technikai igények mellett adatvédelmi, biztonsági és hozzáférés-kezelési szempontokat is át kell gondolni.

Minden projektnek szüksége van külön hibakövető szoftverre?

Nem feltétlenül. Egy nagyon kicsi, rövid életű belső projektben előfordulhat, hogy a csapat meglévő feladatkezelő rendszere elegendő. Ha néhány ember dolgozik együtt, kevés a nyitott probléma és nincs összetett kiadási folyamat, egy külön bug tracking rendszer bevezetése több adminisztrációt okozhat, mint amennyi előnyt hoz. Ahogy azonban nő a projekt, egyre fontosabbá válik a strukturált hibakezelés. Több fejlesztő, több környezet, gyakori kiadások, külső felhasználók, üzletileg kritikus funkciók vagy több párhuzamos fejlesztési ág esetén már nehéz megbízhatóan fejben vagy chatüzenetekből követni a problémákat.

A kérdés tehát nem az, hogy „kell-e mindenkinek hibakövető szoftver?”, hanem az, hogy mekkora hibakezelési folyamatot indokol az adott projekt összetettsége és kockázata. Ha általánosabb feladat- és projektkövetésre van szükség, a feladatkezelő programok működése jó kiindulópont lehet. Egy konkrét projektmenedzsment-eszköz működését pedig a Trellóról szóló útmutató mutatja be részletesebben.

Mire figyelj hibakövető rendszer választásakor?

A legjobb eszköz nem feltétlenül az, amelyik a legtöbb funkcióval rendelkezik. Az számít, hogy illeszkedik-e a csapat munkamódszeréhez. Egy kisebb fejlesztőcsapatnak elég lehet egy egyszerű issue tracker, míg egy nagyobb terméknél már szükség lehet automatizációra, jogosultságkezelésre, egyedi munkafolyamatokra, verziók és kiadások követésére, fejlesztői eszközökkel való integrációra és részletes riportokra. A választásnál többek között azt érdemes megvizsgálni, hogy a rendszer:

• mennyire egyszerűen használható a csapat számára;

• támogatja-e a szükséges státuszokat és munkafolyamatokat;

• kezel-e prioritásokat, címkéket és felelősöket;

• összekapcsolható-e a verziókezeléssel és más fejlesztői eszközökkel;

• integrálható-e automatikus monitorozással;

• támogatja-e a csapat által használt projektmenedzsment-folyamatot;

• megfelelő jogosultság- és hozzáférés-kezelést biztosít-e;

• használható marad-e akkor is, ha később nő a projekt és a csapat.

Ha a vállalkozás több, egymáshoz kapcsolódó folyamatot szeretne egy rendszerben kezelni, a kérdés már túlmutathat az egyszerű hibakövetésen. Ilyenkor az ügyviteli rendszerek vagy más integrált vállalati megoldások is szerepet kaphatnak.

Mikor válik maga a hibakövetés problémává?

Egy rosszul kialakított folyamat könnyen adminisztrációs teherré változhat. Ha minden apró észrevételből hosszú hibajegyet kell készíteni, túl sok státusz létezik, senki nem tartja karban a backlogot, vagy több száz régi, már irreleváns issue marad nyitva, a rendszer elveszíti az áttekinthetőségét. Hasonló probléma, ha minden hibát automatikusan a legmagasabb prioritásra állítanak. Ha minden sürgős, akkor valójában semmi sem az.

A hibakövetés akkor működik jól, ha a folyamat elég részletes ahhoz, hogy használható információt adjon, de nem annyira bonyolult, hogy több munkát teremtsen, mint amennyit megtakarít. A rendszernek ezért időnként karbantartásra is szüksége van: érdemes átnézni a régi hibákat, lezárni a már irreleváns jegyeket, összevonni a duplikációkat és felülvizsgálni a prioritásokat.

Boldog ügyfél, büszke csapat – de nem a hibák teljes hiánya miatt

Valószínűleg a legtöbben belefutottunk már olyan digitális szolgáltatásba, amelynek egy hibájára évekkel később is emlékszünk. Egy fejlesztés során fellépő probléma megakaszthat üzleti folyamatokat, ronthatja a felhasználói élményt, és kritikus funkció esetén közvetlen üzleti következménye is lehet. A cél azonban nem egy irreális, „hibamentes fejlesztés” ígérete. Komplex szoftvereknél ennél hasznosabb cél egy olyan fejlesztési és üzemeltetési folyamat kialakítása, amelyben a hibák gyorsan észlelhetők, reprodukálhatók, megfelelően priorizálhatók és ellenőrzötten javíthatók.

Ebben a hibakövető szoftver fontos eszköz, de önmagában nem old meg mindent. Szükség van egyértelmű felelősségekre, megfelelő tesztelésre, következetes dokumentálásra és olyan projektmenedzsmentre, amely képes a hibajavítást az új fejlesztési igényekkel együtt kezelni. Ha pedig egy fejlesztés során a külső és belső csapattagok együtt dolgoznak, a jól dokumentált feladatok és hibák az együttműködést is megkönnyítik. Ez a kiszervezett szoftverfejlesztés esetén is különösen hasznos: minél egyértelműbb a probléma, annak prioritása és aktuális állapota, annál kevesebb információ veszhet el a szereplők között.

A jó hibakövetés tehát nem arról szól, hogy ki hibázott. Arról szól, hogy amikor egy szoftverben valami nem úgy működik, ahogy kellene, a csapat tudja, mi legyen a következő lépés.