WebView és külső linkek hibátlan működésének tesztelése és fejlesztése

WebView tesztelés magánügyfeleknek

A WebView tesztelés akkor hasznos, ha egy alkalmazásban webes tartalom, külső hivatkozás, fizetési oldal, űrlap vagy beágyazott oldal működését kell ellenőrizni. A cél egyszerű. A felhasználó ne akadjon el, a link ne vigye rossz helyre, a tartalom ne törjön szét, és az alkalmazás ne viselkedjen másként különböző készülékeken. Magánügyfélként nem mindig kell teljes fejlesztői csapat. Sokszor elég egy tapasztalt tesztelő, aki távolról átnézi az alkalmazást, dokumentálja a hibákat, és érthető javaslatot ad a javításra.

Én azt látom, hogy a legtöbb hiba nem a látványos részeken jelenik meg. Inkább ott, ahol a felhasználó egy gombra kattint, belép egy külső oldalra, majd visszatérne az alkalmazásba. Ilyenkor előfordulhat, hogy a hivatkozás új ablakban nyílik meg, nem tölt be, rossz nyelvű oldalra vezet, vagy a visszalépés után az alkalmazás elveszíti az állapotát. Ez bosszantó, főleg akkor, ha a felhasználó már kitöltött egy űrlapot vagy fizetés előtt áll.

A Qjob.hu felületén olyan magánszakembert lehet keresni, aki online végez ilyen ellenőrzést. A munka általában távolról zajlik. A megbízó elküldi a tesztelhető verziót, a belépési adatokat, a fő folyamatokat és az elvárt viselkedést. A szakember ezután különböző készülékeken, böngészőmotorokon és hálózati helyzetekben nézi meg a WebView működését.

WebView ellenőrzés külső hivatkozásoknál

A külső hivatkozások vizsgálata külön része a feladatnak. Nem elég megnézni, hogy a link megnyílik. Azt is ellenőrizni kell, hogy a megfelelő oldal töltődik be, a biztonságos kapcsolat működik, a visszalépés rendben van, és a felhasználó nem kerül ki végleg az alkalmazásból. Ha egy külső fizetési oldal, dokumentum, közösségi felület vagy ügyfélkapu nyílik meg, akkor a tesztelés még fontosabb.

Szerintem itt a leggyakoribb félreértés az, hogy a megbízó csak egy gyors kattintáspróbát vár. De a külső linkeknél több állapotot kell nézni. Mi történik gyenge kapcsolatnál. Mi történik akkor, ha a céloldal lassú. Mi történik, ha a felhasználó megszakítja a folyamatot. És mi történik akkor, ha ugyanaz a hivatkozás egyik eszközön jól működik, a másikon pedig hibásan jelenik meg.

Az online alkalmazástesztelés során a szakember általában képernyőképekkel, rövid videókkal és hibaleírással adja át az eredményt. Jó esetben nem csak azt írja le, hogy valami rossz, hanem azt is, mikor, milyen lépésekkel és milyen környezetben jött elő a hiba. Ez később sok időt takarít meg a fejlesztésnél.

WebView tesztelés árak és munkadíjak

Az ár főleg attól függ, hány képernyőt, hány linket, hány eszközt és hány forgatókönyvet kell ellenőrizni. Egy kisebb WebView alapú alkalmazás gyors átnézése olcsóbb, mint egy fizetési folyamattal, bejelentkezéssel és külső dokumentumokkal dolgozó rendszer vizsgálata. Tapasztalatom szerint a túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelő csak végigkattint néhány oldalt, de nem keresi meg a rejtettebb hibákat.

A táblázat csak irányadó. Egy konkrét ajánlatnál fontos, hogy a megbízó pontosan leírja a feladatot. Hány oldal van. Hány külső hivatkozás szerepel. Van e belépés. Kell e fizetési teszt. Szükséges e képernyőfelvétel. Minél tisztább a leírás, annál pontosabb a díj.

WebView szakember kiválasztása

A megfelelő szakember kiválasztásánál nem csak az ár számít. Érdemes megnézni, hogy dolgozott e már mobilalkalmazásokkal, hibrid megoldásokkal, beágyazott webes felületekkel és külső hivatkozásokkal. A jó tesztelő nem csak hibát keres. Rendszerben gondolkodik, és megérti, hogy a felhasználó mit szeretne elérni.

Én azt javaslom, hogy a megbízó kérjen rövid példát korábbi hibajelentésre. Nem kell bizalmas anyag. Elég egy névtelen minta, amiből látszik, hogyan írja le a szakember a hibát. Egy gyenge leírás annyi, hogy a gomb nem működik. Egy hasznos leírás megadja a lépéseket, az eszközt, az alkalmazásverziót, a várt eredményt és a tényleges eredményt.

Fontos a kommunikáció is. A távoli tesztelés akkor működik jól, ha a felek gyorsan tisztázzák a kérdéseket. Például melyik verziót kell nézni, melyik link számít külsőnek, milyen felhasználói szerepeket kell kipróbálni, és mikor számít lezártnak a munka. Egy magánügyfélnek ez sokszor új helyzet. De nem kell bonyolítani. Egy egyszerű leírás, néhány kép és a hozzáférés már elég lehet az induláshoz.

WebView teszt folyamata távolról

A munka első lépése a rövid egyeztetés. A megbízó elküldi az alkalmazás elérhetőségét, a telepítési módot, a belépési adatokat és a fontos útvonalakat. Ezután a tesztelő összeállít egy egyszerű ellenőrzési listát. Ebben szerepelhet a betöltés, a linknyitás, a visszalépés, az űrlapkitöltés, a hibakezelés és a külső oldalról való visszatérés.

A WebView tesztelés közben a szakember rögzíti a hibákat. Jó esetben minden hibához tartozik egy rövid cím, a hiba súlya, a pontos lépéssor, a várt működés és a tényleges működés. A képernyőfelvétel sokszor többet ér, mint egy hosszú magyarázat. Főleg akkor, ha a hiba csak bizonyos sorrendben vagy csak bizonyos eszközön jelenik meg.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy a fizetési oldal rendben működik, mert a fő hivatkozás megnyílt. A teszt során kiderült, hogy sikeres fizetés után a visszatérő oldal nem töltődött be az alkalmazáson belül. A felhasználó csak egy üres képernyőt látott. A hiba nem volt látványos a kezdeti próba során, de valódi használatnál komoly gondot okozott volna.

A végeredmény általában egy hibajegyzék vagy rövid jelentés. Ebben a hibák sorrendben szerepelnek. Előre kerülnek azok, amelyek akadályozzák a vásárlást, a belépést, az adatküldést vagy a visszatérést. A kisebb vizuális eltérések hátrébb kerülnek. Ez segít abban, hogy a fejlesztő ne találgatással kezdjen.

Külső linkek és biztonsági szempontok

A külső linkeknél nem csak a használhatóság számít. A biztonság is lényeges. Egy WebView nem engedhet be tetszőleges tartalmat ellenőrzés nélkül. A szakember ilyenkor megnézi, hogy a hivatkozások megbízható címekre vezetnek e, van e nem kívánt átirányítás, működik e a biztonságos kapcsolat, és a felhasználó nem kerül e kockázatos oldalra.

Sokan ott hibáznak, hogy minden külső oldalt ugyanúgy kezelnek. Pedig más egy súgóoldal, más egy fizetési felület, és más egy fájlletöltés. A tesztelésnél ezek külön esetek. A letöltésnél fontos, hogy a fájl elérhető e. A fizetésnél fontos, hogy a megszakított folyamat után mi történik. Egy bejelentkezési oldalon pedig az a kérdés, hogy az alkalmazás megtartja e a munkamenetet, vagy újraindul az egész folyamat.

A biztonsági ellenőrzés nem mindig jelent mély kódelemzést. Magánügyfeleknél sokszor elég egy gyakorlati vizsgálat. A tesztelő jelzi, ha gyanús átirányítást, kevert tartalmat, hibás tanúsítványt, rossz jogosultságkezelést vagy zavaros visszatérési pontot talál. Ez nem helyettesít egy teljes biztonsági auditot, de sok kellemetlen hibát kiszűrhet.

Gyakori hibák WebView munka előtt

A leggyakoribb probléma a hiányos feladatleírás. A megbízó azt írja, hogy nézd meg az alkalmazást, de nem mondja el, melyik részek a fontosak. Így a tesztelő vagy túl sok időt tölt kevésbé lényeges képernyőkkel, vagy kihagy egy kritikus folyamatot. Ez mindkét félnek rossz.

Jobb, ha a megbízó röviden leírja a fő célt. Például a felhasználó nyissa meg az alkalmazást, lépjen be, kattintson a külső dokumentumra, térjen vissza, majd küldjön el egy űrlapot. Ilyen leírás mellett a távoli minőségellenőrzés gyorsabb és pontosabb lesz.

Másik hiba, amikor a megbízó csak egy készüléken gondolkodik. A WebView viselkedése eltérhet rendszerverzió, képernyőméret, alapértelmezett böngésző és hálózati állapot szerint. Nem kell minden létező eszközt bevonni, de legalább néhány eltérő környezetet érdemes kipróbálni.

A harmadik gond az, hogy nincs idő az újratesztelésre. Pedig javítás után újra kell nézni a hibát. Néha a javítás megold egy problémát, de létrehoz egy másikat. Ezért érdemes a munka elején tisztázni, hogy az ellenőrzés tartalmaz e ismételt próbát, vagy az külön feladat lesz.

WebView hibák átadása és javítási döntések

A WebView hibák átadása akkor hasznos, ha a jelentés alapján a fejlesztő vagy a megbízó gyorsan tud dönteni. Nem minden hibát kell azonnal javítani. Egy félrecsúszott kép kevésbé sürgős, mint egy hibás fizetési visszatérés vagy egy nem működő külső hivatkozás. A jó jelentés ezért nem csak listáz, hanem sorrendet is ad.

A tesztelő munkája itt különösen értékes. Meg tudja különböztetni a zavaró, a fontos és a kritikus hibákat. Szerintem ez az egyik legnagyobb előnye annak, ha nem csak ismerősökkel próbáltatjuk ki az alkalmazást. Egy laikus felhasználó megmondja, hogy valami furcsa. Egy tapasztalt szakember azt is leírja, hogyan lehet a hibát megismételni.

A végső anyag lehet egyszerű táblázat, hibajegyrendszerbe rendezett lista vagy rövid szöveges összefoglaló. A lényeg, hogy tartalmazza a szükséges adatokat. Melyik képernyőn történt a hiba. Melyik hivatkozás érintett. Milyen eszközön jelent meg. Mi volt az elvárt működés. Mi történt helyette. Ha ezek megvannak, az online tesztelési munka valódi segítséget ad, nem csak általános véleményt.