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

Mennyi pénzbe kerül egy későn megtalált hiba?

Képzeljünk el egy egyetlen félreérthető mondatot egy több száz oldalas követelményspecifikációban. A mondat egy kerekítési szabályról szól, és kétféleképpen is értelmezhető. A fejlesztő az egyik értelmezés szerint kódolja le – teljesen logikusan, jóhiszeműen, a saját olvasata alapján. Ha ezt a mondatot valaki a specifikáció átolvasásakor megkérdőjelezi, a „javítás” költsége nagyjából tíz perc: egy tisztázó kérdés

A tesztelés nem költség, hanem bevételvédelem

Képzeljünk el egy hétfő reggeli vezetői értekezletet, ahol a pénzügyi igazgató (CFO) a negyedéves költségvetést vizsgálva megáll a „Minőségbiztosítás (QA) és Szoftvertesztelés” sornál. „Miért költünk ennyit arra, hogy hibákat keressünk a kódunkban? Nem lenne egyszerűbb, ha a fejlesztőink eleve jobban figyelnének, és hibátlan kódot adnának ki?” – hangzik el a klasszikus kérdés. Ez a felvetés

Amikor a tesztelés stratégiai előnnyé válik – egy piacvezető állásportál QA auditja

Egy piacvezető állásportál működése során a hirdetések feldolgozása nem csupán üzleti folyamat – ez a szolgáltatás alapköve. Ha a hirdetésfeldolgozási rendszerekben vagy a háttéralkalmazásokban hiba lép fel, az közvetlenül befolyásolja a felhasználói élményt és a vállalatok toborzási hatékonyságát. Ebben az esettanulmányban bemutatjuk, hogyan elemeztük egy állásportál tesztelési folyamatait, milyen jelenlegi kihívások fedezhetők fel a működésben,

Scroll to Top