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

A tesztpiramis: a stabil és kifizetődő tesztautomatizálás alapköve

Bevezető A szoftverfejlesztés világában az automatizálás gyakran úgy indul, mint egy lelkes fellángolás: „Minden manuális tesztet váltsunk ki automata scriptekkel!” A kezdeti eufória után azonban sok projektvezető és fejlesztő szembesül a kőkemény valósággal. A tesztek lassúak, gyakran ok nélkül elbuknak, a karbantartásuk pedig több időt emészt fel, mint amennyit maga a fejlesztés. Ilyenkor merül fel

Tesztautomatizálás: mikor érdemes belevágni, és mikor várjunk még?

Bevezető A szoftverfejlesztési projektek egyik legvitatottabb kérdése nem az, hogy kell-e automatizálni a tesztelést, hanem az, hogy mikor. „Már az első naptól írjunk automata teszteket, vagy ráérünk, ha már kész a funkciók nagy része?” – hangzik el a kérdés szinte minden projektindító megbeszélésen. A válasz azonban nem egy egyszerű dátum vagy verziószám. A tesztautomatizálás ugyanis

Tesztautomatizálás útmutató: mikor, hogyan és miért érdemes bevezetni?

Szoftvert fejleszteni ma már nem csak kódolást jelent. Egy termék sikere legalább annyira múlik azon, hogy a kiadás pillanatában stabilan, hibamentesen és megbízhatóan működjön, mint magán az ötleten. Ahogy az IT projektek egyre komplexebbé válnak, a hagyományos, tisztán manuális tesztelés egyre kevésbé tud lépést tartani a fejlesztés tempójával. Eljön a pont, amikor a tesztelés már

Scroll to Top