Szoftvertesztelés közelről: Interjú Keresztúri Márkkal a minőségbiztosítás szerepéről

Keresztúri Márk már az egyetemi évei alatt tudta, hogy szoftvertesztelői karrierút vár rá. Azóta számos projektben részt vett, amelyekben egyedüli tesztelőként is megállta a helyét, és mára magabiztosan mozog mind a manuális, mind az automatizált tesztelés világában. A vele készült interjúból megismerheted, hogyan fejleszti folyamatosan a tudását, és miért tartja fontosnak a tesztelői szerepkört.

Szoftvertesztelés közelről_ Interjú Keresztúri Márkkal a minőségbiztosítás szerepéről.webp
Szoftvertesztelés közelről_ Interjú Keresztúri Márkkal a minőségbiztosítás szerepéről.webp

Keresztúri Márk már az egyetemi évei alatt tudta, hogy szoftvertesztelői karrierút vár rá. Azóta számos projektben részt vett, amelyekben egyedüli tesztelőként is megállta a helyét, és mára magabiztosan mozog mind a manuális, mind az automatizált tesztelés világában. A vele készült interjúból megismerheted, hogyan fejleszti folyamatosan a tudását, és miért tartja fontosnak a tesztelői szerepkört.

R: Szerinted milyen készségek és személyiségjegyek kellenek ahhoz, hogy valaki sikeres szoftvertesztelővé váljon?

M: Szerintem a sikeres szoftvertesztelő legfontosabb készsége a kritikus gondolkodás, sőt néha előnyös, ha kifejezetten „szokatlan" megközelítéseket is képes alkalmazni. Ez azért fontos, mert így könnyebben észrevehet olyan rejtett vagy váratlan hibákat, amelyekről sokan talán nem is gondolnák, hogy előfordulhatnak. Pedig a valós környezetben előbb-utóbb biztosan felszínre kerülnének. Szintén fontosnak tartom a folyamatos önfejlesztést: a szabadidőmben is igyekszem megismerni új, hasznos vagy éppen érdekes technológiákat és eszközöket. Így mindig naprakész maradok, és könnyebben tudok alkalmazkodni a tesztelés folyamatosan fejlődő világához.

R: Mit csinál egy szoftvertesztelő a munkája során? Milyen lépéseken mész végig egy-egy tesztelési projekt során?

M: A szoftvertesztelési folyamat nálam mindig a specifikációk áttekintésével és megértésével kezdődik. Ezt követően elkészítem a teszttervet, valamint létrehozom a teszteseteket. A fejlesztőkkel való szoros együttműködés kulcsfontosságú. Nálunk például kétkörös tesztelés működik: ha az első tesztfázisban találok hibákat, azok javítása után újra ellenőrzöm a rendszert. A tesztek dokumentálásához, futtatásához és a lefedettség méréséhez többnyire TestNavigator-t használok, de a Postman is gyakori segítőtársam. Automatizált teszteléshez szintén több eszköz jöhet szóba: dolgoztam már Cucumberrel, Pytesttel, és jelenleg Playwright-tal is.

A legnagyobb kihívás általában az, amikor egyszerre több projekten párhuzamosan kell dolgozni – most éppen három fut egyszerre. Ez azonban nem szokott akadályt jelenteni; inkább alapos tervezést és folyamatos egyeztetést igényel a csapattal, hogy minden időben és megfelelő minőségben elkészüljön.

R: A TestNavigator nemrég került bevezetésre nálatok. Milyen tapasztalataid vannak eddig a rendszerrel?

M: A TestNavigator bevezetése óta több szempontból is vizsgáltuk a rendszert. Az első benyomások alapján a szoftver intuitív, könnyen kezelhető és könnyű benne tájékozódni. Emellett a tesztek nyomon követése átláthatóbbá vált. Pozitívumként kiemelném az automatizált riportálási lehetőségeket és a tesztek státuszának könnyebb követhetőségét.

A Test Advisor score kimondottan értékes funkció, mivel objektív képet ad a tesztelés folyamatáról, és segít abban, hogy csak a szükséges teszteket futtassuk le, időt és energiát spórolva.

Ez kifejezetten jól jön egy tesztelőnek, ha több projekten is dolgozik egyszerre, valamint a menedzsmentnek, hiszen egy kézzel fogahtó képet kap a tesztelés állapotáról.

Emellett a regressziós tesztek kezelése is strukturáltabb lett, és az API-tesztek integrációja is gördülékenyebb, ami hozzájárul a hatékonyabb tesztelési folyamatokhoz.

R: Mi áll közelebb hozzád, az automatizált tesztelés vagy a manuális?

M: Az automatizált tesztelés kétségtelen előnye, hogy bár kezdetben komolyabb erőforrás- és időbefektetést igényel, később jelentősen megkönnyíti és felgyorsítja a tesztelési folyamatokat. Ezzel szemben a manuális tesztelésnél kiemelkedően fontos a részletes dokumentáció (tesztesetek, jegyzőkönyvek), amelyeket a specifikációk változása esetén mind frissíteni kell, és a teszteket ismételten, kézzel kell futtatni.

Összességében a választás mindig a projekt méretétől, a rendelkezésre álló erőforrásoktól és a hosszú távú céloktól függ: vannak helyzetek, amikor a gyors átfutás és a gyakori módosítások miatt jobban megéri az automatizáció. Máskor, főleg kisebb vagy egyszerűbb projektek esetén, a manuális megközelítés lehet hatékonyabb.

R: Szerinted milyen szerepe van a szoftvertesztelésnek egy fejlesztési projektek sikerében?

M: A szoftvertesztelés elengedhetetlen a fejlesztési projektek sikeréhez, hiszen a hibák korai felismerése és kijavítása jelentősen csökkenti a későbbi kockázatokat, időráfordítást és költségeket. Ha már a projekt korai szakaszától kezdve folyamatosan tesztelünk, a kisebb problémák is időben felfedezésre kerülnek, így nem alakulnak át súlyosabb, a teljes rendszert érintő hibákká. Ez a megközelítés a felhasználói és a megrendelői elégedettség szempontjából is fontos, mivel egy jól tesztelt szoftver megbízhatóbban, stabilabban működik.

Ha a tesztelés háttérbe szorul, vagy későn indul el, gyakran rejtve maradnak olyan kritikus hibák, amelyek a végfelhasználóknál vagy a megrendelőnél kellemetlen meglepetéseket okozhatnak. Ebből adódóan nő a valószínűsége a negatív visszajelzéseknek, és a projekt megítélése is romolhat. Éppen ezért célszerű már a fejlesztés kezdeti fázisában elkezdeni a teszttervezést és a folyamatos ellenőrzést, hogy a lehető legmagasabb szoftverminőséget biztosítsuk.

R: Milyen módszerekkel, eszközökkel fejleszted a szakmai tudásodat és képességeidet?

M: Gyakran veszek részt online tanfolyamokon, például az Udemy oldalán. Ezeknek köszönhetően mindig értesülök az új vagy éppen felkapott technológiákról, módszerekről, illetve a már ismert eszközök eddig nem ismert lehetőségeiről.

Úgy gondolom, a folyamatos tanulás és a különböző projektekben szerzett tapasztalatok együttesen teszik lehetővé, hogy bármilyen összetett vagy nehéz rendszerrel hatékonyan megismerkedjek, és eredményesen végezzem a minőségbiztosítási feladatokat.

R: Hogyan tudsz hatékonyan együttműködni fejlesztőkkel és más csapattagokkal?

M: Az elmúlt csaknem két és fél évben nem találkoztam jelentősebb konfliktussal vagy nézeteltéréssel, mivel a csapatunkban mindenki természetesnek veszi, hogy tisztelettel fordul a másikhoz. Tesztelőként mindig arra törekszem, hogy ha egy problémát vagy kérdést hatékonyabban lehet szóban elmagyarázni, akkor személyes megbeszélést vagy online meetinget szervezzek, különösen, ha valaki épp nincs az irodában. Scrum Master szerepemben pedig rendszeresen tartok Scrum meetingeket, amelyek segítik a csapatot abban, hogy minden feladatot és esetleges nehézséget időben átláthassunk.

Mivel gyakran egyedüli tesztelőként dolgozom a projekteken, a minőségbiztosítással kapcsolatos összes feladatért és felelősségért én felelek. Éppen ezért rendkívül fontos, hogy bármelyik csapattaggal könnyedén egyeztessek, akár fejlesztőkről, akár más szereplőkről van szó. Szerintem, nincs különleges titok: a lényeg, hogy emberként forduljunk egymáshoz, és őszintén kommunikáljunk, még akkor is, ha szorítanak a határidők, vagy valami váratlanul félresiklik.

R: Milyen tévhitekkel vagy előítéletekkel találkozol a szoftvertesztelői munkával kapcsolatban?

M: Nem IT-s közegben gyakran találkozom azzal a tévhittel, hogy egy tesztelő csak felületi „kattintgatással" foglalkozik, mintha a munkája lényegében nem is lenne több mint egy játék. A valóságban azonban a tesztelési folyamat jóval összetettebb: a funkcionalitás és a használhatóság ellenőrzésétől kezdve a hibák mélyebb feltárásáig, számos területet lefed.

A fejlesztési projektekben általában nincs szükség külön magyarázatra: mindenki tisztában van vele, hogy a tesztelő kulcsszerepet játszik a szoftver minőségének biztosításában. Különösen érdekes helyzetek akkor alakulnak ki, amikor a fejlesztő és a tesztelő eltérően értelmezik a specifikációban leírtakat, ilyenkor ugyanis pontos egyeztetéssel lehet egyértelműsíteni, mit is várunk el a rendszertől.