Hibakeresés és összeomlások ellenőrzése a Firebase Crashlytics segítségével

Hibák ellenőrzése Crashlytics-szal magánügyfeleknek

A Hibák ellenőrzése Crashlytics-szal akkor hasznos, amikor egy mobilalkalmazás hibái nem csak fejlesztői megérzés alapján, hanem valódi összeomlási adatok szerint kerülnek vizsgálatra. A cél egyszerű. Látni kell, hol omlik össze az alkalmazás, milyen felhasználókat érint a gond, milyen gyakran ismétlődik, és melyik hiba igényel elsőként javítást. Magánügyfélként ez különösen fontos, mert nem mindig van külön tesztelői csapat, külön termékmenedzser és külön elemző. Egy online szakember ilyenkor segít átnézni a Crashlytics jelentéseket, értelmezni az adatokat, és érthető sorrendet adni a javításoknak.

Én azt látom, hogy sok alkalmazástulajdonos túl későn néz bele a hibajelentésekbe. Akkor kezdi keresni az okot, amikor már panasz érkezik, rossz értékelés jelenik meg, vagy egy frissítés után hirtelen romlik a stabilitás. Pedig a Crashlytics pont arra jó, hogy az összeomlások, nem végzetes hibák és lassulással összefüggő jelek hamarabb láthatók legyenek. Nem old meg mindent magától, de jó kiindulópontot ad. A szakember feladata az, hogy a nyers hibákból használható döntési alapot készítsen.

Qjob.hu felületén olyan magánszakember is kereshető, aki távolról dolgozik, hozzáférést kér a szükséges jelentésekhez, majd összefoglalót ad a talált problémákról. Ez nem feltétlenül jelent teljes fejlesztési munkát. Sokszor elég egy pontos ellenőrzés, egy javítási lista, vagy annak tisztázása, hogy melyik hiba érinti ténylegesen a felhasználókat.

Crashlytics hibaellenőrzés menete

A Crashlytics hibaellenőrzés általában a hozzáférések és az alkalmazásverziók tisztázásával indul. A szakember megnézi, melyik alkalmazásról van szó, milyen rendszereken fut, milyen verziók vannak használatban, és mikor jelentek meg a hibák. Ezután jön a jelentések áttekintése. Itt nem csak az számít, hogy hány összeomlás volt. Fontos az érintett felhasználók száma, az ismétlődés, az eszköztípus, a rendszerverzió, a naplózott események és az, hogy a hiba egy új kiadás után jelent meg vagy régebb óta jelen van.

Szerintem a jó ellenőrzés nem abból áll, hogy valaki kimásolja a hibaneveket. A hasznos munka ennél több. A szakember csoportosítja a problémákat, külön kezeli a kritikus összeomlásokat, a ritka de veszélyes hibákat, a sok felhasználót érintő gondokat, és azokat az eseteket, ahol a jelentés önmagában még kevés. Ilyenkor további tesztelés, felhasználói lépések visszakeresése vagy fejlesztői egyeztetés is kellhet.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy az alkalmazás fő hibája a fizetési képernyőn van. A panaszok alapján ez logikusnak tűnt. A Crashlytics adatai viszont azt mutatták, hogy a gond korábban kezdődött, egy belépés utáni adatbetöltésnél. A fizetési képernyő csak azért látszott problémásnak, mert a felhasználó addigra már sérült állapotú munkamenetben volt. Egy ilyen helyzetben a hibajelentés elemzése időt spórol, mert nem a tünetet kell javítani először.

Hibák ellenőrzése és javítási sorrend

A Hibák ellenőrzése Crashlytics-szal akkor ad jó eredményt, ha a hibák nem egy hosszú, átláthatatlan listában maradnak. A magánügyfélnek általában nem az kell, hogy minden technikai részletet azonnal értsen. Az kell, hogy lássa, mi veszélyes, mi zavaró, mi várhat, és mit érdemes előbb átadni a fejlesztőnek. A javítási sorrend ezért külön része a munkának.

Tapasztalatom szerint a legtöbb vita a sürgősség körül van. A megrendelő sokszor azt a hibát tartja fontosnak, amelyikről ő maga hallott egy felhasználótól. A jelentések viszont néha mást mutatnak. Lehet, hogy egy látványos panasz csak néhány embert érint, miközben egy csendes összeomlás sokkal nagyobb kárt okoz. A szakember ilyenkor nem csak technikai alapon rangsorol. Figyelembe veszi az üzleti hatást, a felhasználói utat, a hiba ismétlődését és a javítás becsült nehézségét.

Sokan ott hibáznak, hogy minden hibát azonnal kritikusnak neveznek. Ez rossz döntésekhez vezet. Ha minden sürgős, akkor semmi sem igazán sürgős. Egy jól elkészített hibaprioritás megkülönbözteti az azonnali javítást igénylő összeomlásokat, a kiadás előtt kezelendő hibákat, az utánkövetendő jelenségeket és azokat az eseteket, amelyekhez több adat kell. Így a fejlesztési munka tisztább lesz, és kevesebb idő megy el félreértésekre.

Crashlytics ellenőrzés árak

Az ár függ attól, hogy csak egy gyors jelentésáttekintés kell, vagy részletes hibadiagnózis, priorizálás és fejlesztőnek átadható feladatlista is. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a szakember ilyenkor csak átfutja a jelentéseket, de nem nézi meg az összefüggéseket. Egy korrekt ellenőrzésnél idő kell az adatok értelmezésére, a verziók összevetésére és a következtetések megfogalmazására.

Ezek tájékoztató jellegű távmunkás díjak. Kisebb alkalmazásnál a munka rövidebb lehet. Egy több platformon futó, sok verziót kezelő alkalmazásnál viszont több idő kell. Én óvatos lennék az olyan ajánlattal, amely mindent néhány ezer forintért ígér. Egy hibajelentés értelmezése nem csak kattintgatás. Hibás következtetés esetén rossz fejlesztési irány indulhat el.

Online szakember választása Crashlytics munkához

Online szakember választásánál nem elég azt nézni, hogy valaki ismeri a Firebase nevét. A magánügyfélnek olyan tesztelő vagy mobilalkalmazás szakember kell, aki érti az összeomlási jelentések logikáját, tud kérdezni, és nem ijesztget feleslegesen. Fontos, hogy világosan elmondja, milyen hozzáférés kell, mit fog megnézni, milyen formában adja át az eredményt, és hol vannak a vizsgálat határai.

A jó szakember nem kér mindenhez teljes jogosultságot, ha nincs rá szükség. Elég lehet korlátozott Firebase hozzáférés, képernyőmegosztás, exportált jelentés vagy célzott hibaképernyők megosztása. A lényeg az, hogy az adatbiztonság és a munka minősége egyszerre legyen rendben. Magánügyfélként érdemes rákérdezni arra is, hogy a szakember készít e érthető összefoglalót nem technikai nyelven. Ez sokat számít, ha a javítást később más fejlesztő végzi.

Portfólió helyett ezen a területen gyakran jobb a konkrét kérdés. Például hogyan döntene két hiba között, ha az egyik sok felhasználót érint, de ritkán omlik össze, a másik pedig kevés felhasználót érint, de fizetés közben jelentkezik. Az ilyen válasz megmutatja, hogy a szakember valóban gondolkodik e a felhasználói hatáson. Egy tapasztalt tesztelő ilyenkor nem ad túl gyors választ. Előbb adatot kér.

Távoli munka és eredményátadás

A Hibák ellenőrzése Crashlytics-szal teljesen jól végezhető távolról. A munka nem igényel személyes találkozót. A kommunikáció történhet üzenetben, videóhívásban vagy közös dokumentumban. A legfontosabb az, hogy a feladat elején legyen rövid leírás az alkalmazásról, az utóbbi frissítésekről, a panaszokról és arról, milyen döntéshez kell az elemzés. Más eredmény kell akkor, ha csak egy hibát kell megérteni, és más akkor, ha teljes stabilitási áttekintés készül.

A folyamat gyakran három részre bontható. Először adatgyűjtés és hozzáférés. Utána elemzés és kérdések. Végül átadás. Az átadás jó esetben nem csak egy általános mondat, hogy vannak hibák. Hasznosabb egy rendezett lista, benne a hiba rövid neve, hatása, gyakorisága, érintett verziója, feltételezett oka, sürgőssége és javasolt következő lépése. Ha reprodukciós lépések is láthatók, az külön érték.

Szerintem a határidőt mindig a hibatömeg alapján kell megadni. Egy gyors ellenőrzés akár egy munkanapon belül elkészülhet. Egy részletesebb vizsgálat több napot is igényelhet, főleg ha sok verzió, több operációs rendszer vagy többféle felhasználói folyamat érintett. A kommunikáció minősége ilyenkor nem mellékes. Ha a szakember nem kér vissza, amikor hiányzik egy adat, könnyen pontatlan lesz a végeredmény.

Gyakori hibák Crashlytics adatok értelmezésénél

A leggyakoribb hiba az, hogy valaki csak a darabszámot nézi. A sok esemény fontos jel lehet, de nem mindig jelenti azt, hogy az a legkritikusabb gond. Néha egy ritkább hiba súlyosabb, mert fizetésnél, regisztrációnál vagy adatmentésnél jelentkezik. Máskor egy gyakori hiba kevésbé veszélyes, mert tesztverzióból vagy régi alkalmazásverzióból jön. Az értelmezéshez mindig kontextus kell.

Másik tipikus gond, hogy a régi és az új hibák összekeverednek. Ha egy alkalmazás több hónapja gyűjti a jelentéseket, akkor a régi összeomlások zavarhatják a friss döntést. Ilyenkor verzió, dátum és felhasználói arány szerint kell szűrni. A Crashlytics ellenőrzés akkor hasznos, ha nem csak azt mondja meg, mi történt valaha, hanem azt is, mi számít most.

Sokan elfelejtik, hogy a nem végzetes hibák is fontosak lehetnek. Ezek nem mindig omlasztják össze az alkalmazást, de jelezhetik, hogy egy folyamat hibásan fut. Például egy lekérdezés nem ad vissza adatot, egy képernyő rossz állapotban marad, vagy egy külső szolgáltatás válasza hibásan kerül feldolgozásra. Az ügyfél ebből csak annyit lát, hogy valami furcsa. A jelentésben viszont már lehet nyoma.

Minőségi hibajelentés magánügyfélnek

A jó hibajelentés nem túl hosszú, de nem is felszínes. Magánügyfélként olyan anyagra van szükség, amelyből dönteni lehet. Mi legyen javítva azonnal. Mi várhat. Mit kell még tesztelni. Hol kell fejlesztőt bevonni. Hol lehet, hogy csak beállítási vagy adatküldési gond van. A szakember akkor dolgozik jól, ha a végén kevesebb a bizonytalanság, nem több.

A jelentésben hasznos lehet egy rövid vezetői összefoglaló, majd egy részletesebb hibajegyzék. Nem kell mindent bonyolult technikai nyelven leírni. De a fejlesztőnek átadható rész legyen pontos. Egy hiba neve önmagában kevés. Kell hozzá érintett képernyő, verzió, gyakoriság, felhasználói hatás és minden olyan adat, amely segíti a javítást. Ha a hiba nem reprodukálható, ezt is világosan kell jelezni.

A minőség ott látszik, hogy a szakember nem ígér biztos okot akkor, amikor csak valószínűséget lát. Ez fontos. A Crashlytics sokat mutat, de nem mindig teljes képet. Néha forráskód, napló, felhasználói visszajelzés vagy külön teszt is kell. Az őszinte megfogalmazás értékesebb, mint a túl magabiztos, de gyenge következtetés.

Crashlytics alapú ellenőrzés várható eredménye

A Crashlytics alapú ellenőrzés végén a megrendelőnek tisztábban kell látnia az alkalmazás stabilitását. Nem feltétlenül minden hiba javul meg azonnal. De láthatóvá válik, hol van a legnagyobb kockázat, melyik verzió okozott romlást, melyik hiba érinti a legtöbb felhasználót, és milyen sorrendben érdemes dolgozni. Ez már önmagában sokat segít egy kisebb projektben.

Az online munka előnye, hogy gyorsan elindítható, és az eredmény dokumentumban is átadható. A megrendelő később vissza tud térni a listához, meg tudja osztani fejlesztővel, és ellenőrizni tudja, hogy a javítás után csökkent e az összeomlások száma. Ez a része gyakran kimarad, pedig fontos. Egy hiba javítása után is nézni kell, hogy tényleg eltűnt e, vagy csak más néven, más körülmények között jelent meg újra.

Én azt tartom jó eredménynek, amikor a magánügyfél nem csak egy hibalistát kap, hanem egy érthető döntési alapot. A Hibák ellenőrzése Crashlytics-szal akkor éri meg igazán, ha a jelentésből következő lépés születik. Nem több bizonytalanság, hanem kevesebb.