QA staffing: hogyan lehet gyorsan és biztonságosan kapacitást bővíteni?

Bevezetés

Előző cikkünkben (itt olvasható) arról írtunk, hogy mikor érdemes külsős tesztelőt bevonni, és mikor intő jel, ha csak tűzoltásra használnánk őket. Most, hogy már tudjuk a „mikor”-t, evezzünk gyakorlatiasabb vizekre, és nézzük meg a „hogyan”-t. Hogyan lehet úgy bővíteni a csapatot, hogy az ne a káoszt növelje, hanem a megoldást hozza el?

(Megjegyzés: A szakmában gyakran használják a „QA staffing” kifejezést a tesztelői bővítésre is, de mi tegyünk különbséget: itt elsősorban szoftvertesztelői kapacitásról beszélünk.)

„Tegnapra kell 3 tesztelő!”

Ismerős a helyzet? A projektmenedzser pánikban hívja a staffing partnert, mert a határidők vészesen közelednek, a fejlesztés csúszásban van, és a tesztelésre maradt idő drasztikusan lecsökkent. A válaszreakció reflexszerű: „Dobjunk rá még embert!”

Ilyenkor történik meg a klasszikus hiba: a kapkodó felvétel során a vezetők csak a létszám („headcount”) feltöltésére koncentrálnak. Megvan a 3 ember? Megvan. Akkor megvagyunk.

De vajon tényleg megvagyunk?

A tapasztalat azt mutatja, hogy a tesztelői (és QA) kapacitásbővítés nem egy bevásárlólista kipipálása. Ez egy folyamat. Ha kihagyjuk a lépéseit, több kárt okozunk, mint hasznot. A rosszul integrált új emberek nemhogy nem gyorsítják a haladást, de le is lassítják a meglévő csapatot a rengeteg kérdéssel és a félreértett feladatokkal.

A „Gyorsan” vs. „Biztonságosan” ellentmondása

Miért olyan veszélyes a kapkodás? Mert rossz embert (vagy rosszkor) felvenni drágább, mintha senkit nem vettünk volna fel.

  • Ha a tesztelő nem érti a feladatot, hibásan tesztel.
  • Ha hibásan tesztel, téves hibajegyeket (bug reportokat) gyárt.
  • A fejlesztők drága idejét rabolja azzal, hogy „nem reprodukálható” vagy „ez feature, nem bug” típusú jegyeket kell kivizsgálniuk.

A staffing (munkaerő-kölcsönzés) nagy ígérete a sebesség. Való igaz, külső partnertől bérelni embereket sokkal gyorsabbnak tűnik, mint hónapokig hirdetni és interjúztatni a belső HR folyamaton keresztül. Ez így is van. De létezik egy mítosz, a „Plug & Play” szakember mítosza.

Sokan azt hiszik, hogy a senior tesztelő olyan, mint egy pendrive: bedugjuk a gépbe, és működik. Sajnos (vagy szerencsére) a tesztelés nem ilyen. Nincs olyan szakember, aki az első napon 100%-os. Mindenkinek, még a legprofibbnak is meg kell értenie a domaint (az üzleti területet). Egy banki szoftvert máshogy kell tesztelni, mint egy webshopot vagy egy orvosi műszert.

A biztonságos bővítés keretrendszere: 3 lépés

Hogyan lehet feloldani az ellentmondást? Hogyan lehet gyorsan bővíteni úgy, hogy ne sérüljön a biztonság? Íme a 3 lépéses keretrendszer, amit mi használunk.

1. Előkészítés (A „Házi feladat”)

Mielőtt felemeljük a telefont, hogy „kell ember”, definiálnunk kell az igényt. Nem „egy tesztelő” kell. Hanem:

  • „Egy junior, aki manuálisan végigkattintja a webshopot, hogy a vásárlói útvonalak működnek-e.”
  • VAGY „Egy senior, aki automatizálja a backend API-t, hogy a regressziós tesztek gyorsabbak legyenek.” Ez óriási különbség!

És ennél a lépésnél a legfontosabb: Környezet előkészítése. Van tesztkörnyezet? Van VPN hozzáférés? Van licenc a szoftverekhez? Ha a kezdés napján kell ezeket az IT supporttal egyeztetni, az nemcsak pénzkidobás, de a tesztelő motivációját is rombolja.

2. A kiválasztás kontrollpontjai (Gatekeeping)

A staffing cégek sok CV-t küldhetnek. De a felelősség a miénk is, hogy kit engedünk be.

  • Ne dőljünk be a CV-nek: A „papíron jó” tesztelő a gyakorlatban lehet alkalmatlan. A technológiák felsorolása nem egyenlő a tudással.
  • A gondolkodásmód tesztelése: Egy rövid szakmai beszélgetés vagy próbafeladat során ne lexikális tudást kérjünk (azt ki lehet guglizni). Azt nézzük meg, hogyan gondolkodik. „Mit tennél, ha ezt a képernyőt látnád?” A tesztelői mindset a lényeg: a kritikus gondolkodás, a kíváncsiság.
  • Soft skillek: Egy agilis csapatban a kommunikáció kritikus. Ha valaki zseniálisan talál hibákat, de nem tudja érthetően elmagyarázni a fejlesztőnek (vagy arrogánsan teszi), az mérgezi a légkört.

3. Az integráció (Onboarding)

Itt vérzik el a legtöbb projekt. A „bedobjuk a mélyvízbe” módszer nem működik.

  • A Buddy-rendszer: Kell egy belső ember (mentor), akihez a külsős fordulhat. Nem kell, hogy egész nap fogja a kezét, de legyen dedikált ideje a kérdésekre.
  • Fokozatos terhelés: Ne a legbonyolultabb modullal kezdjünk. Első héten csak „smoke tesztek” (alapvető működés ellenőrzése), dokumentáció olvasása. Második héten jöhetnek a mélyebb funkciók.

Staffing mint szolgáltatás: Mikor éri meg?

Miért választják mégis sokan ezt a modellt a belső felvétel helyett?

  1. Rugalmasság: A projekt végén, vagy ha csökken a terhelés, a külsős csapatot könnyebb „leépíteni” (scaling down), mint a saját alkalmazottakat elküldeni.
  2. Adminisztrációs teher: Nem a te HR-edet és bérszámfejtésedet terheli a munkaügyi adminisztráció.
  3. Szakmai háttér: Egy jó staffing cég (aki ért a teszteléshez, nem csak általános fejvadász) szakmai felügyeletet (QA management) is biztosít a háttérben. Ha a tesztelő elakad, van kitől kérdeznie házon belül a saját cégénél is.

Esettanulmány: Amikor a kevesebb több

Egy tanulságos példa a közelmúltból: Egy ügyfelünk pánikban hívott minket, hogy 5 tesztelőre van szüksége azonnal, mert óriási a csúszás. A könnyű út az lett volna, ha küldünk 5 embert, és kiszámlázzuk az órákat. De nem ezt tettük.

Először 1 senior QA szakértőt küldtünk ki, hogy mérje fel a folyamatokat (audit). Kiderült, hogy a probléma gyökere nem a tesztelői kapacitás hiánya volt, hanem a hiányos és ellentmondásos specifikáció. A fejlesztők rosszul értették a feladatot, ezért rossz kódot írtak, amit a tesztelők (akik szintén nem értették a célt) hibásnak jelöltek.

A megoldás végül nem 5 tesztelő volt, hanem 2 tesztelő és 1 Business Analyst (üzleti elemző). Az elemző rendbe tette a követelményeket, a tesztelők pedig célzottan tudtak dolgozni. A projekt sikerült, az ügyfél pedig pénzt spórolt azzal, hogy nem a „vakon bővítés”, hanem a célzott beavatkozás útját választotta.

Összegzés

A kapacitásbővítés nem egy sprint, ahol csak a gyorsaság számít. Inkább egy váltófutás. A siker azon múlik, hogy milyen pontosan és biztonságosan tudjuk átadni a stafétabotot (a tudást és a feladatokat) az új csapattagoknak.

Ne várj a tűzoltásig! Ha látod a projekt roadmap-en (ütemterven) a terhelési csúcsot, kezdj el időben egyeztetni a staffing partnerrel. Mi segítünk megtervezni a bővítést, hogy az valóban gyors és biztonságos legyen.

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

Black Friday terheléses tesztelés: hogyan készüljünk fel a csúcsforgalomra?

Az év legforgalmasabb kereskedelmi napjain egy webshop látogatottsága a szokásos többszörösére ugorhat, ráadásul a forgalom nem egyenletesen oszlik el: egy hírlevél kiküldése vagy egy akció indulása percek alatt is okozhat hirtelen csúcsot. A Black Friday előtti terheléses tesztelés megmutatja, hogyan viselkedik a rendszer a várt csúcsforgalom alatt. Ez tehát nem pusztán technikai finomhangolás, hanem a

AI agentek tesztelése: hogyan ellenőrizzünk egy autonóm rendszert?

Az AI következő (jelenlegi) hulláma már nem csak válaszol, hanem cselekszik. Az AI agentek (önállóan, több lépésben feladatot végrehajtó mesterséges intelligencia rendszerek) jegyet nyitnak az ügyfélszolgálati rendszerben, e-mailt küldenek, adatot módosítanak, visszatérítést vagy megrendelést indítanak. Az AI agent tesztelés ezért egészen más kérdést tesz fel, mint egy chatbot ellenőrzése: nem azt, hogy jó-e a válasz,

Hogyan promptold az AI-t, ha tesztesetet akarsz generálni?

Az AI percek alatt legenerál ötven tesztesetet. A kérdés csak az, hogy azok használhatók-e, vagy a felét úgyis kidobod. A különbség szinte sosem a modellen múlik, hanem azon, hogyan kéred. Ha annyit írsz be, hogy „írj teszteket a bejelentkezéshez”, általános, sablonos listát kapsz, amit bármelyik tankönyvből kimásolhattál volna. Ha viszont tudod, hogyan építsd fel a

Scroll to Top

Elérhető tesztelőink

Nézze meg szakértőink profiljait, tapasztalatát és kompetenciáit, és találja meg a projektjéhez illő szakembert.

2006 — 2026

20 ÉVES A PASSED!

20 éve a szoftverminőség szolgálatában.

Két évtized szakértelem, fejlődés és elkötelezettség a szoftvertesztelés mellett.

PASSED

Töltse le tesztelőink szakmai profilját

Adja meg elérhetőségét egyszer és férjen hozzá valamennyi elérhető profilhoz.