Webalkalmazások hibakezelése 2

Miután beismertük, hogy mi magunk is követünk el hibákat és megismertük a különböző hibák típusait azt kell megvizsgálnunk, hogy hogyan találhatjuk meg a kódunkban bujkáló gonosz kis manókat, és ha már egyszer rájuk akadtunk akkor mit is kezdjünk velük.

Hibák megtalálása

Ideális esetben a projektünkben dolgozik egy beta tesztelő csapat akinek az a dolga, hogy megtalálja a működés során fellelhető hibákat. E mellett van pár programozó aki a teljesítmény és pár aki a biztonsági hibák felfedezésén dolgozik.

Kisebb fejlesztői csapat, vagy egy személyes fejlesztés esetén kicsit másképpen fog kinézni a hibák begyűjtése. Amit 100%-os biztonsággal kijelenthetünk az az, hogy a fejlesztő maga biztosan nem fogja megtalálni a hibák jó részét. Sokszor a legszembeötlőbb hibák jó részét sem. A fejlesztő biztosan rendelkezni fog egy jó csomó koncepcióval, előzetes ismerettel aminek a fényében igencsak másképpen fogja használni az alkalmazást mint az egyszerű mezei user aki épp most jött a falvédőről.

Ezekben az esetekben (mármint amikor a fejlesztői csapat létszáma 1és 10 között van) külön kérni kell a felhasználókat, hogy jelezzék ha hibát találtak. Az én kedvenc beta tesztelőm a feleségem. Olyan módon használja az általam fejlesztett alkalmazásokat az első próba során amire én soha, semmilyen körülmények között nem gondoltam volna. A módszerem a következő: fogom a programot, egyetlen rövid mondatban megmondom, hogy miről szól és az orra alá tolom, hogy “Ne é!”. Mivel nem kap semmi információt arról, hogy mit lehet és mit hogyan, kénytelen felfedezni az alkalmazást, azaz első körben erőteljesen teszteli az alkalmazás megismerhetőségét. A megismerhetőség egy nagyon fontos téma, főleg a weben. Erről szeretnék majd írni egyszer bővebben, de szükségem van még némi biztatásra.

A megismerhetőség után az asszony nekigyürkőzik a funkciók tesztelésének. Ebben is nagyon ügyes mert mindent a lehető legnyakatekertebb és számomra legillogikusabb módon kíván megoldani. És ez jó. Jó mert ilyenkor mindig rá kell döbbennem, hogy más más emberek mennyire másképpen állnak neki ugyanannak a problémának.

Debuggerek

Ha megvannak, hogy mik a hibák, akkor elővehetjük a debuggereket amelyek a hibákat kiváltó okok megtalálásában segítenek. HTML, CSS és JavaScript debuggolásra kitűnő eszköz a Firebug. A PHP már valamivel nehezebb ügy, de erre is találhatóak eszközök.

Hibák nyilvántartása, nyomon követése

Az első és legkézenfekvőbb hiba nyilvántartási rendszer az amikor a forráskódban elhelyezünk TODO vagy FIXME kezdetű megjegyzéseket. Az Eclipse, illetve sok más fejlesztői környezet támogatást ad az ilyen típusú hibák nyilvántartására. Ez a módszer jobb mint a semmi, de rettentő messze áll az ideálistól. Hamarosan látni fogjuk, hogy miért. Külön szeretném kihangsúlyozni, hogy a lent leírtak egyszemélyes vagy kis létszámú fejlesztői csapat esetében is igazak és erőteljesen csökkentik a fejlesztésre fordítandó időt.

Hogyan néz ki egy hibajelentés?

Előszőr azt nézzük meg, hogy hogyan néz ki egy jó hibajelentés. Egy használható hibajelentésnek egy webalkalmazás esetében a következő információkat kell tartalmaznia.

  • a hiba rövid leírása
  • reprodukálhatóságának lépései
  • a használt operációs rendszer
  • böngésző neve, verziója
  • mi az elvárt viselkedés
  • mi történt ezhelyett
  • egyéb infók

Ezek azok az információk amelyek szükségesek ahhoz, hogy a hiba javításával foglalkozó fejlesztő meg tudja találni a kódban a hibát kiváltó programrészletet.

Hiba életciklus

Egy hiba életciklusa azzal kezdődik, hogy létrejön, és a fejlesztő nem javítja ki azonnal. Ez lehet amiatt, hogy észre sem veszi, vagy lehet amiatt, hogy ugyan tudatos róla, de egy másik problémával foglalkozik éppen és nem kíván az adott pillanatban a hibára időt fordítani.

A következő lépés amikor valaki jelenti a hibát, jó esetben a fent leírt információk megadásával. Ekkor lép a hiba a nyitott állapotba.

A hiba reprodukált állapotba lép. Ez egy fontos momentum, mivel ezen a ponton bizonyítást nyer, hogy a hiba valóban létezik, másoknál is előidézhető, nem csak annál aki eredetileg azt jelentette.

A hiba beazonosított állapotba lép amikor megtalálják annak kiváltó okát. Ezen a ponton fogjuk a debuggereket munkába.

Ezután a hiba javításra jelölt állapotba lép. Ilyenkor általában meghatározzák, hogy melyik fejlesztő fog a hiba kijavításával foglalkozni, valamint azt, hogy milyen határidőre vagy melyik új verzióban kell a hibát kijavítani.

A hiba akkor kerül lezárt állapotba amikor kijavítottuk és a javítás elérhető a felhasználók számára.

Speciális hiba életszakaszok

A fenti normál életszakaszokon kívül van egy pár másik állapot amibe a hiba beléphet.

  • Ha a hiba nem reprodukálható akkor életciklusa itt véget is ér. A nem reprodukálható hibákat általában “nálam megy” (“work for me”) jelöléssel zárják le.
  • Ha a hiba már ismert akkor a “már ismert” (“known” vagy “duplicate”) jelöléssel kerül lezárásra
  • Ha a hiba nem hiba akkor a “nem javítandó” (“won’t fix”) jelöléssel zárjuk le. Ilyen például amikor valaki hibaként jelenti, hogy az alkalmazás nem működik IE5-tel, nekünk viszont nem is célunk, hogy működjön alatta.

Ha mindezeket az információkat megpróbáljuk belesűríteni a forráskódba akkor bizony bajban leszünk. Nem beszélve arról, hogy így még mindig nem lesz biztosítva az, hogy a felhasználók követni tudják, hogy mi történik az általuk (vagy éppen mások által) jelentett hibákkal

Hibakövető rendszerek

A hibakövető rendszerek olyan alkalmazások amelyek segítségével a felhasználók hibajelentéseket tudnak küldeni a fejlesztőknek, amelyekben nyomon követhetőek a hibák kezelésének szakaszai és amelyek teljes egészében lekezelik a többi hibakezeléshez szükséges feladatokat.

A hibakövető rendszerek használatával egy más szintre léptethetjük a fejlesztést. Nem győzöm hangsúlyozni, hogy egyszemélyes fejlesztés esetén is nagyon hasznos egy hibakövető rendszer használata. Minden jelentett hiba megmarad, nem vész el valahol a forráskódban vagy kis cetliken, tervezhető, hogy mely új verzióban kívánjuk kijavítani őket, súlyozhatóak, hogy mennyire fontosak, kategorizálhatóak, hogy milyen szakterülethez tartoznak és még megannyi más előnyük van. A hibakövető rendszerek is azok a típusú alkalmazásuk, hogy miután az ember elkezdi őket használni már nem érti, hogy nélkülük hogyan tudott egyáltalán dolgozni.

Az ingyenes hibakövető rendszerek közül a legnépszerűbbek a következők.

Bugzilla
A hibakövető rendszerek de facto sztenderdje. Nagyon népszerű, széles körben használt, jól működő rendszer.
GNATS
Az egyik legrégebbi hibakövető rendszer. Többféle interfészen keresztül is működtethető.
Mantis
Webes alapú hibakövető rendszer. Könnyen kezelhető, gyors és kicsi.

Hibák és verziók kiadása

Amit még el kell dönteni, hogy hogyan kapcsolódnak a hibajavítások a kiadott verziókhoz. Elvileg ugyan lehetséges, hogy akkor adjunk ki új verziót amikor az összes ismert hiba javítva van, de gyakorlatilag ez teljességgel értelmetlen és kivitelezhetetlen. Az egyik legműködőképesebb elv lehet az, hogy a súlyosnak jelölt hibákat kell javítani mielőtt kiadnánk egy új verziót. Ez alól kivételt képezhetnek a súlyos biztonsági hibát javító verziók. Mindenesetre jól járunk ha kidolgozunk valamilyen elvet, mert ezzel jól átlátható szakaszokra bonthatjuk a fejlesztést és nem fog a hibákkal való küzdelem szélmalomharccá alakulni.

Remélem ebben a két részben átrágtunk mindent ami a webes alkalmazások hibakövetésével kapcsolatos és sok mindenkinek segít a hibák kezelésében. Jó kódolást!

One thought on “Webalkalmazások hibakezelése 2

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

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.