Push-értesítések tesztelése különböző eszközökön és platformokon

Push-értesítések tesztelése magánügyfeleknek

A Push-értesítések tesztelése akkor hasznos, ha egy alkalmazás vagy webes felület üzenetei nem mindig érkeznek meg, rossz időben jelennek meg, vagy másképp látszanak egyes készülékeken. A cél egyszerű. Kiderül, hogy az értesítés tényleg működik-e a felhasználó oldalán, nem csak a fejlesztői rendszerben. Én azt látom, hogy sok ügyfél csak akkor kér segítséget, amikor már panasz érkezik a felhasználóktól. Pedig a hibák nagy része előbb is megtalálható lenne egy alapos online teszttel.

Ez a munka távolról is jól elvégezhető. A megbízó elküldi az alkalmazás elérését, a tesztfiókokat, a rövid leírást és azt, hogy milyen helyzetekben kell értesítést kapni. A szakember több eszközön, eltérő rendszerbeállításokkal és különböző felhasználói állapotokkal ellenőrzi az eredményt. Nem elég azt megnézni, hogy megjelenik-e egy üzenet. Fontos a cím, a szöveg, az ikon, az időzítés, a kattintás utáni útvonal, az engedélykérés és az is, hogy a felhasználó mit lát, ha az alkalmazás nyitva van vagy háttérben fut.

A Qjob.hu felületén magánszemélyek is találhatnak olyan tesztelőt vagy mobilalkalmazás szakembert, aki nem céges csomagot ad el, hanem konkrét hibakeresést és ellenőrzést vállal. Ez különösen akkor praktikus, ha a feladat nem teljes alkalmazásteszt, hanem egy jól körülírt értesítési folyamat vizsgálata.

Push-értesítés teszt ára

Az ár leginkább attól függ, hány eszközön kell ellenőrizni az értesítést, mennyi állapotot kell kipróbálni, és kell-e hibaraport képernyőképekkel. Szerintem a túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelő ilyenkor csak egy gyors próbát végez. Egy push hiba viszont sokszor nem az első küldésnél látszik. Lehet, hogy csak újraindítás után, hálózatváltáskor, régi alkalmazásverziónál vagy kikapcsolt engedélynél jelenik meg.

Tapasztalatom szerint egy kisebb feladatnál a fix ár kényelmesebb. Nagyobb ellenőrzésnél jobb a részletes feladatlista alapján számolni. Így nem lesz vita abból, hogy mi számít hibának, hány újratesztelés fér bele, és milyen formában készül el az eredmény.

Push-értesítések tesztelése több eszközön

A push üzenet viselkedése készülékenként eltérhet. Más lehet egy friss és egy régebbi operációs rendszer. Más a zárolt képernyő, az értesítési sáv, a néma mód, az akkumulátorkímélő beállítás és a háttérben futó alkalmazás kezelése. Ezért a több eszközös ellenőrzés nem felesleges részlet, hanem a munka lényege.

Sokan ott hibáznak, hogy csak a saját telefonjukon próbálják ki az értesítést. Ha ott megérkezik, késznek tekintik a funkciót. De a felhasználók nem egyforma készüléket használnak. Van, aki nem adott engedélyt. Van, aki törölte és újratelepítette az alkalmazást. Van, aki régi verziót használ. És van olyan helyzet is, amikor a szerver elküldi az üzenetet, de a készülék már nem fogadja, mert a token elavult vagy a kapcsolat megszakadt.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy a rendszer teljesen jól működik, mert a tesztüzenet minden alkalommal megjelent az egyik telefonján. A részletes online ellenőrzés viszont kimutatta, hogy az új felhasználók első értesítése nem érkezett meg, ha a regisztráció után azonnal kiléptek az alkalmazásból. Ez üzletileg fontos hiba volt, mert pont az első kapcsolatfelvétel maradt el. A javítás után nem a szöveg lett jobb, hanem maga a kézbesítés vált megbízhatóbbá.

Megfelelő online tesztelő választása

A jó tesztelő nem csak kattintgat. Kérdez, jegyzetel, és érti, hogy egy push értesítés egyszerre technikai és felhasználói feladat. Érdemes olyan magánszakembert választani, aki tud mobilalkalmazást tesztelni, érti az értesítési engedélyeket, és világosan leírja, milyen eszközökkel dolgozik. Nem kell mindenhez fejlesztőnek lennie, de tudnia kell, mikor kell technikai adatot kérni.

A portfólió itt nem mindig látványos. Fontosabb a tesztelési gondolkodás. Kérj rövid mintát arról, hogyan nézne ki a hibaraport. Egy hasznos jelentés nem csak annyit ír, hogy nem működik. Leírja a lépéseket, az eszközt, a rendszerverziót, az alkalmazás állapotát, a várt eredményt és a tényleges eredményt. Ez alapján a fejlesztő vagy a tulajdonos gyorsabban megérti a gondot.

Én azt látom, hogy a legjobb együttműködés akkor jön létre, ha az ügyfél nem általános mondattal indít, hanem konkrét célt ad. Például azt, hogy a rendelés után azonnal kell üzenet, fizetés után másik szöveg, lemondás után pedig külön értesítés. Így a mobilalkalmazás tesztelő pontosan tudja, mit kell bizonyítania.

Online munka menete és átadás

A munka általában rövid egyeztetéssel indul. A megbízó elküldi a hozzáféréseket, a tesztfiókokat és azokat az eseményeket, amelyek értesítést indítanak. Ezután a szakember összeállítja a tesztlépéseket. Nem kell hosszú dokumentum, de kell egy világos lista. Melyik gomb után mi történjen. Mikor érkezzen az üzenet. Hova vigyen a kattintás. Mi legyen akkor, ha a felhasználó nem adott engedélyt.

Az online kommunikáció legyen tömör. Egy közös üzenetfolyam, képernyőképek, rövid videók és egy megosztott hibalista többnyire elég. A tesztelés végén a megbízó kap egy áttekinthető anyagot. Ebben szerepelnek a sikeres próbák, a hibák, az ismételhető lépések és a javasolt javítási irányok. Ha szükséges, a tesztelő újra ellenőrzi a javításokat. Ez külön tétel is lehet, mert nem ugyanaz, mint az első vizsgálat.

A határidő a feladat méretétől függ. Egy alap ellenőrzés akár egy munkanapon belül elkészülhet. Egy több platformos push értesítés tesztelés már több napot is igényelhet, főleg akkor, ha időzített üzeneteket, különböző szerepköröket vagy ismételt küldéseket is figyelni kell. A gyors munka nem baj, ha előre tisztázott a hatókör. A kapkodás viszont könnyen kihagyott hibákhoz vezet.

Gyakori hibák push üzeneteknél

A push rendszerek hibái sokszor aprónak tűnnek. Az üzenet késik pár percet. A cím túl hosszú. Az ikon nem jelenik meg. A kattintás nem a megfelelő képernyőre visz. Vagy az értesítés kétszer érkezik meg. Ezek a hibák külön-külön nem mindig tűnnek súlyosnak, de a felhasználói bizalmat gyorsan rontják.

Gyakori probléma az is, hogy a szöveg technikailag megérkezik, de a helyzete rossz. Egy lezárt rendelés után még promóciós emlékeztető érkezik. Egy törölt fiók tovább kap üzenetet. Egy új felhasználó nem kap üdvözlő értesítést. Egy webes push feliratkozás működik, de leiratkozás után is marad egy aktív állapot. Ilyenkor nem csak az üzenetküldést kell nézni, hanem a teljes felhasználói útvonalat.

Szerintem az egyik legfontosabb kérdés az, hogy a hiba ismételhető-e. Ha igen, akkor javítható. Ha csak néha jelentkezik, akkor pontosabb naplózás, több eszköz és türelmesebb vizsgálat kell. A jó online tesztelés nem ígéri, hogy minden rejtett hibát azonnal megtalál. De sokkal több bizonyítékot ad, mint egy egyszeri próbaküldés.

Push-értesítés minősége és elvárások

A Push-értesítések tesztelése akkor ad jó eredményt, ha az ügyfél előre meghatározza, mit jelent számára a működő értesítés. Csak az számít, hogy megérkezik. Vagy az is, hogy gyors, pontos, érthető és jó helyre visz. A második megközelítés jobb, mert a felhasználó nem technikai eseményt lát, hanem egy rövid üzenetet, amelynek segítenie kell őt.

A minőséghez hozzátartozik a következetesség. Ugyanarra az eseményre ugyanaz a logika működjön. A nyelv legyen tiszta. A rövid szöveg ne legyen félreérthető. A kattintás ne vigyen üres oldalra. És ne legyen olyan értesítés, amely már nem aktuális. Ezek nem nagy elvárások, mégis gyakran kimaradnak, mert a fejlesztés végén csak a küldés sikerét ellenőrzik.

Egy magánszakember akkor tud jól dolgozni, ha kap tesztelhető állapotot és egyértelmű visszajelzési csatornát. Nem kell mindent előre tökéletesen leírni, de az alapfolyamatokat igen. Ha ez megvan, a push értesítési ellenőrzés gyorsan megmutatja, hol van technikai hiba, hol rossz a felhasználói élmény, és hol kell pontosítani az üzenetek működését.