Miért ne tesztelje a fejlesztő a saját kódját? Mert nem fogja megtalálni a hibákat. Legalábbis nem az összeset, és éppen azokat nem, amelyek aztán élesben derülnek ki, a legrosszabb pillanatban és a legdrágább módon. Ez nem a fejlesztők kritikája: a legjobb fejlesztők is tudják, hogy a saját munkájukra vakok. Ez a cikk megmutatja, miért, mit tanultunk négy valós esetből, mit mond erről a kutatás, és mit változtat az AI által írt kód.
Röviden
- A saját kód tesztelése strukturálisan korlátozott: a fejlesztő ugyanazzal a gondolkodásmóddal tesztel, amellyel a hibát létrehozta.
- A fejlesztői tesztelés ettől még nagyon értékes: egy Microsoft és IBM csapatokon végzett kutatásban a tesztvezérelt fejlesztés 40-90 százalékkal csökkentette a hibasűrűséget.
- A kérdés tehát nem az, hogy a fejlesztő teszteljen-e, hanem az, hogy csak ő teszteljen-e.
- Az AI-val írt kódnál a független ellenőrzés még fontosabb: a Veracode vizsgálatában az esetek 45 százalékában biztonsági hibát tartalmazott a generált kód.
- Pénzügyi szolgáltatóknál a DORA a kritikus rendszerek tesztelésénél független tesztelőt ír elő.
Nem a fejlesztő a hibás, hanem az emberi figyelem
Simons és Chabris 1999-es híres kísérletében a résztvevőknek egy kosárlabdás videóban kellett megszámolniuk a fehér mezes játékosok passzait. A feladat annyira lekötötte a figyelmüket, hogy sokan egyszerűen nem vették észre a képen átsétáló, gorillajelmezes embert. Ezt figyelmi vakságnak (inattentional blindness) hívják: amire nem figyelünk, azt nem látjuk, akkor sem, ha a szemünk előtt van.
A saját kód tesztelésénél ehhez társul a megerősítési torzítás (confirmation bias) is: azt keressük, ami igazolja, hogy jól dolgoztunk. A fejlesztő fejében ott a megoldás, tudja, hogyan készült, és öntudatlanul azokon az utakon halad végig, amelyeket a rendszer kezel. A határeseteket, a kivételeket és a váratlan felhasználói viselkedést ritkán próbálja ki, mert ugyanaz a gondolkodásmód, amely a hibát létrehozta, a tesztelést is irányítja. Ráadásul jellemzően csak az általa módosított részt nézi meg, ugyanazokkal a tesztadatokkal.
Ez nem hanyagság, hanem az emberi agy természetes működése.
Négy eset, amiből tanultam
Oracle-eljárás élesítése egy számlázó rendszerben
Rendszerszervezőként egy Oracle-alapú megrendelő- és számlázórendszerhez írtunk új betöltő eljárást egy új online csatornához. Késésben voltunk, ezért péntek délután én teszteltem az elkészült programot, és megnézte a programozó is. Tökéletesen működött. Este hét körül élesítettük, és hazamentünk. És tényleg működött, de csak az új funkció. A függőségek miatt az adatbázis összes többi eljárása érvénytelen állapotba került, így 16 országban leállt a számlázás és az online megrendelések feldolgozása. Csak az újat ellenőriztük, a többit nem. Másnap hajnalra sikerült mindent újraindítani.
Biztosítói kárbejelentő mobilalkalmazás
Egy biztosító ügyfélszolgálati mobilalkalmazásán a fejlesztőcsapat alapos munkát végzett, minden belső teszt zöld volt. Az utolsó fázisba független tesztelőt vontunk be, aki már az első napon megtalálta, hogy ha az ügyfél kárbejelentés közben fogad egy hívást, majd visszatér az alkalmazásba, minden addig beírt adat elvész, mindenféle visszajelzés nélkül. A fejlesztők a kárbejelentést tesztelték, nem a telefonhívás és a kárbejelentés kombinációját.
Lízingcéges workflow-rendszer
Egy operatív lízingcégnél a workflow-automatizálás fejlesztői tesztjei mind sikeresek voltak. A független tesztelő az első napon kiderítette, hogy a rendszer hibásan kezeli az ékezetes és kötőjeles ügyféladatokat. Magyar piacon, magyar nevekkel. A fejlesztők ékezet nélküli, angol tesztadatokkal dolgoztak, mert ők is így gépelnek tesztadatot.
Telefonos IVR-rendelési rendszer
Egy FMCG-cégnél telefonos, gombnyomásos rendelési rendszert fejlesztettünk. Minden funkció működött, az élesítés után viszont egy órán belül összeomlott. Kiderült, hogy sok egyidejű gombnyomást a szerver nem bírt, ráadásul az egyidejű hívások számáról kapott adatok is tévesek voltak. Terheléses teszt nem volt, eszünkbe sem jutott.
A négy eset közös tanulsága, hogy egyik hiba sem a kód logikájában volt. Mindegyik ott keletkezett, ahová a fejlesztő nem nézett:
| Eset | Ami kimaradt | Melyik teszt találta volna meg |
|---|---|---|
| Oracle-számlázórendszer | A meglévő funkciók működése a változtatás után | Regressziós teszt |
| Biztosítói mobilalkalmazás | Valós felhasználási helyzet (bejövő hívás) | Forgatókönyv-alapú, felfedező tesztelés |
| Lízingcéges workflow | Valósághű tesztadat (ékezetes nevek) | Tesztadat-tervezés, határérték-vizsgálat |
| IVR-rendszer | Valós terhelés | Terheléses és teljesítményteszt |
A fejlesztői tesztelés értékes, csak nem elég
Fontos tisztázni: a fejlesztőnek igenis tesztelnie kell. Nagappan és társai (Microsoft, IBM, North Carolina State University) négy ipari csapatot vizsgáltak, ahol a tesztvezérelt fejlesztést (TDD) alkalmazó csapatoknál a kiadás előtti hibasűrűség 40-90 százalékkal alacsonyabb volt, mint a hasonló, TDD nélkül dolgozó csapatoknál. Az ára a vezetők becslése szerint 15-35 százalékkal hosszabb kezdeti fejlesztési idő volt, amit a csapatok szerint a kisebb karbantartási költség ellensúlyozott.
A Mike Cohn által megfogalmazott és Martin Fowler által népszerűsített tesztpiramis ezt a munkamegosztást írja le: sok gyors, alacsony szintű teszt az alján, kevesebb integrációs teszt középen, és kevés, de átfogó, a teljes rendszert érintő teszt a csúcson.
| Szint | Ki végzi jellemzően | Mit talál meg |
|---|---|---|
| Unit tesztek | A fejlesztő | Hibás logikát egy-egy kódrészben |
| Integrációs tesztek | Fejlesztő és tesztelő együtt | Hibás együttműködést modulok és rendszerek között |
| Rendszer- és end-to-end tesztek | Független tesztelő | Üzleti folyamatok hibáit, valós helyzeteket, regressziót |
| Nem funkcionális tesztek | Specialista tesztelő | Teljesítmény-, terhelési és biztonsági problémákat |
| Felhasználói átvétel (UAT) | Az üzleti terület, a tesztelő támogatásával | Azt, hogy a rendszer valóban a kért üzleti célt szolgálja-e |
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 hogyan reagál a valódi felhasználói viselkedésre. Az autógyártásban ugyanez a helyzet: minden alkatrész külön megfelel az előírásoknak, aztán az összeszerelt autóban a klíma és a navigáció együtt lemeríti az akkumulátort. Ezt alkatrészszintű teszt nem fogja megtalálni.
Nem az a kérdés, hogy a fejlesztő teszteljen-e. Hanem az, hogy csak ő teszteljen-e.
Miért más egy független tesztelő?
Nem azért, mert tehetségesebb a fejlesztőnél, hanem mert más a nézőpontja. Kívülről nézi a rendszert, a felhasználó szemével, és a tesztelés a fő feladata, ezért szisztematikusan tervezi meg: lefedettséget, határértékeket, kivételeket és regressziót vizsgál. A nemzetközi szoftvertesztelői minősítési testület, az ISTQB tananyaga szerint a független tesztelők más jellegű hibákat ismernek fel, mint a fejlesztők, mert más a hátterük és a szemléletük, és meg tudják kérdőjelezni azokat a feltételezéseket, amelyekre a fejlesztés épült.
Pénzügyi szektorban ez kétszeresen igaz. Egy biztosítási díjkalkulátornál nem az a kérdés, hogy a kód szintaktikailag helyes-e, hanem az, hogy a díjszámítás megfelel-e a termékleírásnak. Ezt a fejlesztő ritkán tudja ellenőrizni, mert nem ismeri mélyen a terméket, a domain-tudással rendelkező tesztelő viszont, szükség esetén az üzleti elemzővel együtt, igen. A DORA ezt szabályozói szintre is emelte: a kritikus vagy fontos funkciókat támogató rendszerek tesztelését független, belső vagy külső fél végezheti, összeférhetetlenség nélkül. A függetlenség szintjeiről és a kiszervezési modellekről bővebben: mikor érdemes kiszervezni a szoftvertesztelést.
Mi a helyzet, ha az AI írja a kódot?
Az AI-eszközök ma már a kód jelentős részét megírják, és teszteket is generálnak hozzá. Ez kényelmes, de új kockázatot hoz. A Veracode 2025-ös vizsgálatában több mint 100 nagy nyelvi modellt teszteltek 80 programozási feladaton, és a generált kód az esetek 45 százalékában tartalmazott biztonsági hibát. Java nyelven ez az arány 70 százalék fölött volt, a webes XSS-sérülékenységeknél pedig 86 százalékos volt a hibaarány. A tanulmány szerint a nagyobb és újabb modellek biztonsági szempontból nem teljesítettek érdemben jobban.
Ha ugyanaz az AI-eszköz írja a kódot és a teszteket is, az a függetlenség teljes hiánya: ugyanazok a feltételezések kerülnek a tesztbe, mint a kódba. Az AI által írt kódot ezért különösen érdemes független szemmel, biztonsági vizsgálattal és valós üzleti forgatókönyvekkel tesztelni. A szoftverminőség és az AI kapcsolatáról bővebben: tényleg rossz a szoftverek minősége?
Mikor elegendő a fejlesztői tesztelés?
Az objektivitás kedvéért: nem minden projekthez kell dedikált független tesztelő. Ha a projekt rövid és jól körülhatárolt, a felhasználói kör kicsi és egységes, a hiba következménye alacsony kockázatú, és élesből gyors a visszajelzés, a fejlesztői tesztelés elfogadható kompromisszum.
Ha viszont az alábbiak közül bármelyik teljesül, a független tesztelés nem opcionális:
- a rendszer pénzügyi vagy személyes adatokat kezel;
- több száz vagy ezer felhasználó használja egyszerre;
- compliance- vagy szabályozói követelmény érintett;
- a hiba ügyfélkárt, adatvesztést vagy reputációs kárt okozhat;
- a rendszer meglévő core rendszerekkel integrálódik;
- a kód jelentős részét AI-eszköz írta.
Pénzügyi szektorbeli projekteknél ezek szinte mindig teljesülnek.
Ellenőrzőlista: elég-e a fejlesztői tesztelés a projektedre?
- Írnak a fejlesztők unit teszteket, és ezek automatikusan lefutnak minden változtatásnál?
- Van regressziós teszt, amely a meglévő funkciókat is ellenőrzi egy módosítás után?
- Tesztel valaki, aki nem vett részt a fejlesztésben?
- Valósághű tesztadatokkal dolgoznak (ékezetek, határértékek, hibás bemenetek)?
- Van terheléses és teljesítményteszt a várható csúcsforgalomra?
- Kipróbálják a valós felhasználási helyzeteket (megszakítás, gyenge hálózat, párhuzamos használat)?
- Az AI által írt kódot és teszteket ember és biztonsági vizsgálat is ellenőrzi?
- Szabályozott környezetben dokumentáltan igazolható a tesztelés függetlensége?
Amit a FrontX-nél másképp csinálunk
- Korán kapcsolódunk be (shift-left): a tesztelő már a specifikáció átnézésénél jelen van, és a sprintekben párhuzamosan teszteli az elkészült funkciókat, nem egyetlen nagy záró tesztciklusban.
- Független szemmel tesztelünk: a tesztelő nem a fejlesztőcsapat tagja, így nincs szociális nyomás, hogy ne kritizálja a kolléga munkáját.
- Iparági tudást hozunk: tesztelőink értik a biztosítói, banki és lízinges üzleti logikát, és szorosan együtt dolgoznak az üzleti elemzőkkel.
- A fejlesztői unit teszteket nem kiváltjuk, hanem kiegészítjük regressziós, end-to-end, terheléses és biztonsági tesztekkel.
- Részletek a tesztelési szolgáltatásunk oldalán.
Ha szeretnéd felmérni, elég-e a jelenlegi tesztelési gyakorlatotok, szívesen segítünk: kérj ingyenes konzultációt.
Ha tesztelőként olyan helyen dolgoznál, ahol a tesztelés stratégiai szerep, nem utólagos ellenőrzés, nézd meg nyitott pozícióinkat.
Gyakran ismételt kérdések
Miért ne tesztelje a fejlesztő a saját kódját?
Mert a saját munkánkra vakok vagyunk: a fejlesztő öntudatlanul azokat az utakat járja be, amelyeket a rendszer kezel, nem azokat, ahol hibázik. A figyelmi vakság és a megerősítési torzítás miatt ugyanaz a gondolkodásmód irányítja a tesztelést, amely a hibát létrehozta. A független tesztelő más nézőpontból közelít, és más jellegű hibákat talál.
Akkor a fejlesztőnek egyáltalán ne kelljen tesztelnie?
Dehogynem. A fejlesztői unit tesztek és a tesztvezérelt fejlesztés nagyon értékesek: egy Microsoft és IBM csapatokon végzett kutatásban a TDD 40-90 százalékkal csökkentette a kiadás előtti hibasűrűséget. A fejlesztői tesztelés az alap, de a rendszer- és üzleti szintű hibákhoz független tesztelés is kell.
Mi a különbség a fejlesztői tesztelés és a független tesztelés között?
A fejlesztői tesztelés (unit és integrációs tesztek) a kód szintű hibákat találja meg. A független tesztelés azt ellenőrzi, hogyan reagál a teljes rendszer a valós felhasználói viselkedésre és az üzleti szabályokra, beleértve a regressziót, a terhelést és a biztonságot. A kettő kiegészíti egymást. Független tesztelést akkor érdemes kezdeni, amikor a rendszer már stabilan fut, különben a tesztelő ideje elmegy.
Mikor szükséges független tesztelés?
Ha a rendszer pénzügyi vagy személyes adatokat kezel, sok felhasználó használja egyszerre, szabályozói követelmény érinti, meglévő core rendszerekkel integrálódik, vagy a kód jelentős részét AI írta. Pénzügyi szolgáltatóknál a DORA a kritikus funkciókat támogató rendszereknél független tesztelőt ír elő.
Kell-e külön tesztelni az AI által írt kódot?
Igen. A Veracode 2025-ös vizsgálatában az AI által generált kód az esetek 45 százalékában tartalmazott biztonsági hibát. Ha ugyanaz az eszköz írja a kódot és a teszteket, a tesztek ugyanazokra a feltételezésekre épülnek, ezért független, emberi és biztonsági ellenőrzés kell.
Mit jelent a shift-left tesztelés?
Azt, hogy a független tesztelő nem a fejlesztés végén lép be, hanem a projekt elejétől jelen van, a specifikáció átnézésétől a sprintek közbeni párhuzamos tesztelésig. Így a hibák korábban, olcsóbban derülnek ki.
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
