Alkalmazás tesztelése különböző hozzáférési jogosultságokkal – Bízd ránk a biztonságod!

Jogosultságtesztelés magánügyfeleknek

A jogosultságtesztelés azt mutatja meg, hogy egy alkalmazás csak azokhoz az adatokhoz és funkciókhoz enged hozzáférést, amelyekhez valóban szabad. Ez különösen fontos akkor, ha az alkalmazásban felhasználói fiókok, rendelési adatok, fizetéshez kapcsolódó nézetek, belső üzenetek vagy személyes beállítások vannak. A magánügyfél ilyenkor nem céget keres, hanem olyan tesztelőt, aki távolról, érthető feladatleírás alapján végignézi a jogosultsági helyzeteket, és használható hibajegyzéket ad vissza.

Én azt látom, hogy sok hibás működés nem a látványos részeken derül ki. Nem ott, ahol a gomb nem működik. Hanem ott, ahol egy vendégfelhasználó mégis lát egy belső oldalt, egy normál felhasználó adminisztrációs műveletet tud indítani, vagy egy régi munkamenet túl sokáig aktív marad. A hozzáférési teszt ezért nem csak technikai ellenőrzés. Ez bizalmi kérdés is. Ha a felhasználó olyat lát, amit nem kellene, akkor a szolgáltatás megbízhatósága azonnal romlik.

A Qjob.hu felületén olyan magánszakemberek is elérhetők, akik online munkában vállalnak alkalmazásellenőrzést, jogosultsági hibák keresését és egyszerű, érthető tesztjelentés készítését. Itt a megbízó általában képernyőképeket, tesztfiókokat, rövid leírást és elvárt szerepköröket ad át. A szakember ezek alapján vizsgálja, hogy a rendszer mit enged és mit tilt.

Hozzáférési ellenőrzés szerepkörök szerint

A hozzáférési ellenőrzés alapja a szerepkör. Más jogosultság jár egy vendégnek, egy regisztrált felhasználónak, egy előfizetőnek, egy szerkesztőnek vagy egy adminisztrátornak. A tesztelőnek először azt kell megértenie, hogy ezek a szerepek mit tehetnek meg. Ez nem mindig egyértelmű. Sok ügyfél csak annyit ír, hogy az admin mindent láthat, a felhasználó pedig csak a saját adatait. Ez kezdésnek jó, de teszthez kevés.

Szerintem a jó feladatleírás rövid, de pontos. Tartalmazza, hogy melyik fiók milyen szerepű, melyik képernyőt láthatja, milyen műveletet indíthat, mit nem módosíthat, és mikor kell hibaüzenetet kapnia. Ha ez nincs meg, a szakember először kérdéseket tesz fel. Ez nem lassítás. Inkább védelem a félreértések ellen.

A jogosultságtesztelés során érdemes külön megnézni a belépés utáni állapotot, a kijelentkezést, a lejárt munkamenetet, a közvetlen hivatkozások megnyitását, a régi képernyők frissítését és a tiltott műveletek próbáját. Ezeknél gyakran előjönnek olyan hibák, amelyek normál kattintgatással nem látszanak.

Jogosultságtesztelés árak és munkamennyiség

Az ár főleg attól függ, hány szerepkört, hány képernyőt és hány műveletet kell ellenőrizni. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a szakember csak a legfeltűnőbb hibákat nézi meg. A jogosultsági hibák viszont sokszor apró lépésekből jönnek elő. Kell hozzá türelem, rendszeresség és pontos jegyzetelés.

Tapasztalatom szerint egy kisebb ellenőrzés néhány órát vesz igénybe, de egy összetettebb hozzáférési teszt akár több munkanapot is kérhet. Nem azért, mert a szakember lassú. Azért, mert minden szerepkört külön kell kezelni. Egy hiba csak akkor bizonyítható, ha a lépések ismételhetők.

Megfelelő tesztelő kiválasztása

A megfelelő tesztelő nem csak hibát keres, hanem érthetően leírja, mi történt. Ez magánügyfélként nagyon fontos. A fejlesztőnek vagy az alkalmazást készítő személynek nem elég annyit kapnia, hogy rossz a jogosultság. Kell a pontos útvonal, a használt fióktípus, a várt eredmény és a tényleges eredmény. Így lehet javítani.

Érdemes olyan szakembert választani, aki kér mintát a szerepkörökről, rákérdez a tesztkörnyezetre, és nem ígéri meg látatlanban, hogy mindent teljesen átnéz egy óra alatt. A jogosultságtesztelés nem gyors szemrevételezés. Van benne logika, ismétlés és dokumentálás.

Sokan ott hibáznak, hogy csak az árat nézik. A legolcsóbb ajánlat elsőre kényelmesnek tűnik, de ha a jelentés homályos, akkor később újra kell teszteltetni. Én inkább azt nézném meg, hogy a tesztelő tud-e példát mutatni hibajelentésre. Nem kell bizalmas anyagot kérni. Elég egy minta, amelyből látszik a gondolkodásmód.

Online munkafolyamat és eredményátadás

Az online munkafolyamat általában egy rövid egyeztetéssel indul. A megbízó átadja a tesztelhető alkalmazás elérését, a tesztfiókokat, a szerepkörök leírását és a fontosabb felhasználói útvonalakat. A szakember ezután különböző fiókokkal próbálja végig ugyanazokat a képernyőket. Megnézi, mi látható, mi módosítható, milyen hibaüzenet jelenik meg, és mi történik kijelentkezés után.

A munka távolról is jól végezhető, ha az anyagok rendezettek. Nem kell személyes találkozó. Kell viszont stabil kapcsolat, működő tesztfiók, világos határidő és egy hely, ahová a hibákat rögzíteni lehet. Ez lehet táblázat, dokumentum vagy hibakezelő rendszer. A lényeg az, hogy a fejlesztő később vissza tudja követni a lépéseket.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy csak a belépési képernyővel van gond. A teszt közben derült ki, hogy kijelentkezés után egy korábban megnyitott oldal frissítéssel még mindig betöltötte a személyes adatokat. Ez nem látványos hiba, de kellemetlen. A javítás után újra kellett nézni a munkamenetet és a gyorsítótárazott nézeteket is.

Gyakori hibák jogosultságtesztelés közben

A leggyakoribb hiba az, hogy a megbízó nem ad elég szerepkört a teszteléshez. Egyetlen admin fiókkal nem lehet jogosultsági hibákat feltárni. Kell normál felhasználó, korlátozott felhasználó, új fiók, régi fiók, esetenként letiltott vagy lejárt hozzáférésű fiók is. Minél több állapot van az alkalmazásban, annál fontosabb a pontos minta.

Másik gyakori gond, hogy a teszt csak a látható menüre terjed ki. De a tiltott hozzáférés sokszor nem a menüből indul. Egy régi hivatkozás, egy másik felhasználótól kapott cím, egy böngészőben mentett oldal vagy egy alkalmazáson belüli visszalépés is előhozhat hibát. A szakembernek ezért nem csak rendesen kell használni a rendszert, hanem kicsit kényelmetlen módon is. Ott jönnek elő a problémák.

Az is gond, ha a megbízó minden hibát azonos súlyúnak vesz. Egy rossz gombfelirat nem ugyanaz, mint amikor egy idegen rendelés megjelenik. A jó jelentés külön választja a kisebb használhatósági gondot, a közepes jogosultsági problémát és a súlyos adathozzáférési hibát.

Minőség és javítás utáni ellenőrzés

A minőség nem ott látszik, hogy hány hibát talál a tesztelő. Inkább abban, hogy a leírt hibák javíthatók-e. Egy hasznos jelentés rövid, de nem hiányos. Tartalmazza a környezetet, a fióktípust, a lépéseket, a várt viselkedést, a tényleges eredményt és lehetőleg képernyőképet. Ha a hiba csak bizonyos helyzetben jön elő, azt külön jelezni kell.

A hozzáférési teszt után gyakran szükség van újratesztelésre. Ez nem felesleges kör. A javítás néha új hibát hoz be. Például egy fejlesztő lezár egy tiltott oldalt, de közben egy jogos felhasználó sem fér hozzá. Vagy az admin felület működik, de a normál felhasználó saját adatai is eltűnnek. Emiatt a javítás utáni ellenőrzés sokszor ugyanannyira fontos, mint az első vizsgálat.

Szerintem a jó eredmény az, amikor a megbízó nem csak egy hibajegyzéket kap, hanem tisztábban látja a rendszer működését is. Tudja, melyik szerepkör mit tehet, hol volt bizonytalanság, mit kell fejlesztővel tisztázni, és mi az, ami már rendben működik. Egy magánszakember ebben sokat segíthet, ha a munka elején pontos kereteket kap, a végén pedig ellenőrizhető formában adja át az eredményt.