16 000 óra spórolás egyetlen hibán?

Mi van egy működő banki rendszer mögött, és mit bukhat a projekted, ha erre senki sem figyel?

Röviden, ha csak fél perced van rá:

• Egy banki fejlesztésnél egyetlen, időben észrevett tervezési hiányosság kb. 16 000 munkaórányi (nagyjából egy csapat fél-egy éves munkájának megfelelő) plusz munkát spórolt meg.
• Egy sikeres banki utalás mögött 6–8 rendszer mozdul meg egyszerre. Egy zöld pipa a képernyőn önmagában nem bizonyítja, hogy minden helyesen futott le a háttérben.
• Az AI-alapú rendszerek (pl. hitelbírálat) tesztelése és auditálhatósága ma már nem csak szakmai, hanem vezetői döntés is, különösen egy szabályozott iparágban.

Egy banki alkalmazásnál a felhasználó néhány egyszerű műveletet lát. Belép, megnézi az egyenlegét, elindít egy utalást, majd kap egy visszajelzést arról, hogy sikerült. Egy projektvezető vagy középvezető ugyanezt egy kicsit másképp látja: egy funkciót, aminek el kell készülnie a tervezett időre, a tervezett költségvetésből, úgy, hogy közben ne okozzon kockázatot sem az ügyfeleknek, sem a cégnek. A háttérben jóval összetettebb folyamatok futnak, és egyetlen művelet több egymással összekapcsolt rendszert is érinthet.

Ebben a környezetben a tesztelés sem merül ki abban, hogy valaki végigkattintja az elkészült funkciókat. Ha a vezetők is így gondolják a saját projektjükről, az közvetlenül látszik majd a határidőkön, a költségvetésen és a kiadás utáni hibák számán. 

A tesztelés már az első sor kód előtt elkezdődhet

A követelményeket és a terveket ugyanúgy érdemes ellenőrizni, mint később az elkészült szoftvert. Egy tapasztalt tesztelő már ezen a ponton végig tudja gondolni a felhasználói folyamatokat, és észreveheti, ha hiányzik egy lépés, két követelmény ellentmond egymásnak, vagy van egy olyan helyzet, amire a tervezés során nem gondoltak.

Egy banki fejlesztésnél például egy több lépésből álló folyamat tervezésekor derült ki, hogy nincs lehetőség menet közben kilépni. Ha ezt csak a fejlesztés után veszik észre, a becslés szerint a módosítás és az újratesztelés körülbelül 12 000 tesztelői és 4 000 fejlesztői munkaórát igényelt volna. Ez összesen 16 000 munkaóra, nagyjából egy csapat fél-egyéves munkájának megfelelő mennyiség, amit egyetlen, időben feltett kérdés spórolt meg. 

A hibát azért sikerült megtalálni időben, mert a tesztelés nem a fejlesztés végén, hanem a tervezésnél kezdődött. Ez a legkonkrétabb válasz arra a kérdésre, hogy miért éri meg a tesztelést korán bevonni egy projektbe: nem azért, mert "jó gyakorlat", hanem mert ez az egyetlen fázis, ahol egy hiba javítása még nem visz magával több ezer órányi elkészült munkát. 

Mit tehet ezért egy projektvezető vagy középvezető? 

Vonja be a tesztelést már a követelmények és a tervek véleményezésébe, ne csak a kész funkció átvételekor. Kérdezzen rá kifejezetten a nyitott kérdésekre és az ellentmondó követelményekre a tervezési fázis lezárása előtt. Számoljon a tesztelés kapacitás igényével már a projekt ütemezésekor, ne utólagos pufferként kezelje, ha csúszik a fejlesztés.

A specifikáció teljesítése még nem jelenti azt, hogy jó a megoldás

Előfordulhat, hogy egy funkció pontosan azt csinálja, amit a követelményekben leírtak, a felhasználó problémáját mégsem oldja meg megfelelően. Ezért fontos, hogy a tesztelő ne csak az elkészült funkciót és a specifikációt hasonlítsa össze, hanem értse azt az üzleti folyamatot is, amelynek a szoftver a része.

Ehhez kérdezni is kell. Ha egy használati eset hiányzik, egy szabály nem egyértelmű vagy két követelmény nem fér össze, azt még a fejlesztés közben tisztázni kell. Minél később derül ki ugyanaz a probléma, annál több elkészült munkát érinthet a javítása. Egy vezetőnek ez gyakorlatilag azt jelenti, hogy a "megfelel a specifikációnak" és a "jó lesz élesben" nem ugyanaz a kockázati kategória. 

Ha nem fér bele minden, tudni kell, mit teszteljünk először

Egy nagy banki rendszer minden funkcióját ugyanolyan mélységben végigtesztelni minden release előtt nem reális. A belépés, az utalás vagy a számlanyitás működése például jóval nagyobb figyelmet igényel, mint egy ritkábban használt, kisebb jelentőségű funkció.

A funkciókat és a hozzájuk tartozó teszteseteket ezért üzleti kockázat alapján lehet rangsorolni. Számít, milyen gyakran használják az adott funkciót, mekkora a hiba esélye, és milyen következménye lenne, ha hibásan kerülne ki. A tesztesetek ez alapján kaphatnak alacsony, közepes, magas vagy kritikus prioritást. Ha kevés az idő vagy a kapacitás, a kritikus területek kerülnek előre. Ez pontosan az a döntés, amit egy vezetőnek jóvá kell hagynia, nem csak a tesztelőnek kell meghoznia.

A release gyakoriságát a rendszerhez kell igazítani, nem fordítva

Egy nagy banki környezetben évente akár 3-5 nagyobb release is teljesen indokolt lehet. Egyetlen projekten több tucat ember dolgozhat, miközben a fejlesztés számos más rendszerhez kapcsolódik. Ezek változásait össze kell hangolni, és közben a szabályozói követelményeknek is meg kell felelni.

Ezért a gyakoribb release önmagában nem jelent jobb működést. A megfelelő tempót az adott rendszer összetettsége, a kapcsolódó folyamatok, a kockázatok és a külső követelmények együtt határozzák meg. Egy kisebb terméknél működhet a napi kiadás, míg egy összetett banki rendszerben egészen más feltételekkel kell számolni. Ha ezt egy vezető máshonnan hozott elvárásként ("miért nem adunk ki hetente?") kéri számon, az többnyire a rendszer valós összetettségének félreértéséből fakad.

A frontend csak a jéghegy csúcsa

Egy utalásnál a felhasználó megnyom egy gombot, majd megjelenik a sikeres visszajelzés. Közben a háttérben akár 6–8 rendszer is megmozdulhat, az adatok pedig különböző interfészeken keresztül haladnak tovább. Elég, ha ezen az úton valahol kimarad egy összeg, dátum vagy ügyfélazonosító, és a folyamat már nem úgy fut végig, ahogyan kellene.

Ezért a tesztelő sem állhat meg a képernyőnél. Követnie kell az üzeneteket, meg kell néznie a logokat, az adatbázist és a kapcsolódó háttérrendszereket. Erre akkor is szükség lehet, ha a felületen látszólag minden rendben működik. Egy sikeres visszajelzés önmagában még nem bizonyítja, hogy a teljes folyamat hibátlanul lefutott. Ez az a mondat, amit érdemes megjegyezni minden olyan projektstátusz-megbeszélésen, ahol a "frontend kész" kifejezés elhangzik.

AI a tesztelésben, amit egy vezetőnek is tudnia kell róla

Az AI több előkészítő feladatban használható. Követelmények és használati esetek alapján gyorsan összeállíthat egy első teszteset-listát, illetve teljesen fiktív tesztadatokat is létrehozhat. Banki környezetben ennek külön előnye, hogy a teszteléshez nem kell valódi ügyféladatokból kiindulni.

A tesztelőnek viszont továbbra is értenie kell a rendszert és az üzleti folyamatokat. Egy tapasztalt szakembernek az is feltűnhet, ha egy korábban öt másodperces folyamat hirtelen harminc másodpercig tart, miközben formálisan továbbra is sikeresen lefut. Ilyenkor utánanéz annak, mi változott a háttérben, és olyan problémát is megtalálhat, amelyre az előre megírt teszteset nem tért ki. Az AI tehát gyorsít, de nem helyettesíti a rendszerismeretet.

Ennél is fontosabb vezetői kérdés, hogy amikor maga a banki rendszer tartalmaz AI-komponenst, például egy hitelbírálati modellt, ott az elvárt eredmény fogalma is megváltozik. Egy hagyományos rendszer tesztelésénél általában pontosan meghatározható, milyen kimenetet várunk egy adott bemenetre. Egy nem determinisztikus AI-rendszer ugyanarra a bemenetre több különböző választ is adhat, ezért másképp kell meghatározni, mit tekintünk megfelelő működésnek.

Egy hitelbírálatnál például nem feltétlenül az a fontos, hogy minden futtatás pontosan ugyanazt a pontszámot adja. Azt kell ellenőrizni, hogy egy egyértelműen hitelképes ügyfél eredménye megbízhatóan a megfelelő tartományban marad-e, és ugyanez igaz-e a nem hitelképes esetekre. Emellett azt is meg kell tudni magyarázni, milyen adatok alapján született az eredmény, mert egy szabályozott környezetben később ezt is igazolni kell.

A tesztelés értéke nem csak a megtalált hibák számában mérhető

Egy tesztelő munkájának eredménye sokszor éppen az, ami végül nem történik meg. Nem kell több ezer munkaórát egy későn észrevett problémára fordítani, nem kerül ki egy kritikus hiba az ügyfelekhez, vagy még a release előtt kiderül, hogy egy háttérfolyamat nem úgy működik, ahogyan kellene.

Egy vezető számára ez a lényeg: a megelőzött kár, a be nem tartott extra munkaóra és a meg nem történt incidens ugyanolyan valós eredmény, mint egy határidőre leszállított funkció. Csak éppen nem látszik a demón.

Ehhez a tesztelést nem lehet a fejlesztés végére hagyott ellenőrzési feladatként kezelni. Már a tervezésnél szükség van rá, később pedig a kockázatok, az üzleti folyamatok és a rendszer működése alapján kell eldönteni, mire fordítsuk a rendelkezésre álló időt és kapacitást.

Kíváncsi vagy a teljes beszélgetésre?

Ha akár tesztelőként, akár egy banki szoftverprojekt felelőseként érdekel, ez a fajta kockázat és felelősség hogyan néz ki a mindennapokban, hallgasd meg a Nálunk működött legújabb epizódját Bodrogközi Gáborral.

Konkrét példákon keresztül beszélünk a tesztelés mindennapjairól, a kockázatokról, a banki rendszerek összetettségéről és arról, hogyan változtatja meg az AI a tesztelői munkát. Ha felelős vagy egy banki fejlesztési projekt sikeréért, ez az epizód abban is segít átlátni, mennyibe kerülhet egy időben fel nem tett kérdés.

🎙️ Nézd meg vagy hallgasd meg a teljes epizódot!

Youtube

Spotify

Apple Podcast