Mikor érdemes kiszervezni a szoftvertesztelést, és hogyan válassz QA-partnert?

Bevallok valamit, ami egy tesztelési szolgáltatást nyújtó cégtől nem hangzik jól: nem minden cégnek kell kiszervezni a szoftvertesztelést. Van, ahol a belső QA-csapat a legjobb megoldás, van, ahol a vegyes modell működik, és van négy helyzet, amikor a kiszervezés nemcsak olcsóbb, hanem jobb eredményt is ad. Ez a cikk sorra veszi ezt a négy helyzetet, azt, hogyan javítja valójában a kiszervezett tesztelés a termék megbízhatóságát, hogyan válassz QA-partnert, mit változtat az AI-alapú tesztelés a hagyományos kiszervezéshez képest, és mit jelent mindez a DORA alatt álló pénzügyi szolgáltatóknak.

Röviden

• A kiszervezést nem az óradíj dönti el, hanem négy kérdés: változó-e a kapacitásigény, hiányzik-e a domain-tudás, kell-e függetlenség, és core tevékenység-e a QA.
• A kiszervezés nem egyetlen modell: csapatkiterjesztés, projektalapú tesztelés és menedzselt tesztelési szolgáltatás mást-mást old meg.
• Pénzügyi szolgáltatóknál a DORA független tesztelőket ír elő, de a felelősség kiszervezéskor is a pénzügyi szervezetnél marad.
• A World Quality Report 2025 szerint a cégek 89 százaléka kísérletezik vagy dolgozik generatív AI-val a tesztelésben, de csak 15 százalék jutott el a vállalati szintű bevezetésig.
• A kiszervezett tesztelés csak akkor javítja a megbízhatóságot, ha mérik: az élesbe kijutott hibák aránya, a hibás telepítések aránya és a helyreállítási idő mutatja meg, működik-e.
• QA-partnert értékelőlap és rövid pilot alapján válassz, ne csak a napidíj alapján.
• Az AI-alapú tesztelés gyorsítja a teszttervezést és a regressziós tesztek karbantartását, de nem pótolja a domain-tudást és a függetlenséget.
• Stabil, folyamatos tesztelési igénynél a belső csapat hosszú távon jellemzően olcsóbb és jobban integrálódik.

Miért kérdés ez most?

A rossz szoftverminőség ára nem elméleti. A CISQ (Consortium for Information & Software Quality) 2022-es becslése szerint az Egyesült Államokban a gyenge szoftverminőség legalább 2410 milliárd dollárba került egyetlen év alatt, és a felhalmozott technikai adósság nagyjából 1520 milliárd dollárra rúgott. Boehm és Basili klasszikus összefoglalója szerint egy hiba kijavítása átadás után gyakran nagyságrendekkel drágább, mint a fejlesztés korai szakaszában.

Ehhez jön két új tényező. Az egyik a szabályozás: a DORA 2025 januárja óta kötelezően előírja a pénzügyi szolgáltatóknak a digitális működési reziliencia tesztelését. A másik az AI: a tesztelési munka egy része automatizálható, de a bevezetéshez új tudás és új adatkezelési szabályok kellenek. Mindkettő arra kényszeríti a vezetőket, hogy újragondolják, mit tesztelnek házon belül, és mit bíznak partnerre.

Először a mítoszok

„A kiszervezett QA olcsóbb.”

Néha igen, néha nem. Ha évekig tartó, állandó tesztelési kapacitásra van szükség, a megrendelő a tanácsadóknak többet fizethet, mint amennyibe egy belső csapat kerülne. Hosszú távú, stabil igénynél a belső csapat valóban olcsóbb lehet.

„A kiszervezett QA rugalmasabb.”

Ez igaz, de csak akkor ér valamit, ha a tesztelési igény valóban változik. Stabil terhelésnél olyan rugalmasságért fizetsz felárat, amit nem használsz.

„A kiszervezett QA kevésbé megbízható.”

Ez a leggyakoribb kifogás, és a legkevésbé helytálló, ha a partnert jól választottuk ki. A minőség nem a foglalkoztatási formán múlik, hanem a szakértelmen, a domain-ismereten és a folyamaton.

1. helyzet: csúcsterhelés, amit nem érdemes állandó kapacitásra méretezni

Van egy szoftverbevezetési projekt. Három hónap alatt le kell tesztelni a teljes rendszert: funkcionális tesztelés, integrációs tesztelés, UAT-koordináció. Utána a projekt véget ér, és a tesztelési igény a töredékére esik vissza.

Erre nem érdemes három senior tesztelőt felvenni. A toborzás két-három hónap, a betanulás még egy, és mire produktívak lennének, a csúcs elmúlt.

Ezt közelről is láttuk. Egy pénzügyi nagyvállalatnál a bevezetés előtt hirtelen megnőtt a tesztelési igény. Tíz napon belül három senior QA-szakértőt állítottunk munkába, a tesztelési fázis határidőre lezárult, a kritikus hibák még az élesítés előtt felszínre kerültek, utána pedig visszaskáláztuk a kapacitást. Belső csapattal ezt nem lehetett volna megoldani. Persze egy szakértő cégnél sem garantált, hogy éppen van három szabad tesztelő, de sokkal valószínűbb, mint házon belül.

Mikor alkalmazható: egyszeri vagy időszakos projektnél, ahol a csúcsigény nem indokol állandó belső kapacitást, vagy ahol még nem dőlt el, kell-e belső tesztelő.

2. helyzet: hiányzó domain-tudás, és nincs idő betanítani

Egy biztosítási termék tesztelése nem ugyanaz, mint egy általános webalkalmazásé. A kárbejelentés kivételes esetei, a díjkalkuláció logikája, a lízingszerződés életciklusa vagy a KGFB-termék díjstruktúrája nem adható át egy rövid eligazításon. Ha a tesztelő nem ismeri az üzleti logikát, a tesztelés felszínes marad, és a kritikus hibák a felszín alatt maradnak. Elvben a részletes tesztterv és specifikáció pótolhatná ezt, a gyakorlat viszont azt mutatja, hogy a szakmai tudást nehéz dokumentummal helyettesíteni.

Egy biztosítói mobilalkalmazásnál láttuk a különbséget. A fejlesztői tesztek felületesek voltak, a független QA viszont már az első napon megtalálta, hogy egy bejövő hívás megszakítja a kárbejelentést, és elvész minden addig beírt adat. A fejlesztők nem gondoltak erre, a tesztelő igen, mert tudta, hogyan használják a valódi ügyfelek a telefonjukat.

Mikor alkalmazható: speciális tudást igénylő projekteknél, ahol nincs idő a betanításra. Ez lehet tesztelői szaktudás (például teljesítmény- vagy biztonsági tesztelés) és üzleti domain-tudás is.

3. helyzet: független szemre van szükség, nem belső ellenőrzésre

Ritkán mondják ki hangosan, de a fejlesztőcsapaton belüli tesztelők idővel „elvakulnak”. Ismerik a rendszert, tudják, hogyan készült, és öntudatlanul elkerülik azokat az utakat, ahol hibázik. Üzleti elemzőként egyszer egy telefonos IVR-rendszert teszteltem hosszan, több körben, és minden kifogástalanul működött. Aztán átadtuk egy tapasztalt tesztelő kolléganőnek, aki azonnal összevissza kezdte nyomkodni a gombokat, és a rendszer lefagyott. Én ezt nem próbáltam, csak a specifikáció szerint mentem végig a menükön. Ez nem hanyagság, hanem a megerősítési torzítás (confirmation bias) természetes működése (erről bővebben: miért ne tesztelje a fejlesztő a saját kódját).

Az ISTQB, a nemzetközi szoftvertesztelői minősítési testület tananyaga négy függetlenségi szintet különböztet meg:

Az ISTQB azt is kimondja, hogy a függetlenségnek ára van: a független tesztelő elszigetelődhet a fejlesztőcsapattól, a fejlesztők pedig elveszíthetik a minőségért érzett felelősségüket. Ezért a jó kiszervezés nem „átdobja a falon” a tesztelést, hanem korán bekapcsolja a tesztelőt a projektbe.

Külső fejlesztővel dolgozó ügyfeleknél a kérdés még élesebb. Ha az IT-partner fejleszti és teszteli is a rendszert, ki ellenőrzi az ellenőrt? Egy pénzügyi nagyvállalatnál pontosan ez történt: a partner fejlesztett és tesztelt, és az élesítés után derültek ki olyan hibák, amelyeket egy független QA megtalált volna. A független tesztelés nem a fejlesztő ellen szól, hanem az ügyfél érdekét védi. Ha a megrendelő egy kézben akarja tartani a felelősséget, ez nem megoldás, de tapasztalatunk szerint a szerepek szétválasztása sokszor kifizetődik.

Mikor alkalmazható: külső fejlesztőpartnerrel dolgozó, nagy komplexitású projekteknél, vagy ha el akarod kerülni, hogy egyetlen beszállítótól függj.

4. helyzet: a tesztelés nem core tevékenység, de a minőség kritikus

Ez a leggyakoribb és legkevésbé bevallott helyzet. Sok pénzügyi nagyvállalatnál a szoftverfejlesztés és a tesztelés nem alaptevékenység, az általuk üzemeltetett rendszerek minősége viszont kritikus. Egy kárbejelentő rendszer hibája nemcsak IT-probléma, hanem ügyfél-elégedettségi, megfelelőségi és reputációs kockázat egyszerre.

Ezeknek a szervezeteknek nem éri meg teljes körű belső QA-kompetenciát felépíteni és fenntartani, de a minőség biztosítása nem opcionális. A kiszervezés itt nem költségcsökkentés, hanem stratégiai döntés: a minőség felelősségét olyan partnerre bízzák, aki ezt alaptevékenységként végzi.

Mikor alkalmazható: ahol a szoftverminőség üzletileg kritikus, de a QA-kompetencia felépítése nem stratégiai prioritás, vagy egy kritikus projekt közben nem reális kiépíteni.

Hogyan javítja a kiszervezett tesztelés a termék megbízhatóságát?

A tesztelés kiszervezése önmagában nem teszi megbízhatóbbá a szoftvert. Az javítja a megbízhatóságot, amit egy jó QA-partner magával hoz: a független nézőpont, a regressziós biztonsági háló, a nem funkcionális tesztelés és a mérés. A gyakorlatban öt mechanizmuson keresztül javul a megbízhatóság:

• Független teszttervezés: a külső tesztelő nem osztja a fejlesztők feltételezéseit, ezért megtalálja azokat a hibákat, amelyek ezekből a feltételezésekből fakadnak.
• Regressziós biztonsági háló: automatizált regressziós tesztkészlet, amely minden kiadásnál lefut, hogy egy változtatás ne rontson el valamit máshol. Pontosan ez hiányzott, amikor egyik korábbi projektemen egy számlázó rendszer egy élesítés után 16 országban leállt.
• Nem funkcionális tesztelés: teljesítmény-, terheléses, átállási (failover) és biztonsági tesztelés, amit a belső csapatok gyakran kihagynak, mert nincs hozzá eszközük vagy specialistájuk.
• Éleshez közeli körülmények: valósághű tesztadatok és környezetek, határértékekkel, speciális karakterekkel és valós használati mintákkal.
• Mérés: a megbízhatóság csak ott javul, ahol követik.

A méréshez jó kiindulópont a DORA kutatási program (DevOps Research and Assessment, nem összetévesztendő az EU DORA rendeletével) szállítási mutatói. Egy QA-partnernek meg kell tudnia mutatni, hogyan mozdítja ezeket a munkája:

A kiinduló értékeket a megbízás előtt rögzítsétek. Ha néhány hónap után ezek a számok nem javulnak, nem a kiszervezési modellel van a baj, hanem azzal, ahogyan működtetik.

A kiszervezésnek több modellje van

A „kiszervezzük a tesztelést” mondat mögött nagyon különböző megoldások állhatnak. A modell megválasztása legalább olyan fontos, mint maga a döntés.

A gyakorlatban a vegyes modell a leggyakoribb: a belső csapat birtokolja a tesztstratégiát és a kritikus tudást, a csúcsokat és a speciális területeket (például teljesítmény-, biztonsági vagy automatizált regressziós tesztelést) pedig partner fedezi.

Mennyibe kerül? A bér csak a jéghegy csúcsa

A Bluebird 2026-os, valós toborzási adatokon alapuló budapesti IT-fizetési összesítője szerint a tesztelői bérek így alakulnak (bruttó, havi):

A senior automatizálási tesztelő bére tehát már közel van a senior Java fejlesztőéhez (1,6-2,2 millió Ft). A valódi összehasonlításhoz azonban a bér mellé oda kell tenni a rejtett költségeket is: a toborzás idejét és díját, a betanulás alatti alacsonyabb teljesítményt, a tesztkörnyezetek és eszközök licencét, valamint azt, hogy a kapacitás akkor is fizetendő, amikor éppen nincs mit tesztelni. Külső konstrukcióban a napidíj magasabb a bérnél, mert tartalmazza a szolgáltató költségeit is, cserébe csak a ténylegesen igénybe vett kapacitásért fizetsz, és nincs toborzási idő.

Az igazi költségkérdés tehát nem az, hogy mennyi a napidíj, hanem az, hogy mennyibe kerül egy élesben felfedezett hiba. Egy pénzügyi szolgáltatónál ez ügyfélpanaszt, javító kiadást, esetenként felügyeleti bejelentést is jelenthet.

Pénzügyi szektor: mit jelent a DORA a kiszervezett tesztelésre?

A DORA (az EU digitális működési rezilienciáról szóló rendelete) két ponton is közvetlenül érinti a tesztelés kiszervezését.

1. A tesztelési kötelezettség. A rendelet 24. cikke szerint a pénzügyi szolgáltatóknak (a mikrovállalkozások kivételével) legalább évente megfelelő teszteket kell futtatniuk minden olyan IKT-rendszeren és alkalmazáson, amely kritikus vagy fontos funkciót támogat. A teszteket független félnek kell végeznie, akár belső, akár külső, és a teljes tesztelés során el kell kerülni az összeférhetetlenséget. A 25. cikk felsorolja a tesztek körét is: a sérülékenységvizsgálattól és a forráskód-felülvizsgálattól a forgatókönyv-alapú, kompatibilitási, teljesítmény- és end-to-end teszteken át a penetrációs tesztelésig.

2. A harmadik fél kockázata. A 28. cikk szerint a kiszervezett IKT-szolgáltatások kockázata a pénzügyi szervezet saját IKT-kockázatkezelési keretrendszerének része, és a szervezet akkor is teljes mértékben felelős a megfelelésért, ha a munkát szolgáltató végzi. Minden IKT-szolgáltatási szerződést nyilván kell tartani, a kritikus vagy fontos funkciókat támogató szolgáltatásoknál pedig kilépési stratégia is kell.

A gyakorlatban ez azt jelenti, hogy a tesztelés kiszervezése pénzügyi szolgáltatónál nem egyszerű beszerzés. A szerződésnek rendeznie kell a tesztadatok kezelését, a jelentési kötelezettségeket, az auditjogot és a kilépést, a partnernek pedig dokumentáltan kell tudnia igazolni, mit, mikor és milyen eredménnyel tesztelt.

Mit változtat az AI a tesztelésen?

A World Quality Report 2025 (OpenText, Capgemini és Sogeti, több mint 2000 vezető 22 országból) szerint a szervezetek 89 százaléka kísérletezik vagy már dolgozik generatív AI-val támogatott tesztelési folyamatokkal, de csak 15 százalékuk jutott el a vállalati szintű bevezetésig. Az átlagos termelékenységnövekedés 19 százalék volt, a válaszadók nagyjából harmada viszont alig látott javulást. A legfőbb akadályok az adatvédelmi kockázat (67 százalék), az integráció bonyolultsága (64 százalék) és a hallucináció, azaz a megbízhatatlan kimenet (60 százalék). A cégek fele szerint hiányzik náluk az AI-szaktudás.

Ebből két tanulság következik a kiszervezési döntéshez:

• Az AI nem váltja ki a tesztelőt, de megváltoztatja a munkáját. A tesztesetek első változata, a tesztadatok generálása és az automatizált regressziós tesztek karbantartása gyorsulhat, a kockázatalapú tesztstratégiát, a domain-tudást és az eredmények értékelését viszont továbbra is ember adja.
• Kérdezz rá, hogyan használja a partner az AI-t. Milyen eszközökkel dolgozik, hová kerülnek a tesztadatok és a kód, és ki ellenőrzi az AI által generált teszteket? Pénzügyi szolgáltatónál éles ügyféladat nem kerülhet ellenőrizetlenül felhőalapú AI-eszközhöz.

AI-alapú tesztelés vagy hagyományos QA-kiszervezés?

Sok szolgáltató ma már AI-alapú tesztelést kínál a klasszikus kiszervezett tesztelés mellett vagy helyett. A különbség nem csak az eszközökben van, a költségmodell és a kockázatok is mások:

Szerintem nem vagy-vagy a kérdés. A reális modell egy olyan QA-partner, amelynek szakemberei ott használnak AI-eszközöket, ahol azok valóban időt spórolnak, a kockázatalapú tesztstratégia, a domain-tudás és a jóváhagyás viszont emberi kézben marad. Legyél óvatos az olyan ajánlatokkal, amelyek a tesztelők teljes kiváltását ígérik: a fenti bevezetési adatok alapján ezt ma kevés szolgáltató tudja teljesíteni.

Mikor NEM érdemes kiszervezni?

Az objektivitás kedvéért négy helyzet, amikor a belső csapat a jobb választás:

• Folyamatos, stabil tesztelési igény: ha minden sprintben ugyanannyi QA-kapacitás kell, a belső csapat hosszú távon jellemzően olcsóbb, és jobban integrálódik.
• Mélyen beágyazott rendszertudás: ha a rendszer annyira egyedi, hogy a betanulás hónapokig tart, vagy a tartalma annyira érzékeny üzleti titok, hogy nem adható ki.
• Nagyon szoros agilis integráció: ha a tesztelő a fejlesztőcsapat napi tagja, és nem akarjátok szétválasztani a felelősséget.
• Saját QA-kompetencia mint stratégiai cél: ha a szervezet tudatosan épít belső tesztelési tudást, a teljes kiszervezés ezt lassíthatja. Ilyenkor a vegyes modell a jó irány.

Hogyan válassz QA-partnert? Gyakorlati értékelőlap

A leggyakoribb hiba, hogy a QA-partnert csak a napidíj alapján választják ki. Használj inkább egy egyszerű értékelőlapot, és minden jelöltnek tedd fel ugyanazokat a kérdéseket:

A tanácsunk: hosszú távú szerződés előtt futtass egy néhány hetes pilotot egy valódi kiadáson. A pilot hetek alatt megmutatja, amit egyetlen prezentáció sem: milyen gyorsan érti meg a csapat az üzletedet, milyen hibákat talál, és hogyan jelenti őket.

Ellenőrzőlista: kiszervezzük a tesztelést?

• Változó a tesztelési kapacitásigény, vannak kiugró csúcsok?
• Hiányzik belülről a szükséges üzleti vagy tesztelői szaktudás?
• Szükség van a fejlesztőtől független tesztelésre (például a DORA vagy egy külső fejlesztőpartner miatt)?
• A QA nem alaptevékenység, de a minőség üzletileg kritikus?
• Eldöntöttük, melyik modell illik hozzánk: csapatkiterjesztés, projektalapú vagy menedzselt szolgáltatás?
• Megvan a tesztadatok kezelésének és az AI-eszközök használatának szabálya?
• A szerződés rögzíti a KPI-kat, a jelentéseket, a tudásátadást és a kilépést?
• Megállapodtunk a megbízhatósági mutatókban és a kiinduló értékekben a kezdés előtt?
• Kipróbáltuk a partnert egy rövid pilottal a hosszú távú szerződés előtt?

Amit a FrontX-nél másképp csinálunk

• Domain-tudást hozunk, nem csak kapacitást: QA-szakértőink ismerik a biztosítói, banki és lízinges folyamatokat, így nemcsak azt ellenőrizzük, hogy a gomb megnyomható-e, hanem azt is, hogy a mögötte lévő üzleti folyamat helyesen fut-e.
• Korán kapcsolódunk be: a tesztelő már a specifikáció átnézésénél ott van, és szorosan együtt dolgozik az üzleti elemzőkkel.
• Rugalmas modellben dolgozunk: csapatkiterjesztésként, projektalapon vagy menedzselt szolgáltatásként, ahogy a helyzet kívánja.
• Független szemmel tesztelünk akkor is, ha a fejlesztést más partner végzi.
• A tesztesetek és az automatizált szkriptek az ügyfélé maradnak. Részletek a tesztelési szolgáltatásunk oldalán.

Ha olyan bevezetési projekted van, ahol a tesztelési kapacitás vagy a domain-tudás kérdéses, szívesen segítünk eldönteni, melyik modell illik hozzád: kérj ingyenes konzultációt.

Gyakran ismételt kérdések

Mikor érdemes kiszervezni a szoftvertesztelést?

Négy fő helyzetben: ha a tesztelési kapacitásigény változó, ha hiányzik a belső domain- vagy tesztelői tudás, ha a fejlesztőtől független tesztelésre van szükség, vagy ha a QA nem alaptevékenység, de a minőség kritikus. Stabil, folyamatos igénynél a belső csapat hosszú távon jellemzően olcsóbb.

Milyen modellekben lehet kiszervezni a tesztelést?

A három leggyakoribb a csapatkiterjesztés, ahol a megrendelő irányítja a bevont tesztelőket, a projektalapú tesztelés egy bevezetéshez vagy kiadáshoz, és a menedzselt tesztelési szolgáltatás, ahol a partner SLA és KPI mentén felel a tesztelésért. A gyakorlatban gyakori a vegyes modell is.

Mennyibe kerül egy tesztelő Magyarországon?

A Bluebird 2026-os budapesti összesítője szerint egy manuális tesztelő bruttó havi bére 700 ezer és 1,6 millió, egy automatizálási tesztelőé 850 ezer és 1,75 millió forint között van a tapasztalattól függően. A teljes költséghez hozzá kell számolni a toborzást, a betanulást, az eszközöket és a kihasználatlan kapacitást is.

Mit ír elő a DORA a tesztelésről?

A DORA szerint a pénzügyi szolgáltatóknak legalább évente tesztelniük kell a kritikus vagy fontos funkciókat támogató IKT-rendszereiket, független belső vagy külső tesztelőkkel. Kiszervezés esetén a felelősség a pénzügyi szervezetnél marad, a szerződést nyilván kell tartani, és kritikus funkcióknál kilépési stratégia is kell.

Kiváltja-e az AI a tesztelőket?

Nem. A World Quality Report 2025 szerint a cégek 89 százaléka kísérletezik vagy dolgozik generatív AI-val a tesztelésben, de csak 15 százalékuk vezette be vállalati szinten, és a legfőbb akadály az adatvédelem. Az AI gyorsítja a tesztesetek és tesztadatok előállítását, a tesztstratégiát és az eredmények értékelését viszont továbbra is szakember adja.

Hogyan javítja a szoftvertesztelés kiszervezése a termék megbízhatóságát?

A független nézőponttal, automatizált regressziós biztonsági hálóval, nem funkcionális teszteléssel (például teljesítmény- és failover-tesztekkel) és valósághű tesztadatokkal. A megbízhatóság csak akkor javul, ha mérik, például az élesbe kijutott hibák arányával, a hibás telepítések arányával és a helyreállítási idővel, a kezdéskor rögzített kiinduló értékekhez képest.

Hogyan válasszak QA-partnert?

Napidíj helyett értékelőlap alapján: domain-tudás, a csapat stabilitása, tesztelési folyamat, korai bevonás, jelentések, AI- és adatkezelés, a teszteszközök tulajdonjoga, szabályozói tapasztalat és rugalmas üzleti modell. Hosszú távú szerződés előtt futtass egy rövid pilotot egy valódi kiadáson.

AI-alapú tesztelés vagy hagyományos kiszervezés: melyik a jobb?

A feladattól függ. Az AI-alapú tesztelés a nagy volumenű, ismétlődő munkában erős, például a tesztesetek első változatánál, a tesztadatoknál és a regressziós tesztek karbantartásánál. A tapasztalt szakemberekkel végzett hagyományos kiszervezés az összetett üzleti logikánál, a felfedező tesztelésnél és a szabályozott környezetben erősebb. A gyakorlatban a kettő kombinációja a legjobb, ahol a stratégia és a jóváhagyás emberi kézben marad.

Mi a shift-left tesztelés, és miért fontos kiszervezett modellben?

A shift-left azt jelenti, hogy a tesztelés nem a fejlesztés végén kezdődik, hanem a projekt elejétől jelen van, a specifikáció átnézésétől a sprintek közbeni tesztelésig. Kiszervezett modellben ez különösen fontos, mert a külső tesztelőnek időben fel kell építenie a domain- és rendszertudást.

Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. LinkedIn-profil