Alkalmazás háttérműködésének tesztelése és optimalizálása

Alkalmazás tesztelése magánügyfeleknek

Az Alkalmazás tesztelése akkor hasznos, ha egy mobilalkalmazás vagy webes felület működését valós használat előtt szeretné ellenőriztetni egy független szakemberrel. A cél nem az, hogy valaki csak rákattintson néhány gombra, hanem hogy kiderüljenek azok a hibák, amelyek később ügyfélpanaszt, elhagyott regisztrációt, hibás fizetést vagy rossz értékelést okozhatnak. Magánügyfélként ez különösen fontos, mert sokszor nincs külön fejlesztői csapat, tesztelési vezető vagy hosszú ellenőrzési folyamat. Ilyenkor egy tapasztalt tesztelő rövid idő alatt átnézheti a fő funkciókat, a képernyőket, az értesítéseket, a bejelentkezést és a háttérben futó működést.

Én azt látom, hogy sok megrendelő csak akkor kér alkalmazásellenőrzést, amikor már baj van. Például nem érkezik meg az e-mail, lefagy a felület, eltűnik egy adat, vagy a felhasználó nem tud továbblépni egy űrlapon. Pedig a távoli tesztelés ennél korábban is elvégezhető. A szakember megkapja az alkalmazás elérését, a tesztfiókot, a rövid leírást és a kívánt ellenőrzési pontokat. Ezután képernyőképekkel, videóval vagy írásos hibajegyzékkel adja át az eredményt.

Alkalmazás tesztelésének fő célja

Az alkalmazás tesztelésének fő célja az, hogy a felhasználó útja érthető, stabil és hibamentes legyen. Nem elég az, hogy a program elindul. Fontos, hogy az első képernyő világos legyen, a gombok működjenek, az adatok mentése megtörténjen, a fizetés vagy rendelés visszajelzése megjelenjen, és a rendszer ne viselkedjen kiszámíthatatlanul. Tapasztalatom szerint a kisebb hibák gyakran összeadódnak. Egy lassú betöltés még nem nagy ügy. Egy félreérthető gomb sem feltétlenül végzetes. De ha mindez egy regisztrációs folyamatban történik, az ügyfél könnyen feladja.

A tesztelés során a magán megrendelő általában nem elméleti jelentést vár. Gyakorlati választ szeretne. Mi működik. Mi nem működik. Hol akad el a felhasználó. Mit kell javítani először. Szerintem a jó alkalmazásteszt nem túl hosszú, de pontos. Nem az a lényeg, hogy húsz oldal készüljön róla, hanem hogy a fejlesztő vagy a tulajdonos azonnal értse, mi a hiba és hogyan lehet újra előidézni.

Online alkalmazásellenőrzés menete

Az online alkalmazásellenőrzés általában rövid egyeztetéssel indul. A megrendelő leírja, milyen alkalmazásról van szó, melyik részeket kell átnézni, milyen eszközökön fontos a működés, és van-e ismert probléma. A tesztelő ez alapján javasolhat teljes átnézést vagy célzott ellenőrzést. Célzott munka például a regisztráció, a bejelentkezés, a háttérben futó folyamatok, az értesítések, a fizetés, az űrlapok, a keresés vagy a jogosultságok vizsgálata.

A távoli munka előnye, hogy nem kell személyes találkozó. Az elérés átadható üzenetben, a tesztfiók külön létrehozható, a hibák pedig képernyőképpel és lépésről lépésre leírással rögzíthetők. Volt olyan eset, amikor egy ügyfél csak annyit mondott, hogy néha nem működik az alkalmazás a háttérben. A tesztelő végül azt találta meg, hogy az értesítés csak akkor veszett el, ha a felhasználó előtte kilépett, majd újra megnyitotta az alkalmazást. Ez apró részletnek tűnt, de a szolgáltatás szempontjából nagyon fontos volt.

A jó brief sok időt megspórol. Nem kell hosszú dokumentum. Elég néhány konkrét pont. Milyen eszközön kell próbálni. Milyen fiókkal. Melyik funkció fontos. Mi számít hibának. Kell-e videós bizonyíték. És milyen formában kéri a megrendelő az eredményt. Ha ezek nincsenek tisztázva, a munka könnyen félremegy.

Alkalmazás tesztelése árak

Az Alkalmazás tesztelése ára attól függ, mennyi képernyőt, funkciót és eszközt kell ellenőrizni. Egy egyszerű belépési és regisztrációs vizsgálat olcsóbb, mint egy teljes alkalmazásellenőrzés hibajegyzékkel, videóval és visszateszteléssel. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelő nem szán elég időt a különböző helyzetek kipróbálására. De a drága ajánlat sem mindig jobb. A lényeg az, hogy a feladat terjedelme és az átadott eredmény világos legyen.

Magánügyfélként érdemes úgy kérni ajánlatot, hogy a szakember külön jelezze, mit tartalmaz az ár. Benne van-e a hibák újratesztelése. Készül-e rövid összefoglaló. Lesznek-e képernyőképek. Hány eszközön nézi meg a működést. Így nem lesz vita abból, hogy a tesztelés csak egy gyors átnézés volt, vagy részletes ellenőrzés.

Tesztelő választása online munkához

Tesztelő választásakor nem csak az ár számít. Fontosabb, hogy a szakember hogyan gondolkodik a felhasználói folyamatról. Kérdez-e a célról. Érdekli-e, hogy ki használja az alkalmazást. Tud-e egyszerűen hibát leírni. Egy jó tesztelő nem csak azt írja, hogy nem működik. Azt is leírja, milyen lépések után jelent meg a hiba, milyen eszközön történt, milyen eredményt várt, és mi történt helyette.

A Qjob.hu felületén magánszemélyek is találhatnak olyan szabadúszót, aki távolról vállal alkalmazásellenőrzést. Érdemes a jelentkezőktől rövid példát kérni korábbi hibaleírásra vagy tesztjelentésre. Nem kell bizalmas anyag. Elég egy minta. Abból gyorsan látszik, hogy a tesztelő érthetően dolgozik-e. Sokan ott hibáznak, hogy csak technikai tapasztalat alapján választanak. Pedig a kommunikáció legalább ennyire fontos. Ha a szakember nem tudja világosan átadni a hibát, a fejlesztő sem biztos, hogy gyorsan javítani tudja.

Szerintem egy kisebb első feladat jó próba. Például csak a belépés, az értesítés vagy egy fő folyamat ellenőrzése. Ha az eredmény pontos, akkor lehet bővíteni a munkát. Ez biztonságosabb, mint rögtön teljes alkalmazástesztet rendelni ismeretlen embertől.

Gyakori hibák alkalmazástesztelésnél

A leggyakoribb hiba az, amikor a megrendelő túl általános feladatot ad. Például annyit ír, hogy nézze át az alkalmazást. Ez kevés. A tesztelő ilyenkor találhat hibákat, de nem biztos, hogy a legfontosabb részekre figyel. Jobb, ha a megrendelő megjelöli a kritikus pontokat. Regisztráció. Fizetés. Értesítés. Adatmentés. Profilmódosítás. Keresés. Ezekből már lehet használható teszttervet készíteni.

Másik gyakori gond, hogy nincs tesztfiók vagy nincs tiszta hozzáférés. A szakember idejének egy része ilyenkor nem tesztelésre megy el, hanem belépési problémákra. Ez drágítja a munkát és rontja az eredményt. A harmadik hiba a túl sok utólagos módosítás. Ha a megrendelő a munka közben folyamatosan új képernyőket és új funkciókat ad hozzá, a határidő és az ár is változhat. Ez nem rosszindulat kérdése, hanem egyszerű terjedelem.

Én azt látom, hogy a minőség ott javul igazán, ahol a hiba nem csak felsorolva van, hanem rangsorolva is. Kritikus, közepes, kisebb. Így a fejlesztő nem veszik el a részletekben. Egy rossz ikon vagy apró szöveghiba nem ugyanaz, mint egy sikertelen adatmentés.

Eredmény átadása és határidők

Az alkalmazás tesztelése után az eredményt célszerű egyszerű, követhető formában átadni. Ez lehet táblázat, rövid dokumentum, hibajegy lista vagy képernyőképekkel kiegészített leírás. A jó átadás tartalmazza a hiba nevét, a lépéseket, az elvárt eredményt, a tényleges eredményt és a bizonyítékot. Ha videó is készül, még könnyebb megérteni a problémát.

A határidő a munka méretétől függ. Egy kisebb ellenőrzés akár egy munkanapon belül elkészülhet. Egy részletesebb alkalmazásteszt több napot is igényelhet, főleg akkor, ha több eszköz, több fióktípus vagy több felhasználói út szerepel benne. De a gyorsaság nem lehet az egyetlen szempont. A kapkodó tesztelés gyakran csak a látványos hibákat találja meg. A háttérben futó problémákhoz türelem kell.

Az online kommunikáció legyen rövid és egyértelmű. A megrendelő adja át a szükséges hozzáféréseket, a tesztelő pedig jelezze, ha valami nem érthető. Nem kell felesleges kör. De kell nyoma annak, hogy mi volt a feladat és mi lett az eredmény.

Mikor érdemes háttértesztet kérni

Háttértesztet akkor érdemes kérni, ha az alkalmazás nem csak nyitott állapotban fontos. Sok szolgáltatásnál számít, hogy mi történik akkor, amikor a felhasználó bezárja, újranyitja, megszakítja az internetkapcsolatot, később folytatja a munkát, vagy értesítést kap. Ezek a helyzetek valósak. A felhasználó nem laborban használja az alkalmazást. Megáll, visszalép, vár, másik képernyőre vált, majd újra próbálkozik.

Az alkalmazásellenőrzés ilyen része gyakran több hibát mutat meg, mint a sima képernyőteszt. Például eltűnik a kitöltött űrlap. Duplán jelenik meg egy értesítés. A státusz nem frissül. Vagy a felhasználó visszakerül egy korábbi lépésre. Ezek apró működési zavaroknak tűnhetnek, de bizalmatlanságot keltenek. Egy magánügyfél számára ez pénzben is mérhető, mert a hibás folyamat miatt kevesebb rendelés, jelentkezés vagy kapcsolatfelvétel érkezhet.

Tapasztalatom szerint akkor jó a teszt, ha a végén nem csak hibák listája marad, hanem döntési alap. Mit kell azonnal javítani. Mit lehet később. Mi csak kényelmi probléma. És mi veszélyezteti közvetlenül a felhasználói eredményt.