Magyar 
English (UK) 
Deutsch Amikor a komplex architektúra felemészti a tesztidőt
„Miért van ennyi hiba az éles rendszerben, ha egyszer már leteszteltük?”
„Megint a tesztelés miatt csúszunk, pedig már nem lehet tovább tologatni a go-live-ot.”
„Papíron van tesztelési folyamatunk, de a gyakorlatban mégsem működik…”
Ismerősek ezek a kérdések?
Egy átlagos nagyvállalati IT-környezetben az architektúra ma már messze nem arról szól, hogy „van egy monolit ERP és egy-két interfész”. A legtöbb nagyvállalatnál mikroszervizek, API-first architektúrák, hibrid cloud (on-prem + AWS/Azure/GCP), több tucat integráció (ERP, CRM, billing, logisztika, identity, mobilapp, webportál) és 3–8 párhuzamos vendor együttműködése a realitás.
A rendszer ettől nem egyszerűen nagyobb lett, hanem minőségileg is megváltozott. A komplexitás ráadásul hálózatszerűen nő: minden új interfész többszörösére emeli a potenciális hibapontok számát.
Mi ezzel a gond?
Alapvetően semmi, hiszen ezek a modern architektúrák számos előnyel járnak – legyen szó a gyors üzleti reakcióképességről, a rugalmasságról és vendorfüggetlenségről, a skálázhatóságról vagy az üzleti kísérletezés lehetőségeiről. A baj csak akkor van, amikor az új rendszer bevezetésre vagy frissítésre kerül, a cég tesztelési gyakorlata pedig – ha van egyáltalán – még mindig a „régi világra” van optimalizálva. Ebből egyenesen következnek a jól ismert jelenségek: integrációs hibák élesben, regressziós problémák minden új release után, és a „ha marad rá idő” típusú tesztelés és krónikus bizonytalanság a go-live döntéseknél.
A TestIT-nél mi is gyakran találkozunk hasonló fennakadásokkal, amik jelentősen befolyásolják egy-egy IT-projekt sikerességét, ezért most segítségképpen részletesebben is körbejárjuk, hogy tipikusan miért csúsznak, hibáznak és drágulnak túl gyakran a nagyvállalati IT-projektek a tesztelési folyamat rejtett gyengeségei miatt, és milyen irányba érdemes elindulni, ha valaki ezen változtatni szeretne, vagy legalább a főbb lehetséges csapdákat elkerülné.
Az okok, amik hozzájárulnak az IT projektek csúszásához
Első ok: Sok alkalmazás, sok interfész, kevés tesztidő
Nagyvállalati környezetben ma tipikus probléma, hogy több tucat üzleti alkalmazás kommunikál egymással, akár több száz interfész (API, batch, message queue) működik, és a fejlesztésben vegyes csapatok (in-house, nearshore, offshore, vendor) dolgoznak egyszerre. Közben a release-ciklusok rövidülnek: a korábbi negyedéves vagy féléves ütemet sok helyen havi, akár két heti kiadások váltják fel.
A World Quality Report (Capgemini–Sogeti–Micro Focus) utóbbi kiadásai szerint a szervezetek 60–70%-a érzi úgy, hogy a rendszerkomplexitás nagyobb ütemben nő, mint a QA-kapacitás és -kompetencia. Ez jól látszik a projektek ütemezésén: a scope nő, az integrációk szaporodnak, a fejlesztés csúszását valahogy be kell nyelni, a go-live dátum viszont marad, mert üzleti okokból nincs rá mozgástér.
És mi húzza ilyenkor a rövidebbet? A tesztelésre kijelölt idő. A tervezett 6 hétből lesz 3, sokszor papíron még mindig „ugyanazzal a scope-pal”. Ebből a 3 hétből 1 hét megy el integrációs tűzoltásra és környezeti problémákra, egy hét UAT-re, és jó esetben marad egy hét regresszióra. Ez nyilvánvalóan kevés egy 100+ interfészt használó architektúrákban. Nem véletlen, hogy a Gartner és a Forrester elemzései szerint nagyvállalati környezetben a hibák 60–80%-a integrációs és regressziós természetű: nem önmagukban az egyes modulokban, hanem azok illeszkedésében vannak a gondok.
Második ok: Nem az embertől várjuk a tudást, hanem a folyamattól
A tudás márpedig néhány kulcsember fejében kellene, hogy legyen. A tesztelési folyamatnak pedig erre kell ráépülnie. Amíg nincs megfelelően rendszerezve és dokumentálva ez a tudás, addig nagyon nehéz dolgunk lesz teszteléskor. Az ISTQB-szabványok és az ISO/IEC/IEEE 29119 is azt hangsúlyozzák, hogy a tesztelés akkor működik hosszú távon, ha ismételhető a folyamat, nem pedig tűzoltásszerűen alkalmazzák.
A gyakorlatban azonban gyakran az alábbi kép rajzolódik ki:
1. 3–5 kulcsember érti ténylegesen a rendszert és az üzleti folyamatokat.
2. A tesztesetek és tapasztalatok jelentős része „fejben” vagy elszórt Excel-táblákban, régi Confluence-oldalakon létezik.
3. Az end-to-end folyamatok dokumentációja hiányos vagy elavult.
„Judit tudja, hogyan kell ezt végigtesztelni, az elmúlt 9 évben mindig ő csinálta” – a gyakorlatban előfordulhat, hogy Judit eddig elengedő volt a teszteléshez, azonban egy komplex rendszer teszteléséhez már biztosan nem, és nagyon is kockázatos lenne, ha rábíznánk ezt a feladatot. A „Nincs időnk dokumentálni, előbb menjen ki a release” – hozzállás rejtett veszélyeiről nem is beszélve.
Mi ezzel a probléma? Az, hogy ilyenkor nem lehet pontosan megmondani, hogy:
- mit teszteltünk le és mit nem
- nem lehet értelmesen priorizálni
- mi maradjon ki, ha fogy az idő
- és nem lehet gyorsan bővíteni a QA-kapacitást, mert a tudás nem adható át rendszerszinten
Harmadik ok: Hiányzó in-house tesztelési kompetencia és kapacitás
A QA-t sajnos még mindig sok helyen „utolsó pillanatos ellenőrzésnek” tekintik, nem pedig stratégiai minőségmenedzsmentnek. A stratégiai IT-döntések QA-szempontjai gyakran háttérbe szorulnak. Vagyis:
- nincs egységes, vállalati szintű tesztelési stratégia és módszertan, csak projekt- és vendor-szintű QA „kicsiben”,
- a QA-munka túlnyomórészt vendor oldalon történik, a megrendelő oldalon nincs erős tesztmenedzsment szerep,
- az üzleti oldal UAT-érettsége alacsony: gyakran csak rápillantanak az UI-ra, és ezzel le is van tudva ez a feladat.
Amikor pedig gond van, a hibák oda-vissza „pattognak” a felek között, és nincs, aki a QA egészét egybefogná.
Negyedik ok: Folyamatos release-nyomás, low time-to-market
Az IT ma már minden iparágban a core business része. Bankoknál a mobilapp és az online banki élmény, telkóknál a self-service portál, gyártóknál a digitális ellátási lánc és partnerportálok, B2B-ben az API-ekoszisztéma. A menedzsment joggal vár gyors release-t és gyors ROI-t – de a minőség időigényét sokszor nincs kedvünk beárazni.
Az IEEE Software publikációi és több iparági tanulmány rendre azt mutatják, hogy
- egy kritikus hiba megelőzése a korai tesztelési fázisban „1 egység” költség,
- ugyanez a hiba a rendszer- vagy UAT-fázisban „10–50 egység”,
- ha élesben derül ki, akkor „100+ egység” (üzemszünet, SLA-büntetés, reputációs kár, ügyfélvesztés).
Ennek ellenére az utolsó hetekben gyakran az hangzik el: „Most az egyszer engedjük el a teljes regressziót, úgyis csak egy kisebb módosítás.” Ezekből a „kisebb” módosításokból lesznek az olyan éles hibák, amelyek egy egész folyamatot tesznek használhatatlanná.
Tehát akkor hol is bukik el az IT-projektfolyamat valójában?
A fentiekből világosan látszik, mi hiányzik – vegyük ezeket még egyszer sorra:
✘ Nincs tesztelési stratégia és egységes, vállalati szintű tesztelési módszertan
A legtöbb szervezetnél létezik valamilyen projektszintű tesztterv, UAT-checklista, esetleg regressziós Excel-tábla. Ami hiányzik, az az egységes, vállalati szintű tesztelési stratégia, amely egyértelműen meghatározza, hogy:
- mit jelent a „kész” különböző rendszer- és release-típusoknál,
- mely tesztelési szintek kötelezőek (unit, integration, system, E2E, UAT, non-functional),
- milyen mérőszámok (coverage, defect escape rate, hibasűrűség) alapján tekintünk elfogadhatónak egy release-t,
- hogyan működik együtt a belső QA a vendor QA-jával, ki miért felel.
Ha nincs központi stratégia erre, akkor minden projekt saját szabályrendszert alakít ki, méghozzá eltérő minőségi szintekkel és várakozásokkal. Két egymást követő projektben teljesen más lehet a „kellően leteszteltük” jelentése, a menedzsment pedig minden go-live döntést „félhomályban” hoz meg.
✘ Nincs végponttól végpontig tervezett regressziós készlet
A regressziós tesztelés általában két szélsőség között ingadozik: vagy „mindent újratesztelnénk” (ami időben lehetetlen), vagy „csak az érintett modult nézzük át” (ez pedig egy integrált ökoszisztémában illúzió).
A realitás egy priorizált, kockázatalapú E2E regressziós készlet, amely:
- lefedi az üzletmenet szempontjából kritikus folyamatok működéséhez, a bevételhez és reputációhoz legszorosabban kötődő üzleti folyamatokat (order-to-cash, billing, partnerkezelés, core banking folyamatok stb.),
- felismeri a keresztmetszeti funkciókat (például jogosultság, árazás, számlázás), amelyek több rendszeren átívelnek,
- tartalmaz kulcsfontosságú nem-funkcionális teszteket is (teljesítmény, biztonság).
Erre egyébként az ISTQB és a World Quality Report is rámutat – a szervezetek többségénél úgy tűnik, nincs formalizált, karbantartott regressziós katalógus. Amíg ez hiányzik, addig minden release egyfajta „orosz rulett”. A tesztelés félig improvizált, és a „Miért nem vettük ezt észre?” kérdés minden komolyabb incidensnél előkerül.
✘ Nincs helye a tesztelésnek a projektben
A projektek időkorlátosak, a scope pedig ritkán csökken. Ha a tesztelés nincs keményen beágyazva a projektirányítási keretrendszerbe (gate-ek, minőségi kritériumok formájában), akkor a tesztidő válik soft-scope elemmé: ez az, amit elkezdenek lenyirbálni. A tesztelés „ad hoc” módon történik, ha marad rá idő.
Egy tipikus lefutása ennek így néz ki:
- a tesztkörnyezet késve készül el, ezért csúszik az integrációs teszt,
- a performance test kimarad, „most nem fér bele” vagy „általában nem szokott probléma lenni”
- az üzleti oldal UAT-je lerövidül vagy production pilot jellegűvé válik.
Ilyenkor a döntés, hogy mit hagyjunk ki, nem strukturált kockázatelemzés, hanem gyors, politikai és határidő-vezérelt alkudozás eredménye. A végeredmény váratlanul jelentkező hibák élésben, utólagos tűzoltás, és mindezt megkoronázza az IT-val szembeni bizalomvesztés.
A tesztautomatizálás megtérülése: mikor éri meg és hogyan számoljuk ki?
A tesztautomatizálás megtérülése kulcskérdés minden vállalat számára. Bemutatjuk azokat a tényezőket, amelyek befolyásolják a ROI-t, mikor érdemes beruházni, és hogyan kerülhetők el a leggyakoribb buktatók…
Mire van tehát szükség? End-to-end test management és QA governance
Nagyvállalati környezetben a tesztmenedzsment önálló szakma.
Nem arról szól, hogy „szerzünk pár tesztelőt”, hanem arról, hogy a minőséget rendszerszinten tervezzük, irányítjuk és mérjük, egy jól definiált keretrendszerbe ágyazva.
Ez többek között az alábbiakat jelenti:
- end-to-end test strategy készül
- működik a QA governance
- mérhetővé válik a minőség
End-to-end test strategy | QA governance | Skálázhatóság |
az üzleti célokból és kockázatokból indul ki | van dedikált szerepkör (test manager / QA lead), aki a QA szabályait birtokolja | például defect escape rate (mennyi hiba jut ki élesbe) |
illeszkedik az architektúrához és a delivery modellhez (waterfall, agile, SAFe, DevOps) | tiszták a felelősségek a belső csapatok és a vendorok között | regressziós lefedettség |
definiálja a kötelező tesztszinteket, minőségi kapukat, riportolási elvárásokat | standardizált metrikák alapján történik a minőség követése | üzletileg kritikus folyamatok hibaaránya |
SLA- és OLA-teljesülés QA-nézőpontból |
✔ Tesztautomatizálás ott, ahol valódi értéket teremt
A tesztautomatizálás megtervezésekor elsődleges kérdés az, hogy mit érdemes automatizálni, milyen szinten (unit, API, UI, E2E), milyen céllal (integráció, teljes regresszió, smoke, non-functional).
A tesztautomatizálás az alábbi esetekben különösen hatékony:
- API-szinten mikroszerviz- és integráció-centrikus környezetben, mert kevésbé törékeny, mint a tisztán UI-alapú automatizálás
- a kritikus üzleti folyamatok automatizált regressziójakor, például könyvelési vagy core banking alapfolyamatoknál
- automatizált tesztfuttatásnál CI/CD-be kötve, minőségi „gate-ekkel”
A legtöbb tesztautomatizálás a UI-szkriptek karbantartásába fullad és a szervezeteknek csak egy kis része tudja azt stratégiai, E2E-szinten hasznosítani. A megoldás az, hogy az automatizálás tesztmenedzsmentből induljon, üzleti prioritásokhoz igazítva, reális ROI-számítással. Ugyanis nem a technológia, hanem a stratégia dönti el, mi térül meg.
✔ AI-assisted testing – emergens, de már kézzelfogható trend
Az AI/ML-alapú teszteléstámogatás számos formában megjelenhet: prediktív hibakeresésben, automatikus test case-generálásban, UI-változásokhoz alkalmazkodó tesztszkriptekben, logelemzésben és anomália-detektálásban. Gartner és Forrester előrejelzések szerint a következő 3–5 évben a QA-eszközök jelentős része ilyen képességekkel bővül.
Ez segíthet gyorsabban karbantartani és optimalizálni a regressziós készleteket, azonosítani lefedetlen területeket, csökkenteni a manuális, repetitív QA-munkát. De fontos, hogy ez nem helyettesíti az alapokat. Ha nincs tesztelési stratégia, nincs E2E regressziós katalógus, nincs tiszta QA-governance, és az AI csak az „okos káoszt” fogja támogatni. A valódi érték ott jelenik meg, ahol már van stabil QA-folyamat, és az AI ezt gyorsítja, nem pótolni próbálja.
Ha bizonytalan saját tesztelési folyamata hatékonyságában, ezen a checklisten menjen végig…
Azokban, akik már megéltek néhány éles hibát vagy fájdalmasan csúszó release-t, felmerülhet a kérdés, hogy mennyire felel meg a jelenlegi tesztelési folyamatuk a saját nagyvállalati környezetükben.
Erre belülről gyakran nehéz őszinte, objektív választ adni. Ezért érdemes külső, független QA-szemüveget kérni, amely nem a fejlesztői, nem is (csak) a vendor, hanem a vállalati és üzleti kockázati nézőpontból vizsgálja, hogy:
- Van-e egységes tesztstratégia, teszt metodológia és QA-governance?
- Létezik-e priorizált E2E regressziós készlet a legkritikusabb folyamatokra?
- Mennyire hatékony a jelenlegi tesztautomatizálás, hol lenne értelme bővíteni?
- Hogyan illeszkedik a QA-folyamat az agilis/DevOps/hibrid működéshez?
- Hogyan kezelik az integrációs és non-functional kockázatokat?
Miben tud segíteni a TestIT?
A TestIT-ben a fenti megközelítéssel nyújtunk olyan tesztmenedzsment és QA-tanácsadási szolgáltatásokat, amelyek:
- felmérik a jelenlegi QA-érettséget,
- az iparági szabványok (ISTQB, ISO/IEC/IEEE 29119) és trendek (World Quality Report, Gartner, Forrester) alapján ajánlanak fejlesztési irányokat,
- segítenek kialakítani a tesztelési módszertant vagy finomhangolni az end-to-end tesztmenedzsment keretrendszert,
- és támogatják egy reális, üzletileg is védhető tesztautomatizálási stratégia megalkotását.
Mindezt sok éves, markáns nagyvállalati tapasztalattal a hátunk mögött, hiszen már számos piacvezető cég nagyvállalati rendszerét világítottunk át, és végeztük el komplex IT-rendszereinek szoftvertesztelői, tesztmenedzsmenti feladatait sikeresen.
Ha kérdése van, keressen minket – akár egy rövid, fókuszált QA-audit is képes sok vakfoltot láthatóvá tenni.
FAQ
1. Mekkora szervezetnél érdemes külön test management, QA governance funkciót kialakítani?
Ott már biztosan indokolt, ahol több kritikus üzleti rendszer (ERP, CRM, billing, core banking, logisztika stb.) működik párhuzamosan, éves szinten több egymásra épülő projekt és release fut, és több vendor dolgozik egyszerre. Ilyen környezetben a QA-nak érdemes önálló „lábakat” adni: dedikált tesztmenedzserrel, QA-leaddel és világos governance-kerettel.
2. Hogyan kezdjünk hozzá, ha eddig főleg manuális, ad hoc tesztelésünk volt?
Nem kell mindent egyszerre megreformálni. Gyakorlatban bevált lépések:
- gyors Testing Survey QA-helyzetfelmérés (folyamatok, eszközök, szerepkörök áttekintése),
- egy–két kritikus üzleti folyamat kiválasztása, ezekhez E2E regressziós katalógus kialakítása,
- pilot automatizálás a legstabilabb és legfontosabb tesztekre,
- a tapasztalatok alapján fokozatos kiterjesztés a vállalati rendszerportfólióra.
3. Valóban szükségünk van külső QA-partnerre, ha van saját IT-csapatunk?
Nem mindenre, de bizonyos helyzetekben nagyon megtérül. Egy külső partner:
- objektív rálátást hoz olyan strukturális problémákra, amelyeket belülről nehéz észrevenni,
- specializált tudást biztosít (test management, non-functional tesztelés, automatizálási stratégia, AI-assisted testing),
- lerövidíti a tanulási görbét a bejáratott módszertanok és best practice-ek átvételével.
A cél nem az, hogy a külső partner átvegye a QA-t, hanem hogy megerősítse és feljebb pozicionálja a belső minőségbiztosítást.
