2011 tesztelési kihívása – InterGiro 2 átállás a magyar bankokban

A legtöbb tanácsadó céget mindig lázba hozza, ha egy teljes szektort érintő változásban játszhat szerepet. Bankszektorban egy ideje nem volt ekkora koordinációt igénylő feladat, mint annak idején a nemzetközi számviteli sztenderdeknek, vagy a BASEL irányelveknek való megfelelés. Az egyértelmű üzleti igények mellett talán ez a kíváncsiság volt, amiért 2010-ben kiemelt figyelmet szenteltünk a napon belüli forint átutalások témakörének.

Az Euró-zónához való csatlakozás egyik következő lépése, hogy a devizautalásokhoz hasonlóan a belföldi forint átutalásokat is egy speciális formátumban kezeljük, illetve az EU más országaihoz hasonlóan napon belül teljesüljenek a megbízásaink. 2012 közepétől ezért a mostani napi egy helyett a bankoknak naponta 5-ször kell az utalásaikat meneszteni, és mindezt SEPA (Single European Paymnet Area) formátumban. A megbízásoknak 4 órán belül teljesülnie kell, illetve a megbízás befogadása, és a kedvezményezett bank MNB számlájának jóváírása között telhet el maximum 4 óra. A feladat komplexitását jól mutatja, hogy formátumváltozás mögött az összes kapcsolódó payment folyamatot át kell nézni, és az új lehetőségekhez, szabályokhoz igazítani. A kihívás tehát egy erős informatikai változás, amit részben az új formátum, és adattartalom, részben pedig a megváltozott üzleti folyamatok generálnak.

A feladat üzleti tartalmának és a SEPA formátum informatikai kihívásainak részletezéséhez persze egy rövid cikk igen szűk lehetőséget biztosít, a legfontosabb kihívásokat a következő fólia szemlélteti:

A feladat sikeres végrehajtását a GIRO Zrt. egy Országos Projekt létrehozásával segíti, mely a klíringtagoknak nyújt praktikus értelmezési segítséget, és fórumot biztosít a felmerülő kérdések kompetens megválaszolására, az MNB az átállási folyamat, és a jövőbeni fizetésforgalom szabályozásáról gondoskodik. 

A banki projektek sikeressége, vagyis, hogy az egyes pénzintézetek a kötelező minimum követelmények teljesítése mellett mennyire tudják kihasználni az új szabályozás lehetőségeit, erősen függ a tesztelési feladatok körültekintő lebonyolításától.

Az Országos Projekt ütemezése szerint a banki belső teszteknek szeptember folyamán meg kell kezdődniük, hogy a próbatesztekre felkészítsék a résztvevő klíringtagokat. Meggyőződésünk, hogy ennek a projektnek a tesztelési része kiemelkedő prioritást élvez. Egyrészről, mivel több rendszert és szervezeti egységet átívelő tesztesetekről kell beszélnünk, másrészt már maguk a tesztek sem maradhatnak bankon belül, hiszen az alkalmazni kívánt platform a fizetésforgalom működtetéséről szól. Tapasztalat alapján azt gondolom, hogy a banki projektek tesztfázisai a mérföldkőhöz közeledve mindig lerövidülnek, vagyis leginkább hibajavításra használják, pedig a jól tervezett tesztesetek végrehajtása a hibajavítások iteratív folyamatát is lerövidíti. Az InterGiro2 átállás kapcsán a tesztelésnek azért is kiemelt szerepe van, mert a bank core-tevékenységéhez kapcsolódik, és mint ilyen, a legnagyobb prioritás kell élvezze. Nem életszerű ugyanis a helyzet, mikor a bank lakossági vagy vállalati ügyfeleinek fizetésforgalmi szolgáltatásai szünetelnek egy banki hiba miatt. Ezért tartom fontosnak az IG2 átállás kapcsán a tesztelési fázis kiemelt fontosságát hangsúlyozni. 

A tesztelési feladatok egyik része automatizálható nagy mennyiségű, rutinszerű szabályok mentén futtatható ellenőrzések, melyek esetében a tervezés során meggondolandó, hogy érdemes akár egy költségesebb teljesen automatizált teszt folyamat felállítása, mely a későbbi tesztek során megtérülhet. A tesztelési feladatok másik része pedig a hibás üzenetek mögötti üzleti folyamatok javítására vonatkozik. A megközelítőleg 10 hónap átfutású tesztelési fázis tehát számos különböző profilt kíván, a rutinszerű tesztek futtatásától a bonyolult hibaüzenetek üzleti elemzéséig. 

Már a tesztelési felkészülés során nagy figyelmet kell fordítani a tesztesetek tervezésének és előkészítésének. Az IG2 által kialakított vagy megváltoztatott funkciók a bank összes, átutalásokkal közvetlenül vagy közvetett módon érintett folyamataira hatással vannak. A tesztelésnek, és így a teszteseteknek nemcsak a klasszikus funkcionalitás-integráltság-teljesség hármasnak kell megfelelnie, hanem speciális szempontoknak is. Ezek a speciális szempontok a terhelhetőség és az üzleti folyamatok teljessége. 

A fenti gondolatmenetet követve a tervezhető tesztelési fázisok és azok IG2 specifikus tartalma:

Funkcionális tesztelés

Az elkészült kód és paraméterezés első próbája. Ebben a szakaszban a tesztelés fő fókusza az alapvető funkcionalitás: a megváltozott képernyők, új paraméterek, kivonatok és az új IG2 interfész működése. Az egyes funkciók tesztelése külön-külön történik, a teszt elvárt eredménye, hogy az egyes leszállított rendszerelemek a dokumentációban előírtaknak megfelelően működnek. 

Természetesen a meglévő funkciók tesztelésén túl figyelmet kell fordítani a folyamatváltozásból fakadó, újonnan kezelendő funkciókra, mint például a visszahívás típusú üzenetekre vagy a fedezetbiztosítási időablakok változására. A kötelező és opcionális új folyamatok tesztelésén túl ki kell térni a hibalehetőségek kezelésére, hiszen eddig a bankok számára hiba esetén egy egész éjszaka állt rendelkezésre a javításra. A napi 5 cut off kötelezettséggel azonban csupán percei lesznek a javításra, ezért a hibaágak kezelésére csak pár perc marad. Az automatizálás kidolgozása komoly sikertényező lehet.

Integrációs tesztelés

A tesztelés következő szakaszban már egy integrált tesztkörnyezetben történik. Az egyes rendszerek és interfészek egymással összekapcsolva integrált rendszerként viselkednek. Ebben a fázisban nyílik lehetőség end-to-end tesztelésre, amikor a teljes megváltozott üzleti folyamat tesztelhető. Ahogy korábban is említettem fontos, hogy a tesztelés ne csak az egyes funkciókra, hanem a teljes érintett üzleti folyamatcsoportra kiterjedjen. Át kell szervezni a mező mappinget is, mert jelenleg a számlavezető rendszerek, ha egy mezőben nem kapnak adatot, hibásnak minősítik az üzenetet. Az opcionális mezők kötelező fogadásával azonban reguláris folyamat lesz, hogy egyes esetekben nem kap adatot az adott mezőben a core rendszer. A rendszerek támasztotta informatikai korlátok vizsgálata szintén elengedhetetlen, hiszen nem csak új mezők, hanem a meglévő mezők változásaival is számolni kell. Ilyen lesz például a közlemény mező, aminek a hossza változik, és néhány, magyar bankokban használt számlavezető rendszernél komoly változást indukál a fejlesztése. Ezen mezőváltozások rendszerek közötti (core rendszer – payment rendszer – GIRO háló) tesztelése megkönnyíti az átállást. 
Az integrációs teszt részeként szükséges regressziós tesztet is végezni, kizárandó, hogy a változtatás nem várt hatással van a rendszer átutalásokhoz nem kapcsolódó folyamataira.

Terheléses tesztelés

Az IG2 változás egyik leghangsúlyosabb eleme a napi egyszeri helyett bevezetésre kerülő napi ötszöri átutalásindítás. Ennek a változásnak rendkívül nagy hatása van az átutalási folyamatokat támogató rendszerekre. Megtörténhet, hogy egy átutalási csúcsnapon a rendszereknek a normál átutalási mennyiség 5-10-szeresét kell feldolgozniuk úgy, hogy az MNB által előírt 4 órás átutalási ablak ne sérüljön.

Szerző:Kókai János