A bankok esetében a tesztautomatizálás ritkán csupán költségcsökkentési kezdeményezés. Az automata tesztelés támogatja a gyorsabb kiadásokat, a megbízhatóbb digitális szolgáltatásokat, a fokozott működési ellenálló képességet, valamint lehetővé teszi azon hibák korai felismerését, amelyek egyébként eljuthatnának az éles környezetbe. Ennek ellenére a pénzügyi megtérülés igazolása meglepően nehéz feladat lehet. Cikkünkben azt vizsgáljuk, hogyan mérhető a tesztautomatizálás megtérülése (ROI) a bankszektorban – a költségmegtakarítástól és a gyorsabb kiadásoktól kezdve a kockázatok csökkentésén és az ellenálló képességen át egészen a teljesítményig.
A banki rendszerek olyan környezetben működnek, ahol a szoftverhibák azonnali üzleti következményekkel járhatnak. Egy fizetési folyamat, hitelesítési szolgáltatás, mobilbanki alkalmazás, tranzakciós platform vagy alapvető banki integráció hibája több ezer ügyfelet érinthet, és jelentős operatív munkát igényelhet. A csúcsterhelés alatti teljesítményromlás ugyanolyan káros lehet, még akkor is, ha az alapul szolgáló funkciók technikailag helyesek.
A tesztelés tehát két alapvetően különböző módon teremt értéket. Az első a hatékonyság: az ismétlődő manuális munka csökkentése és a regressziós tesztelés felgyorsítása. A második a kockázatcsökkentés: a problémák feltárása, mielőtt azok az ügyfeleket, a tranzakciókat, a szabályozási kötelezettségeket vagy a kritikus szolgáltatásokat érintenék. Egy realisztikus megtérülési modellnek mindkettőt mérnie kell.
Az alapvető ROI-képlet egyszerű:
ROI = (Generált érték − Befektetés) / Befektetés × 100
A kihívás abban rejlik, hogy meghatározzuk, mi tartozik az egyenlet mindkét oldalára. Egy reális számítás magában foglalhatja az automatizálási keretrendszer fejlesztését, a licencek és platformköltségeket, az infrastruktúra és a tesztkörnyezetek költségeit, a CI/CD integrációt, a tesztadatok előkészítését, a speciális mérnöki erőforrásokat, a képzést, a jelentéskészítést, a monitorozást és a folyamatos tesztkarbantartást.
Az automatizált tesztek szoftvereszközök. Ahogy az alkalmazások, API-k, felhasználói felületek, üzleti szabályok és integrációk fejlődnek, a teszteknek is velük kell fejlődniük. Egy automatizálási program, amely az első évben olcsónak tűnik, költségessé válhat, ha a szkriptek törékenyek vagy nehezen karbantarthatók. A ROI-t ezért az automatizálás teljes életciklusa alatt kell mérni, nem csak a megvalósításkor.
A csökkentett manuális végrehajtás továbbra is az egyik legkönnyebben számszerűsíthető előny. Tegyük fel, hogy egy banki regressziós csomag kiadásonként 500 órányi manuális tesztelést igényel, és a szervezet évente tíz fő regressziós ciklust hajt végre. Ez körülbelül 5000 órányi manuális végrehajtást jelent. Az automatizálás jelentős részét kiküszöbölhetné ennek az erőfeszítésnek.
Azonban félrevezető lenne mind az 5000 órát pénzügyi megtakarításként kezelni. Az automatizált csomagok továbbra is monitorozást, karbantartást, hibaelemzést, környezetkezelést és tesztadatok előkészítését igénylik.
Egy jobb eredményt hozó számítás a következő:
Nettó tesztelési hatékonyság = elkerült manuális erőfeszítés − automatizálási üzemeltetési és karbantartási erőfeszítés
Van egy másik fontos kérdés: mi történik az automatizálás által felszabadított kapacitással? Ha a tapasztalt tesztelők egyszerűen az instabil automatizált szkriptekkel foglalkoznak, kevés értéket teremtenek. Ha ehelyett a feltáró tesztelésre, a kockázatelemzésre, az összetett forgatókönyvekre, a teljesítménymérnökségre vagy az új funkciókra koncentrálhatnak, az automatizálás valódi további kapacitást teremtett.
Az automatizálás egyik legértékesebb hozzájárulását gyakran figyelmen kívül hagyják, mivel nehéz közvetlen költségmegtakarításként kifejezni. Lerövidíti a visszacsatolási ciklust. Egy manuális regressziós csomag több napot is igénybe vehet. Egy automatizált csomag éjszaka vagy folyamatosan futhat a fejlesztési folyamat részeként. Ez azt jelenti, hogy a hibák sokkal közelebb észlelhetők a változáshoz, amely előidézte azokat.
Ez azért fontos, mert a késői hibák zavaróak. A fejlesztőknek rekonstruálniuk kell a kontextust, a tesztelőknek reprodukálniuk kell a problémát, a kiadásokat esetleg el kell halasztani, és több csapat is részt vehet a vizsgálatban és a javításban.
A bankok így nyomon követhetik a regressziós ciklus időtartamát, a kódmódosítástól a teszteredményig eltelt időt, a gyártás előtt észlelt hibák százalékos arányát, a hibák kiküszöbölésének arányát, a kiküszöbölt hibák vizsgálatára fordított időt és a javítások ellenőrzéséhez szükséges időt. Az alapállapot és az automatizált folyamat közötti javulás a megtérülés jelentős részét képviseli.
A tesztelés azt is meghatározhatja, hogy az új banki funkciók milyen gyorsan jutnak el az ügyfelekhez. Vegyünk egy fejlesztőszervezetet, amely képes hetente kiadásokat készíteni, de egy ötnapos manuális regressziós ciklustól függ. A fejlesztési sebesség nem az igazi korlát. A tesztelés igen.
Ha a megbízható automatizálás napokról órákra csökkenti ezt a regressziós ciklust, a szervezet képes lesz gyakrabban kiadni a verziókat anélkül, hogy feladná a minőségellenőrzést. Ez felgyorsíthatja az új digitális szolgáltatások, szabályozási változások, biztonsági frissítések, fizetési funkciók és ügyfélélmény-javítások megvalósítását.
Ahelyett, hogy tetszőleges pénzbeli értéket rendelnénk az „agilitáshoz”, mérjük a konkrét változásokat: Mennyi ideig tartottak a kiadások az automatizálás előtt? Mennyi ideig tartanak most? Ennek a javulásnak mennyi része tulajdonítható ésszerűen az automatizált tesztelésnek? Az eredmény erősebb üzleti indokot teremt, mint egyszerűen a végrehajtott tesztek számának jelentése.
Kritikus banki rendszerek esetében akár kis számú súlyos termelési hiba megelőzése is jelentősen többet érhet, mint több ezer órányi manuális tesztelés csökkentése. A termelési hibák költségeket okozhatnak sikertelen vagy késleltetett tranzakciók, ügyfélszolgálati tevékenységek, vészhelyzeti elhárítás, egyeztetések, szolgáltatásleállás, mérnöki túlórák, incidensek kivizsgálása és hírnévkárosodás révén. Nem mindegyik költséget könnyű számszerűsíteni, de a bankok gyakran rendelkeznek olyan korábbi incidensadatokkal, amelyek hasznos alapot nyújthatnak.
A csapatok megvizsgálhatják a korábbi incidenseket, és megkérdezhetik, hogy a jelenlegi automatizált regressziós, integrációs, API-, végponttól végpontig tartó vagy teljesítménytesztek észlelték volna-e a problémát a kiadás előtt. Ha a válasz igen, akkor a hasonló incidensek korábbi költsége hozzájárulhat az üzleti tervhez. A számításnak konzervatívnak kell maradnia. A tesztautomatizálás nem kaphat kreditet minden olyan incidensért, amely nem következik be. A cél a hiteles attribúció, nem pedig a mesterségesen lenyűgöző megtérülési százalék.
A hagyományos automatizálási mérőszámok egyik gyengesége, hogy általában a mennyiséget jutalmazzák. Egy irányítópult akár 15 000 automatizált tesztet vagy 90%-os automatizálási lefedettséget is jelenthet. Egyik szám sem árulja el a vezetőségnek, hogy a bank legfontosabb kockázatait megfelelően tesztelték-e.
Tízezer automatizált teszt, amely alacsony kockázatú funkciókat fed le, kevesebb értéket képviselhet, mint több száz robusztus teszt, amely a fizetésfeldolgozást, a hitelesítést, a tranzakciós limiteket, a számlaműveleteket vagy a kritikus integrációkat fedi le.
A bankok azonosíthatják kritikus üzleti folyamataikat, és meghatározhatják, hogy melyeket fed le az automatizálás, milyen gyakran tesztelik azokat, mely rendszereket és integrációkat tartalmazza, hogy a negatív forgatókönyveket lefedik-e, hogy a teljesítménykövetelményeket validálják-e, és hogy az eredmények elegendő bizonyítékot szolgáltatnak-e. Ez közvetlenül összekapcsolja az automatizálást azokkal a szolgáltatásokkal, amelyeket az üzleti tevékenységnek védenie kell.
Az európai pénzügyi intézmények számára a tesztautomatizálás egy szélesebb körű működési rugalmassági környezetet is támogat. A DORA előírja a hatókörébe tartozó pénzügyi szervezetek számára, hogy kockázatalapú digitális működési rugalmassági tesztelési programokat tartsanak fenn. A rendszerektől és kockázatoktól függően a tesztelés magában foglalhatja a teljesítményt, a kompatibilitást, a teljes körű tesztelést, a forgatókönyv-alapú tesztelést, a sebezhetőséget és az egyéb validációs formákat.
Az automatizálás megismételhetőbbé és skálázhatóbbá teheti ezt a tesztelést. A bizonyítékok reprodukálását is megkönnyítheti. Ezt az értéket nem szabad tetszőleges „megfelelőségi megtakarítás” számként lefordítani. Jobb megközelítés a konkrét fejlesztések mérése, mint például a kritikus rendszerek tesztelési gyakorisága, a kritikus folyamatok lefedettsége, a végrehajtási bizonyítékok elérhetősége, a követelmények és eredmények közötti nyomon követhetőség, valamint a korrekció ellenőrzéséhez szükséges idő. Ezek a mutatók azt mutatják, hogy az automatizálás hogyan járul hozzá a rugalmassághoz és az irányításhoz.
A funkcionális automatizálás megmutatja, hogy egy tranzakció működik-e, é nem feltétlenül mondja meg, hogy több ezer ügyfél képes-e egyszerre végrehajtani a tranzakciót. Ezért kell a teljesítménytesztelést beépíteni a tágabb ROI-elemzésbe.
A bankoknak meg kell érteniük, hogyan viselkednek a rendszerek csúcsidőszakban, hogy a válaszidők elfogadhatóak-e, hol jelennek meg a szűk keresztmetszetek, és hogyan viselkedik az infrastruktúra tartós terhelés alatt.
A teljesítménytesztelés mérhető értéket teremthet azáltal, hogy a kapacitásproblémákat a termelés előtt észleli, támogatja az infrastrukturális döntéseket, validálja a főbb kiadásokat, és csökkenti a teljesítménnyel kapcsolatos incidensek valószínűségét. Feltárhatja a felesleges túlterhelést is.
Ha a teljesítménymérnökség kimutatja, hogy egy alkalmazás biztonságosan működhet kevesebb infrastrukturális erőforrással, az ebből eredő infrastrukturális megtakarítás a ROI egy másik mérhető összetevőjévé válhat.
Az automatizálás üzleti indokai minden alkalommal erősebbek lesznek, amikor egy hasznos automatizált tesztet újra lefuttatnak. Egy teszt, amelynek automatizálása 1000 euróba kerül, és csak egyszer fut, korlátozott értéket képviselhet. Ugyanaz a teszt több százszori futtatása különböző kiadásokban, környezetekben és fejlesztési folyamatokban nagyon eltérő gazdaságossággal jár.
A szervezeteknek ezért figyelemmel kell kísérniük az automatizált tesztek végrehajtásainak számát, az újrafelhasználást a kiadások és alkalmazások között, a karbantartási ráfordítást végrehajtásonként, valamint az automatizált eszközök hasznos élettartamát. Az újrafelhasználható keretrendszer-összetevők is fontosak.
A megosztott könyvtárak, a jelentéskészítési képességek, a tesztadat-segédprogramok, az API-összetevők és a végrehajtási infrastruktúra csökkentheti a jövőbeli automatizálás költségeit. A legjobb automatizálási programok ezért nemcsak teszteket, hanem újrafelhasználható mérnöki képességeket is hoznak létre.
Az automatizálási programok könnyen olyan mérőszámokra összpontosíthatnak, amelyek az aktivitást jutalmazzák az érték helyett: létrehozott szkriptek száma, automatizált manuális tesztek százalékos aránya, végrehajtások száma, automatizált tesztesetek száma összesen. Ezek a mérőszámok hasznosak működési szempontból, de nem szabad, hogy a megtérülés elsődleges bizonyítékává váljanak.
A vezetőknek különböző kérdésekre kell választ keresniük. Gyorsabbak-e a kiadások? Kevesebb kritikus hiba éri-e el a termelést? Gyakrabban tesztelhetők-e a fontos üzleti folyamatok? A regressziós tesztelés már nem szűk keresztmetszet? Korábban azonosítják-e a teljesítményproblémákat? Ha ezekre a kérdésekre igen a válasz, az automatizálás üzleti értéket teremt.
A tesztautomatizálás ritkán hozza a teljes gazdasági értékét már a bevezetés szakaszában. A beruházási költségek gyakran az elején jelentkeznek, míg az előnyök az ismételt végrehajtások során halmozódnak fel. Vegyünk egy egyszerűsített példát!
Egy bank az első évben 250 000 eurót fektet automatizálásba. Ezt követően az üzemeltetés, az infrastruktúra és a fejlesztési feladatok költsége évi 100 000 eurót tesz ki. Ha a kézzelfogható előnyök – a manuális munka kiváltása, a regressziós tesztelésre fordított erőfeszítés csökkenése, a hibák korábbi felismerése és a működési hatékonyság növekedése – évente 220 000 eurót jelentenek, akkor hároméves távlatban a következőképpen alakul a mérleg:
Teljes beruházási költség: 450 000 euró
Teljes mérhető haszon: 660 000 euró
Nettó haszon: 210 000 euró
Az alapvető ROI-képletet alkalmazva ez három év alatt megközelítőleg 47%-os megtérülést jelent. Ez csupán szemléltető példa; minden banknak a saját működési adatai alapján kell kiszámítania a megtérülést. A lényeges elv az, hogy az automatizálás gazdasági megtérülése az ismételt, hasznos végrehajtások révén javul.
Egy sikeres automatizálási stratégia nem törekedhet arra, hogy mindent automatizáljon. Egyes tesztek költségesek és ritkán hajtják végre őket. Mások gyakran változnak, vagy emberi megítéléstől függenek. Eközben egy viszonylag kis tesztcsoport is védheti a szervezet legfontosabb üzleti folyamatait, és évente több százszor lefuthat.
A kockázatalapú automatizálási stratégia azokat a területeket helyezi előtérbe, ahol az ismételt automatizált ellenőrzés a legnagyobb értéket teremti. A banki szektorban ezek közé tartozhatnak a fizetési folyamatok, a hitelesítés, az alapvető banki integrációk, a tranzakciófeldolgozás, a digitális csatornák, a szabályozási munkafolyamatok és a nagy volumenű API-k. A cél nem a maximális automatizálási lefedettség. A cél a maximális hasznosság biztosítása.
A banki szektorban a tesztautomatizálás megtérülése (ROI) nem mérhető szkriptek számlálásával vagy a megtakarított manuális munkaórák kiszámításával. Egy értelmesebb mérés azt vizsgálja, hogy az automatizálás milyen változásokat hoz létre a szervezetben.
Lerövidíti-e a regressziós ciklusokat? Korábban észleli-e a hibákat? Segít-e a csapatoknak biztonságosan és gyakrabban kiadni a verziókat? Csökkenti-e a termelési kockázatot? Javítja-e a teljesítménybiztosítást? Megismételhető bizonyítékokat nyújt-e a kritikus rendszerek esetében?
Amikor a bankok ezeket az eredményeket az automatizálás pénzügyi költségeivel együtt mérik, a megtérülés sokkal valóságosabbá válik, mint egy elméleti százalék. Gyakorlatias módja annak meghatározására, hogy hol teremt értéket a tesztautomatizálás – és hová kell a következőkben befektetni.
Végső soron a legfontosabb kérdés nem az, hogy „Hány tesztet automatizáltunk?”, hanem az, hogy „Milyen mérhető üzleti és technológiai kockázatokat tudunk jobban kezelni a tesztautomatizálásunknak köszönhetően?”
A komplex pénzügyi rendszerek fenntartható automatizálási képességének kiépítéséhez a megfelelő architektúra, priorizálás, mérnöki szakértelem és teljesítménytesztelési stratégia szükséges.
A ProofIT bizonyított referenciákkal rendelkezik a banki, telekommunikációs és légiipari komplex, üzletileg kritikus rendszerek automatizált tesztelésében és teljesítménytesztelésében.
Segítünk a szervezeteknek skálázható tesztautomatizálás kiépítésében, komplex, végponttól végpontig tartó folyamatok validálásában, a rendszer teljesítményének valós körülmények közötti értékelésében és a minőségbiztosítás megerősítésében a komplex vállalati környezetekben.
Ha szeretné tudni, a tesztautomatizálás hol tudja a legnagyobb mérhető értéket biztosítani szervezetében, vegye fel a kapcsolatot a ProofIT munkatársaival a business@proofit.tech e-mail címen vagy a +44 73 6048 4722 telefonszámon, hogy átbeszéljük tesztelési stratégiáját.
