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

Milyen lesz a QA engineer szerepe az AI korszakában?

„Elveszi a mesterséges intelligencia a munkámat?” – Ez a kérdés ma a szoftvertesztelői közösség legforróbb és leggyakoribb témája. Ahogy a generatív AI modellek és az intelligens tesztelési platformok egyre kifinomultabbá válnak, sok QA szakember aggódva figyeli a híreket. A kód- és tesztgenerátor asszisztensek, az öngyógyító lokátorok és az automatikus hibadetektálási ígéretek láttán könnyen alakulhat ki

Hogyan segíti az AI a tesztesetek generálását?

A modern szoftverfejlesztés egyik legnagyobb kihívása az idő. A sprintek rövidek, a funkciók száma folyamatosan nő, miközben a minőségi elvárások nem csökkennek. Ebben a feszített tempóban a teszt tervezése és a tesztesetek megírása gyakran a fejlesztési folyamat szűk keresztmetszetévé válik. Egy manuális tesztelő órákat tölthet azzal, hogy egy-egy komplex user story alapján pontról pontra kidolgozza

Hol bukik el leggyakrabban a szoftvertesztelés egy projektben? 4 szisztematikus hiba, amit nem szabad elkövetnetek

Minden projektmanager ismeri az érzést: a sprint végi demón minden zöld, az elfogadó tesztek átmentek, a csapat gratulál egymásnak – aztán az élesítés után két nappal becsörög az ügyfél, hogy egy kritikus üzleti folyamat nem működik. De hogyan juthatott keresztül egy ekkora hiba az egész tesztelési rendszeren? A válasz szinte sohasem az, hogy „a tesztelők

Scroll to Top