Spoiler: mert nem fogja megtalálni a hibákat.
Legalábbis nem az összeset. És éppen azokat nem, amelyek aztán az éles bevezetés után derülnek ki — a legrosszabb pillanatban, a legdrágább körülmények között.
Ezt nem a fejlesztők ellen mondom. Ellenkezőleg: a legjobb fejlesztők is pontosan tudják, hogy a saját kódjukat nem érdemes tesztelni. Mert nem lustaságból maradnak el a hibák — hanem egy teljesen természetes, pszichológiai jelenség miatt. De kezdjük az elején.
A confirmation bias — amit mindenki ismer, de kevesen neveznek meg
Van egy klasszikus kísérlet a pszichológiában. Megkérnek egy csoportot, hogy számolják meg egy kosárlabda videóban a fehér csapatnak a passzmozdulatait. A feladat annyira leköti a figyelmet, hogy a résztvevők nagy része egyszerűen nem veszi észre a videó közepén átmasírozó gorilla jelmezes embert.
A fejlesztői tesztelés pontosan így működik.
Amikor egy fejlesztő teszteli a saját kódját, a fejében már ott van a megoldás — tudja hogyan készült, tudja mire gondolt amikor írta, és öntudatlanul azon az úton jár végig amit a rendszer kezelni tud. Az edge case-eket, a boundary condition-öket, a kivételes helyzeteket — azokat ahol a rendszer összeomlik — ritkán találja meg. Mert a gondolkodásmódja ugyanaz, ami a hibát létrehozta.
Ez nem hiba. Ez az emberi agy természetes működése.
Három eset amiből tanultam
Biztosítói kárbejelentő rendszer
Egy biztosítónál dolgoztunk egy ügyfélszolgálati mobilalkalmazáson. A fejlesztőcsapat alapos munkát végzett, belső teszteket futtatott, minden zöld volt. Mi vittük be a független QA-t az utolsó fázisba.
Az első nap végén a QA kolléga megtalálta, hogy ha az ügyfél a kárbejelentési folyamat közben megkapja a bejövő hívást, elfogadja, majd visszatér az appba — a folyamat elveszti az addig beírt adatokat, de erről semmilyen visszajelzést nem ad. Az ügyfél újrakezdheti az egészet, fogalma sincs miért.
A fejlesztők egyszerűen nem gondoltak erre a scenárióra. Nem lustaságból — hanem mert ők a kárbejelentési folyamatot tesztelték, nem a telefon interrupt-kezelést kombinálva a kárbejelentési folyamattal.
Salesforce integráció biztosítói CRM bevezetésnél
A Salesforce bevezetésnél a fejlesztőcsapat tesztelte az integrációt a meglévő biztosítási rendszerrel. Az alapfolyamatok működtek. Amit nem teszteltek: mi történik ha ugyanazt az ügyfelet egyszerre két ügyintéző próbálja módosítani különböző rendszerekből. Az éles bevezetés második napján ez pontosan megtörtént — és az adatok inkonzisztens állapotba kerültek.
A fejlesztők azért nem tesztelték ezt a scenáriót, mert az ő fejlesztői tesztkörnyezetükben egyetlen tesztelő dolgozott egyszerre. Az éles környezetben 40 ügyintéző.
Lízingcéges workflow rendszer
Egy operatív lízingcégnél a workflow automatizáció fejlesztői tesztjei sikeresen lefutottak. A független QA az első napon megtalálta, hogy a rendszer a speciális karaktereket tartalmazó ügyféladatoknál (ékezetes nevek, kötőjelek) hibásan kezeli az adatbázis-kommunikációt. Magyar piacon. Magyar nevekkel.
A fejlesztők latin betűs tesztadatokkal dolgoztak. Természetes — ők is latinul gondolkodnak, amikor tesztadatot írnak be.
A pszichológia mögötte — miért strukturális ez a probléma
A független tesztelés nem azért jobb mert a QA-k tehetségesebbek a fejlesztőknél. Azért jobb, mert más a perspektívájuk.
Egy független tesztelő több más jellegű hibát vehet észre, mint aki a programozókkal együtt dolgozik, mivel más rálátása lehet a projektre, illetve észrevehet olyan problémákat is, amelyek a fejlesztő csapat gondolkodásmódjából erednek.
Ez a kulcsmondat. Nem a hibák mennyiségéről van szó — hanem a minőségükről. A fejlesztő megtalálja azokat a hibákat, amelyek a kód logikájából fakadnak. A független tesztelő megtalálja azokat, amelyek az üzleti logika és a kód logikájának ütközéséből fakadnak — és ezek az igazán drága hibák.
Pénzügyi szektorbeli projekteknél ez hatványozottan igaz. Egy biztosítási kalkulátor hibájánál nem az a kérdés, hogy a kód szintaktikailag helyes-e — hanem az, hogy a biztosítási díjszámítási logika megfelel-e a termékleírásnak. Ezt a fejlesztő nem tudja ellenőrizni, mert nem ismeri a termékleírást a mélységében. A jó QA viszont igen.
"De nálunk a fejlesztők unit tesztet is írnak"
Igen. Ez jó. A unit teszt megtalálja a kód szintű hibákat.
De a unit teszt nem helyettesíti a funkcionális tesztelést, az integrációs tesztelést és a felhasználói elfogadási tesztelést. Mert a unit teszt azt ellenőrzi, hogy egy izolált kódrész az elvárások szerint működik-e. Nem azt, hogy az egész rendszer a valódi felhasználói viselkedésre hogyan reagál.
Az autógyártásban van egy hasonló különbség: az alkatrészek egyenként mind megfelelnek a minőségi előírásoknak — aztán az összeszerelt autóban a légkondicionáló és a navigáció egyszerre bekapcsolva lemerítik az akkumulátort. Ezt az alkatrészszintű tesztek nem fogják megtalálni.
Mikor elegendő a fejlesztői tesztelés?
Az objektivitás kedvéért: nem minden projekthez kell dedikált független QA. Vannak esetek amikor valóban elegendő a fejlesztői tesztelés.
Ha a projekt rövid és jól körülhatárolt, a felhasználói bázis kicsi és homogén, a hibák következménye alacsony kockázatú, és van gyors visszacsatolási lehetőség az éles környezetből — akkor a fejlesztői tesztelés elfogadható kompromisszum.
De ha bármelyik teljesül az alábbiak közül, a független tesztelés nem opcionális:
— Pénzügyi adatokat kezel a rendszer— Több száz vagy ezer felhasználó fogja egyszerre használni— Compliance vagy szabályozói megfelelés érintett— A hiba következménye ügyfélkár, adatvesztés vagy reputációs kár— A rendszer meglévő core rendszerekkel integrálódik
Pénzügyi szektorbeli projekteknél ezek szinte mindig teljesülnek.
Amit a FrontX-nél másképp csinálunk
A FrontX QA-i nem a fejlesztés végén lépnek be. Shift-left megközelítéssel dolgozunk: a tesztelő már a specifikáció review-jánál jelen van, a fejlesztési sprint közben párhuzamosan teszteli az elkészült funkciókat, és nem egy hatalmas végső tesztelési ciklusban próbálja meg megtalálni az összes hibát.
Ez azért működik, mert a QA nem a fejlesztőcsapat munkatársa — hanem független szemmel néz a rendszerre. Nincs szociális nyomás, hogy "ne kritizálja a kolléga munkáját." Nincs érdekeltség a hibák eltussolásában. Van viszont pénzügyi szektorbeli iparági háttér — ami azt jelenti, hogy a QA érti az üzleti logikát, amit tesztel.
Ha senior QA szakértőt keresel aki érti a pénzügyi szektor folyamatait — vagy ha QA-ként dolgozol és olyan helyen szeretnél lenni ahol a tesztelés stratégiai szerep, nem utólagos ellenőrzés — nézd meg hogyan dolgozunk: frontx.hu/allasajanlatok
Kérdés hozzád
Találkoztál már olyan hibával éles bevezetés után, amit egy független tesztelő valószínűleg megtalált volna előtte? Mi volt a legdrágább "meglepetés" amit az éles rendszer hozott?
Gyakran ismételt kérdések
Miért ne tesztelje a fejlesztő a saját kódját?
Mert a fejlesztő öntudatlanul azokat az utakat járja be tesztelés közben, amelyeket a rendszer kezel — nem azokat, ahol hibázik. A confirmation bias miatt a saját kód tesztelése strukturálisan korlátozott: a fejlesztő ugyanolyan gondolkodásmóddal tesztel, amellyel a kódot írta. A független tesztelő más perspektívából közelít, és olyan hibákat talál, amelyek a fejlesztő gondolkodásmódjából fakadnak.
Mi a különbség a fejlesztői tesztelés és a független QA között?
A fejlesztői tesztelés (unit tesztek, integrációs tesztek) a kód szintű hibákat találja meg. A független QA az üzleti logika és a kód ütközéséből fakadó hibákat találja meg — azt ellenőrzi, hogy az egész rendszer a valódi felhasználói viselkedésre hogyan reagál. A kettő nem helyettesíti egymást.
Mikor szükséges független tesztelés IT projekteknél?
Mindenképpen szükséges, ha a rendszer pénzügyi adatokat kezel, több száz felhasználó fogja egyszerre használni, compliance vagy szabályozói megfelelés érintett, vagy a rendszer meglévő core rendszerekkel integrálódik. Pénzügyi szektorbeli projekteknél ezek szinte mindig teljesülnek.
Mit jelent a shift-left tesztelés a független QA kontextusában?
A shift-left tesztelés azt jelenti, hogy a független QA nem a fejlesztés végén lép be, hanem a projekt elejétől jelen van — a specifikáció review-tól a fejlesztési sprint párhuzamos teszteléséig. Ez drasztikusan csökkenti az utólagosan javítandó hibák számát.
Hogyan különbözik a FrontX QA megközelítése?
A FrontX QA-i shift-left szemlélettel dolgoznak, pénzügyi szektorbeli iparági háttérrel. Nem csak a technikai hibákat keresik — hanem azt is ellenőrzik, hogy az üzleti logika helyesen van-e implementálva. Nem kell elmagyarázni a biztosítási folyamatot, a lízingszerződés életciklusát vagy a banki compliance elvárásokat — ezt már hozzák.
Szerzői bio
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: linkedin.com/in/laszlobehan | FrontX blog: frontx.hu/blog
