Push rendszer újratelepítés utáni működésének ellenőrzése

Push teszt újra magánügyfeleknek

A Push teszt újra akkor fontos, amikor egy alkalmazás törlés és újratelepítés után nem ugyanúgy viselkedik, mint az első telepítésnél. Ilyenkor a feladat nem csak az, hogy megérkezik-e az értesítés. Azt is ellenőrizni kell, hogy az engedélyek, a felhasználói azonosítás, az eszköz tokenje, a bejelentkezés állapota és az üzenet útvonala rendben működik-e. Magánügyfélként ez főleg akkor lényeges, ha van egy kész vagy félkész alkalmazásod, és nem szeretnéd, hogy a felhasználó egy újratelepítés után elveszítse az értesítéseket.

Én azt látom, hogy sok hiba nem az első telepítésnél jön elő, hanem a másodiknál. Az alkalmazás már ismeri a felhasználót, a rendszer viszont új engedélyt, új azonosítót vagy más állapotot kezel. Ezért a push értesítés ellenőrzése nem lehet egyetlen gyors próba. A tesztelő feladata, hogy külön helyzeteket nézzen meg, és érthetően leírja, mi történt. Nem elég annyit mondani, hogy működik vagy nem működik.

Push értesítés tesztelése újratelepítés után

Az újratelepítés utáni értesítési próba általában több lépésből áll. Először törölni kell az alkalmazást, majd újra telepíteni, belépni vagy regisztrálni, engedélyezni vagy elutasítani az értesítést, és utána küldeni egy valódi tesztüzenetet. A szakember közben figyeli, hogy az értesítés megjelenik-e zárolt képernyőn, háttérben futó alkalmazásnál, bezárt alkalmazásnál és aktív használat közben.

Szerintem a legfontosabb kérdés az, hogy a régi és az új állapot nem keveredik-e. Előfordulhat, hogy az alkalmazás régi tokent használ, rossz felhasználóhoz kapcsolja az üzenetet, vagy nem frissíti időben a háttérrendszer adatait. Ezt egy felhasználó nem tudja pontosan megfogalmazni. Ő csak azt látja, hogy nem kap értesítést. A tesztelő viszont hibajegyet, képernyőképet, időpontot és ismételhető lépéseket ad.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy az értesítési rendszer teljesen hibás. A teszt során kiderült, hogy első telepítésnél minden rendben volt, de újratelepítés után az alkalmazás nem kért új engedélyt, miközben a háttérrendszer már más eszközazonosítót várt. A javításhoz nem kellett az egész rendszert átírni. Csak pontosan látni kellett, hol szakad meg a folyamat.

Online tesztelési folyamat és eredményátadás

Távoli munkánál a kezdéshez nem kell személyes találkozó. A megrendelő átadja az alkalmazás elérhetőségét, a tesztelési fiókot, a rövid leírást, a célplatformot és azt, milyen értesítéseket kell ellenőrizni. Ha van fejlesztői hozzáférés vagy tesztkörnyezet, az sokat segít. De sok esetben egy külső tesztelő akkor is hasznos, ha csak felhasználói szinten vizsgálja az alkalmazást.

A jó online folyamat rövid egyeztetéssel indul. Utána jön a próba több eszközön vagy több állapotban. A végén az ügyfél kap egy tömör jelentést. Ebben szerepelhetnek a tesztlépések, a várt eredmény, a tényleges eredmény, a hiba súlyossága, a képernyőképek és a javasolt következő lépés. Tapasztalatom szerint ez sokkal használhatóbb, mint egy hosszú, nehezen olvasható általános vélemény.

Push teszt ára és reális költsége

A Push teszt újra ára attól függ, hány állapotot kell ellenőrizni, hány eszközön történik a próba, és mennyire részletes jelentést kérsz. Egy egyszerű ellenőrzés olcsóbb, ha csak azt kell megnézni, hogy újratelepítés után megérkezik-e egy üzenet. Drágább lesz, ha belépési folyamat, engedélykezelés, több felhasználói fiók, különböző készülékállapot és részletes hibaleírás is kell.

A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent. Nem azért, mert minden drága teszt jobb. Hanem mert a gondos ellenőrzés időt kér. A tesztelőnek törölnie kell az alkalmazást, újra kell telepítenie, várnia kell az értesítésekre, jegyzetelnie kell, majd ismételnie kell a folyamatot. Ha valaki néhány perc alatt végez, nagy eséllyel csak egyetlen felszínes próbát csinált.

Megfelelő tesztelő választása

Magánügyfélként olyan tesztelőt érdemes keresni, aki érthetően kérdez. Nem baj, ha nem használ bonyolult szavakat. Inkább az számít, hogy rákérdez az alkalmazás céljára, az értesítési típusokra, a belépési módra és arra, mi számít hibának. A Qjob.hu felületén érdemes megnézni, hogy a szakember adott-e már hasonló online tesztelési munkára választ, és tud-e konkrét módszert írni.

A portfólió itt nem mindig látványos. Egy tesztelő munkája sokszor hibajegyekben, jelentésekben és pontos leírásokban látszik. Kérhetsz mintát arról, hogyan ír le egy hibát. Ha csak általános mondatokat kapsz, az nem jó jel. Ha a válaszban szerepelnek lépések, várt eredmény, tényleges eredmény és bizonyíték, akkor nagyobb eséllyel kapsz használható munkát.

Sokan ott hibáznak, hogy csak az árat nézik. Pedig az online értesítési teszt célja nem az, hogy valaki rányomjon egy gombra. A cél az, hogy megtalálja azt a helyzetet, amelyet a valódi felhasználó is átélhet. Ezért fontos a türelem, a pontosság és a tiszta kommunikáció.

Adatok, hozzáférések és kommunikáció

A push értesítés ellenőrzése előtt tisztázni kell, milyen adatokat adsz át. Gyakran elég egy tesztfiók, egy alkalmazáslink, a várt üzenet szövege és egy rövid lista arról, milyen helyzeteket kell kipróbálni. Ha érzékeny ügyféladatok vannak az alkalmazásban, jobb külön tesztfiókot létrehozni. Így a munka biztonságosabb és átláthatóbb.

A kommunikáció legyen egyszerű. Egy rövid írásos megbízás sok félreértést megelőz. Írd le, hogy az alkalmazást törlés után kell újra telepíteni, milyen fiókkal kell belépni, mikor kell értesítést küldeni, és milyen eredményt vársz. A szakember ez alapján tud ütemezni. Ha a tesztüzenetet más küldi, akkor az időpontot is egyeztetni kell.

Én hasznosnak tartom, ha a tesztelő a munka közben nem csak a végeredményt adja át, hanem a bizonytalan pontokat is jelzi. Például ha az értesítés késve érkezik, ha csak bizonyos beállítással működik, vagy ha az alkalmazás nem kér engedélyt ott, ahol kellene. Ezek apró dolgoknak tűnnek, de később sok panaszt okozhatnak.

Gyakori hibák újratelepítéskor

Az egyik gyakori hiba, hogy az alkalmazás régi állapotból indul. A felhasználó azt hiszi, új telepítést lát, de a rendszer egy része még korábbi adatokat használ. Ilyenkor az értesítés nem biztos, hogy a megfelelő eszközre megy. Máskor az engedélykérés marad el, vagy az alkalmazás nem kezeli jól, ha a felhasználó korábban elutasította az értesítést.

Gond lehet az is, ha a háttérrendszer nem frissíti gyorsan az új eszközadatot. A felhasználó belép, minden rendben látszik, de az első üzenet mégsem érkezik meg. Van olyan helyzet is, amikor az értesítés megjelenik, de rákoppintva rossz oldal nyílik meg. Ez nem csak kényelmetlen. Bizonyos alkalmazásoknál üzleti veszteséget is okozhat, mert a felhasználó nem jut el a fontos művelethez.

A Push teszt újra ezért nem puszta technikai részlet. Ez felhasználói élmény kérdése is. Ha valaki törli, majd újra telepíti az alkalmazást, jó eséllyel valamilyen problémát próbál megoldani. Ha ekkor az értesítések sem működnek, gyorsan elveszíti a bizalmát.

Minőségi elvárások és javítás utáni ellenőrzés

Az értesítési tesztelés akkor jó, ha a végén dönteni lehet belőle. Az ügyfélnek látnia kell, hogy a hiba ismételhető-e, melyik eszközön jelent meg, milyen beállítás mellett történt, és mi volt a pontos lépéssor. A rövid videó vagy képernyőkép sokat segít. De önmagában nem elég, ha nincs mellé érthető leírás.

Javítás után érdemes újra ellenőrizni ugyanazt a folyamatot. Ez a regressziós próba lényege. Nem kell minden funkciót újra végignézni, de a korábbi hibát és a hozzá kapcsolódó alaphelyzeteket igen. Tapasztalatom szerint sok ügyfél itt spórolna, pedig a javítás utáni ellenőrzés nélkül csak feltételezés marad, hogy a probléma valóban megszűnt.

Az online tesztelési munka akkor ad valódi értéket, ha a szakember nem csak hibát keres, hanem rendet tesz a bizonytalan helyzetekben. A jó eredmény rövid, pontos és továbbadható a fejlesztőnek. Így a Push teszt újra nem különálló papírmunka lesz, hanem egy praktikus lépés a stabilabb alkalmazás felé.