Bevezető

Egy vállalat HR rendszere nemcsak dolgozói adatokat tárol – bizalmat is kezel. Ha a jogosultságkezelésben hiba van, az nem csupán technikai probléma: adatvédelmi incidens, reputációs kár és jogi következmény is lehet belőle.

Ebben az esettanulmányban bemutatjuk, hogyan zajlott egy valós, összetett tesztelési projekt, ahol a cél az volt, hogy a HR rendszer új, LDAP és RBAC-alapú jogosultságkezelése hibátlanul működjön.

Háttér

Egy 800 főt foglalkoztató vállalat döntött úgy, hogy megújítja belső HR rendszerét. A korábbi, sok kézi beállítást igénylő jogosultságkezelés helyett szerepkör-alapú (RBAC) modellt vezettek be, LDAP integrációval.

Ez több mint ötven különböző szerepkört jelentett – a gyakornoktól a HR-vezetőig –, mindegyikhez eltérő hozzáférési szabályokkal. A cél egy átlátható, szabályozott rendszer volt, amely megfelel a GDPR és a belső auditkövetelmények előírásainak.

Ez egy „nem hibázhatunk” típusú projekt volt. Egy rossz jogosítás akár több száz dolgozó béradatait is láthatóvá tehette volna.”

A tesztelési csapat

A projektben tizenegyen dolgoztunk a tesztelési oldalon. A csapat nemcsak tesztelőkből állt: üzleti elemzők, HR-esek, biztonsági szakértő és DevOps kolléga is részt vett benne.

A tesztelés így valódi keresztfunkcionális együttműködéssé vált.

• Tesztvezető – stratégia, ütemezés, riportálás
• Manuális tesztelők (5 fő) – valós élethelyzetek modellezése
• Automata tesztelő – API-szintű jogosultságvizsgálat
• Biztonsági szakértő – GDPR és hozzáférési audit
• DevOps – környezetek, adatvisszaállítás
• HR szakértők (2 fő) – üzleti logika és szerepkörvalidálás

A HR csapat bevonása különösen fontos volt: ők pontosan tudták, ki mit láthat, és mi számít tiltott adatnak.

A kihívás: komplexitás és adatbiztonság

A tesztelés igazi nehézsége nem a technológia volt, hanem a mennyiség és a változás.

Ötven szerepkör, több ezer lehetséges kombináció, és közben folyamatosan módosuló specifikáció. A fejlesztés alatt új szerepkörök kerültek be, másokat összevontak vagy megszüntettek. Egy kézi tesztelésre épülő megközelítés itt napok alatt kezelhetetlenné vált volna.

Ehhez jött az adatoldali probléma: a régi rendszerből áthozott adatok között voltak hibás vagy duplikált rekordok, ami a jogosultságok ellenőrzését torzíthatta volna.

A csapatnak olyan megoldást kellett találnia, ami strukturált, ismételhető és automatizálható.

A stratégia: rendszerszintű megközelítés

Az első lépés az volt, hogy minden szerepkör jogosultságait döntési táblákban rögzítettük. Ezekben soronként szerepelt, hogy egy adott felhasználói típus mit tehet meg: beléphet-e, láthat-e adatot, módosíthat-e, exportálhat-e, vagy elérheti-e más dolgozók rekordjait.

Például:

Szerepkör	Művelet	Várható eredmény
Team Lead	Csapattag teljesítményértékelésének megnyitása	Siker
Team Lead	Más osztály dolgozójának megnyitása	Tiltva

Minden ilyen logikai sorhoz létrehoztunk egy tesztesetet, amely tartalmazta a várható eredményt is.

Ez biztosította, hogy a tesztelés ne csak ellenőrzés, hanem verifikálható bizonyítás is legyen: minden szabály dokumentálva, minden eredmény visszakereshető.

Automatizálás: Postman, Newman, CI

Az API volt a rendszer “igazságforrása” – itt dőlt el, ki mit tehet. Ezért a tesztelés kulcseleme az API-szintű automatizálás lett.

A Postmanben létrehozott tesztkollekciók minden szerepkörre külön tokennel futottak le.

A hívások várt státuszkódokat ellenőriztek (pl. 200 OK a jogos, 403 Forbidden a tiltott eseteknél), és a Newman segítségével automatikusan lefutottak a CI pipeline-ban.

Az eredményeket automatikus riportok gyűjtötték, így a fejlesztők és a vezetőség valós időben látták, mely szerepkörök felelnek meg az elvárásoknak.

Ez az automatizálási réteg rengeteg időt spórolt meg, és lehetővé tette, hogy minden build után regressziós jogosultsági teszt fusson le automatikusan.

Tesztadatok és környezetek

A teszteléshez több tucat felhasználót kellett létrehozni, különböző szerepkörökkel és szervezeti hierarchiákkal. Ezt egy Python-alapú adatgeneráló szkript kezelte, amely maszkolt, de valósághű adatokat állított elő, majd feltöltötte a tesztadatbázisba. Így minden futás előtt tiszta, ismételhető állapotból tudtunk indulni. Ez elengedhetetlen volt ahhoz, hogy az automatizált API-tesztek konzisztens eredményt adjanak.

Átláthatóság és nyomon követhetőség

A projekt során kiemelten kezeltük a traceability-t: minden követelményhez hozzárendeltünk egy vagy több tesztet, és minden teszthez logolt eredményt. Ezt Jira + Xray, Jenkins, Git kombinációval valósítottuk meg, a dokumentációt Confluence-ben vezettük.

A rendszerlogokat Grafana dashboardon követtük, ahol a hibák és lefedettségek valós időben láthatóak voltak.

Ez a fajta átláthatóság kulcsfontosságú volt, mert a vezetőségnek auditálható bizonyítékot kellett kapnia arról, hogy a rendszer valóban megfelel az adatvédelmi elvárásoknak.

Eredmények és tanulságok

A tesztelés során összesen 37 hibát találtunk, ebből 5 volt kritikus. Mindet a határidő előtt sikerült javítani, és az élesítés után nem történt egyetlen adatvédelmi incidens sem.

A HR csapat visszajelzése szerint az új rendszer végre átlátható, és pontosan tudják, ki mit láthat. A fejlesztők értékelték, hogy a tesztelés automatizált és ismételhető, a menedzsment pedig megnyugodott: a jogosultsági rendszer stabil és auditálható.

Összegzés

Ez a projekt jól rávilágított arra, hogy a tesztelés nem csupán hibakeresés, hanem kockázatkezelés és stratégiai tervezés is. A döntési táblák, az automatizálás és az üzleti oldal bevonása együtt biztosították, hogy a rendszer ne csak működjön, hanem biztonságos és átlátható is legyen.