Bevezetés
A projekt késésben van. A határidő vészesen közeleg. A menedzsment ideges. Mi az első reflex? „Fel kell vennünk még embert! Tegnapra!”
Ismerős a helyzet? Valószínűleg mindenki találkozott már vele, aki dolgozott IT projektben. A pánikgomb megnyomása ilyenkor természetes reakció. Az extra erőforrás bevonása valóban életmentő lehet, de csak akkor, ha okosan csináljuk. A kapkodó, előkészítetlen bővítés ugyanis több kárt okozhat, mint hasznot.
A szoftvertesztelés területén ez hatványozottan igaz. Nem elég csak „testeket” (headcount) adni a projekthez; a megfelelő embereket, a megfelelő időben és módon kell integrálni. Ha ezt elvétjük, könnyen beleeshetünk olyan csapdákba, amelyekkel garantáltan elégetjük a büdzsét anélkül, hogy a szoftver minősége érdemben javulna.
Ebben a cikkben sorra vesszük az 5 leggyakoribb hibát a gyors tesztelői kapacitásbővítés (QA Staffing) során, és megnézzük, hogyan kerülhetjük el őket.
A „Mindenes” keresése (Wrong Profile)
A hiba: A pánikban lévő projektmenedzser megfogalmazza az igényt: „Kell egy tesztelő.” De milyen? A kiírásban gyakran összemosódnak a szerepek: legyen manuális tesztelő, de értsen az automatizáláshoz (Selenium, Cypress), tudjon performancia teszteket írni (JMeter), és lehetőleg security tesztelésben is legyen jártas. Ja, és holnap kezdjen.
A következmény: Két forgatókönyv lehetséges:
- A túlképzett szenvedő: Felveszünk egy drága automatizáló mérnököt (SDET), akit aztán hetekig manuális teszteléssel terhelünk, mert „most ez a legfontosabb”. Eredmény: unatkozni fog, demotiválttá válik, és hamar felmond.
- Az alulképzett küzdő: Felveszünk egy kiváló manuális tesztelőt, akitől elvárjuk, hogy automatizált keretrendszert építsen nulláról. Eredmény: nem tudja megcsinálni, frusztrált lesz, a kód minősége pedig csapnivaló.
Megoldás: Pontos profilalkotás (Job Profile Definition) Mielőtt keresni kezdünk, tisztázzuk: mi a valódi feladat a következő 3 hónapban? Ha manuális regressziós teszteket kell futtatni, keressünk egy precíz manuális tesztelőt. Ha API teszteket kell automatizálni, keressünk arra szakembert. Ne keressünk „svájci bicskát”, ha csak csavarhúzóra van szükségünk.
„Majd útközben megtanulja” (Lack of Onboarding)
A hiba: „Nincs időnk betanítani, azonnal teszteljen!” – hangzik el gyakran. A tesztelő megkapja a belépési adatokat, a laptopot, és rámutatnak a szoftverre: „Hajrá, találd meg a hibákat!”
A következmény: A tesztelő valóban elkezd dolgozni, de mivel nem ismeri az üzleti logikát (Business Logic) és a domaint:
- Olyan dolgokat jelent hibának, amik valójában helyes működések (Feature, not a bug) – ezzel a fejlesztők idejét rabolja.
- Napokig ül egy blokkoló problémán (pl. hiányzó jogosultság, speciális tesztadat), mert nem tudja, kihez forduljon.
- Nem a kritikus üzleti folyamatokat teszteli, hanem lényegtelen sarokpontokat.
Megoldás: Dedikált „Buddy” és dokumentált folyamatok Még a legnagyobb tűzoltás közben is megéri rászánni az első 2 napot a strukturált onboardingra. Jelöljünk ki mellé egy mentort (Buddy), akihez bármikor fordulhat. Adjuk át a legfontosabb dokumentációkat és az architektúra ábrát. A befektetett idő napokon belül megtérül a relevánsabb hibajegyekben.
Elvárások tisztázatlansága (Unclear Expectations)
A hiba: A feladatkiadás kimerül annyiban: „Teszteld le az egészet.” De mit jelent az „egész”? És mikorra? Mi a „Kész” (Definition of Done) a tesztelés szempontjából?
A következmény: A tesztelő, mivel nem kapott prioritásokat, a saját feje után megy. Lehet, hogy napokat tölt azzal, hogy a weboldal CSS hibáit és elcsúszott pixeleit dokumentálja, miközben a fizetési kapu (Payment Gateway) egyáltalán nem működik, vagy az API 500-as hibákat dobál. A projekt szempontjából a tesztelés „sikeres” (találtunk 50 hibát), de az üzleti kockázat nem csökkent.
Megoldás: Kockázat-alapú tesztelési stratégia (Risk-based Testing Strategy) A staffing fázisban tisztázni kell: mit kell és mit tilos tesztelni időhiányban. Priorizáljuk a teszteseteket:
- Blocker / Showstopper (kritikus üzleti funkciók)
- Major
- Minor A tesztelőnek tudnia kell, hogy ha a fizetés nem megy, akkor a gomb színével nem foglalkozunk.
Az eszközök hiánya
A hiba: Sikeresen felvettünk 3 új tesztelőt. Hétfőn reggel megérkeznek, lelkesek. De:
- Nincs tesztkörnyezet (Staging environment), vagy épp karbantartás alatt áll.
- Nincs tesztadat (pl. anonimizált ügyfélbázis).
- Nincs mobilkészülék, amin tesztelni kellene.
- Nincs licenc a szükséges szoftverekhez (pl. JIRA, TestRail, IDE).
A következmény: Fizetett üresjárat. A drága külsős vagy belsős erőforrás napokig (vagy hetekig!) malmozik, amíg az IT support vagy a DevOps csapat megteremti a feltételeket. Ez a legdrágább hiba mind közül.
Megoldás: „Pre-flight check” (Felszállás előtti ellenőrzés) Az érkezés előtt 1 héttel (de minimum 3 nappal) végig kell menni egy ellenőrzőlistán. Van gép? Van hozzáférés? Van környezet? Ha nincs, akkor inkább toljuk el a kezdést pár nappal – olcsóbb, mint fizetni a semmittevést.
Kommunikációs szigetek
A hiba: A külsős (staffingolt) tesztelőket „karanténban” tartjuk. Nem hívjuk meg őket a stand-upokra („ott úgyse róluk van szó”), nem beszélnek közvetlenül a fejlesztőkkel, csak Jira jegyeken keresztül kommunikálnak. Ők a „bedolgozók”.
A következmény: Információvesztés és lassú hibajavítás. Kialakul a „Ping-pongozás” a hibajegyekkel: a tesztelő leírja, a fejlesztő visszadobja („nem tudom reprodukálni”), a tesztelő újra leírja… és közben telnek a napok. A tesztelők nem érzik magukat a csapat részének, így a motivációjuk és a felelősségérzetük is alacsonyabb lesz.
Megoldás: Teljes integráció a csapatba (One Team szemlélet) A külsős tesztelő is a csapat része, még ha csak 3 hónapra is. Hívjuk meg a Daily Stand-up-ra, a Sprint Planning-re és a Retro-ra is. Bátorítsuk a közvetlen kommunikációt a fejlesztőkkel (pl. Slack-en, Teams-en). A legjobb hibajavítás az, amikor a tesztelő és a fejlesztő együtt, pár perc alatt, szóban tisztázza a problémát.
Összegzés
A kapacitásbővítés nem sprint, hanem egy jól megtervezett váltófutás. A gyors bővítés nem a kapkodást jelenti, hanem a felkészültséget. Ha elkerüljük a fenti 5 hibát – pontosan definiáljuk a profilt, felkészülünk az érkezésükre, tisztázzuk az elvárásokat és integráljuk őket a csapatba –, akkor a bővítéssel nemcsak a tűzoltás lehet sikeres, hanem a projekt hosszú távú minőségét is megalapozhatjuk.
Mottó a végére: „Lassan járj, tovább érsz” – azaz szánj időt az előkészítésre, és a végrehajtás villámgyors lesz.
