Külsős tesztelői csapat vs. belső felvétel – A valódi költségek és az időtényező

Bevezető

„Szervezzük ki, vagy vegyünk fel rá saját embert?”

Ez a kérdés – a klasszikus „Buy vs. Build” dilemma – valószínűleg minden növekvő technológiai cég vezetőségének asztalán landolt már. Amikor a szoftverfejlesztési projekt eléri azt a szintet, ahol a minőségbiztosítás (QA) hiánya már kritikus üzleti kockázatot jelent, dönteni kell.

A legtöbb esetben az első reakció a pénzügyi osztály részéről egy gyors matek: „Egy szenior külsős tesztelő óradíja 15-20 ezer forint. Ha felveszünk egy saját kollégát, az bérköltséggel együtt is kijön ennek a feléből. Tehát a belső felvétel az olcsóbb.”

Ez a számítás logikusnak tűnik, de a gyakorlatban gyakran téves. Olyan, mintha egy autó árát kizárólag a benzin ára alapján ítélnénk meg, figyelmen kívül hagyva a vételárat, a biztosítást, a szervizt és az értékcsökkenést.

Ebben a cikkben lebontjuk a szoftvertesztelés Teljes Birtoklási Költségét (Total Cost of Ownership – TCO), és megvizsgáljuk azt a tényezőt, ami az Excel táblázatokból gyakran kimarad: az időt.

1. Az „Idő” tényező: Mikorra kell a szakember?

Az üzleti életben az idő pénz. Szoftverfejlesztésben az idő: piacra lépés (Time-to-Market). Ha egy projekt azért csúszik hónapokat, mert nincs, aki letesztelje, az közvetlen bevételkiesést jelent.

A belső felvétel rögös útja

Ha ma úgy döntünk, hogy felveszünk egy tapasztalt manuális vagy automata tesztelőt, a következő idővonallal kell számolnunk:

  1. Hirdetés és szűrés (2-4 hét): A QA szakma hiányszakma. A jó szakemberek nem álláskeresők, őket vadászni kell.
  2. Interjúkörök (2-3 hét): HR kör, szakmai teszt, szakmai interjú, vezetői interjú. Ez nem csak idő, de a belső senior kollégák drága idejét is égeti.
  3. Felmondási idő (30-60 nap): Ha megtaláltuk a tökéletes jelöltet, ő valószínűleg dolgozik valahol. A senioroknál gyakori a 2 hónapos felmondási idő.
  4. Onboarding (1-3 hónap): Attól, hogy belépett az ajtón, még nem termel 100%-on. Meg kell ismernie a domaint, a rendszereket, a kollégákat.

Összegezve: A döntéstől a teljes értékű munkavégzésig minimum 3-6 hónap telik el. Van ennyi ideje a projektnek?

A külsős megoldás (Staffing/Outsourcing) sebessége

Ezzel szemben egy specializált tesztelői cég (vendor) üzleti modellje arra épül, hogy „készleten” tartja a szakértelmet.

  1. Kiválasztás (1-3 nap): A partnercég bemutat 2-3 profilozott jelöltet, akik azonnal elérhetők.
  2. Integráció (1-2 hét): Mivel ezek a szakemberek projektről projektre járnak, az alkalmazkodóképességük (adaptabilitásuk) kiemelkedő. Gyorsan felveszik a fonalat, mert ez a munkájuk lényege.

Mérleg: Ha a projektnek „tegnapra” kellett volna a minőségbiztosítás, a belső felvétel nem opció.

2. A „Költség” teljes képe: A jéghegy a víz alatt

Térjünk vissza a matekhoz. Miért tűnik drágábbnak a külsős, és miért lehet mégis olcsóbb a végelszámolásnál?

A jéghegy csúcsa: Az óradíj vs. Bér

Valóban, ha tisztán az óradíjat szorozzuk fel óraszámmal, a külsős tanácsadó díja magasabbnak tűnik a belső bérköltségnél. De a belső alkalmazottnál a „listaár” csak a kezdet.

A jéghegy alja: A rejtett költségek belső felvételnél

Amikor saját alkalmazottat veszünk fel, a cég magára vállalja az összes működési kockázatot és költséget (Overhead):

  1. Toborzási költség (Recruitment Cost): Fejvadász díj (az éves bruttó bér 15-20%-a), vagy a belső HR és a szakmai vezetők interjúztatással töltött munkaórái. Ez milliós tétel lehet egyetlen embernél.
  2. Infrastruktúra: Laptop, monitorok, drága szoftverlicencek (pl. IntelliJ, tesztmenedzsment eszközök), irodabérlet arányos része.
  3. Képzés és fejlődés: Konferenciák, tréningek, vizsgadíjak. Ha nem képezzük a tesztelőt, elavul a tudása és elmegy. Ha képezzük, az pénzbe kerül.
  4. Improduktivitás (Üresjárat): Ez a legfájóbb pont. A projektmunka hullámzó. Van, hogy hetekig éjjel-nappal tesztelni kell (release előtt), de van, hogy hetekig csak a specifikáció írása zajlik, és nincs mit tesztelni. A belső embert akkor is fizetni kell, ha épp „Malmozik”.
  5. Betegszabadság, szabadság: Évi 20-30 nap fizetett szabadság és a betegségek. A külsős partnernél csak a ledolgozott órákért fizetünk számlát. Ha a külsős nem dolgozik, nem kerül pénzbe.

A külsős költségszerkezete: „Pay-as-you-go”

A külsős modell (Time & Material) olyan, mint a felhőszolgáltatás: akkor és annyit fizetünk, amennyit használjuk.

  • Nincs toborzási díj.
  • Nincs fizetett üresjárat.
  • Az eszközöket és a képzést a szolgáltató cég állja.
  • A számla költségként elszámolható (OPEX), nem bérköltség.

3. A Kockázati mérleg: Rugalmasság vs. Stabilitás

A mai gazdasági környezetben a rugalmasság (flexibility) az egyik legértékesebb valuta.

A „Zsoldos” és a „Családtag”

Gyakori ellenérv a külsősökkel szemben: „Ő csak egy zsoldos, nem kötődik a céghez, nem ismeri a kultúrát.” Ez lehet igaz. A belső ember (ideális esetben) lojális, ismeri a cég minden rezdülését, és hosszú távon a csapat magját adja.

De mi van, ha nem válik be?

  • Belső munkavállaló: Elküldeni valakit pszichésen és jogilag is nehéz, költséges folyamat. Ha pedig ő mond fel a próbaidő után, kezdődik elölről a 3-4 hónapos kálvária, miközben a projekt áll.
  • Külsős partner: A szolgáltatói szerződésekben garancia van. Ha a delegált szakember nem válik be, a szolgáltató köteles cserélni – gyakran napokon belül. A kockázatot a szolgáltató viseli, nem az ügyfél.

Skálázhatóság (Scalability)

Mi történik, ha a projekt hirtelen leáll, vagy épp ellenkezőleg, háromszorosára nő a terhelés? Lépcsőzetesen, havi szinten bővíteni vagy szűkíteni egy belső csapatot szinte lehetetlen. Egy staffing partnerrel ez egy telefonhívás: „Jövő hónaptól nem 2, hanem 4 ember kell, de csak 3 hónapig.” Ez a fajta agilitás versenyelőnyt jelent.

4. Döntési Mátrix: Mikor melyiket válasszam?

Hogy segítsük a döntést, álljon itt egy egyszerű útmutató:

Válassz BELSŐ felvételt (In-house), ha:

  • Core Product: A cég fő termékének fejlesztéséről van szó, ami évekig fog tartani.
  • Domain Tudás: A teszteléshez nélkülözhetetlen a mély, speciális iparági tudás, amit nehéz átadni.
  • Kultúra: Fontos, hogy a kolléga részt vegyen minden céges eseményen, és a csapat hosszú távú építőköve legyen.
  • Van idő: Ráérsz 3-4 hónapot várni a kezdésre.
  • Van QA Lead: Van, aki szakmailag irányítsa, mentorálja a tesztelőt.

Válassz KÜLSŐS partnert (Staffing/Outsourcing), ha:

  • Projekt alapú munka: Határozott idejű (3-12 hónapos) fejlesztésről van szó.
  • Sürgős: Azonnal (1-2 héten belül) kell a kapacitás.
  • Hullámzó terhelés: Nem tudod garantálni a folyamatos, 100%-os kihasználtságot évekre előre.
  • Speciális tudás kell: Pl. teljesítménytesztelés (Performance Testing) vagy biztonsági tesztelés, amihez nem éri meg főállású embert tartani.
  • Nincs QA Management: Nincs kapacitásod foglalkozni a tesztelők szakmai irányításával – ezt a szolgáltatótól várod el.

Összegzés: A hibrid modell ereje

A valóság gyakran nem fekete-fehér. A legsikeresebb technológiai cégek gyakran a hibrid modellt alkalmazzák.

Felépítenek egy erős, de kisméretű belső „keménymagot” (QA Lead + kulcsemberek), akik őrzik a domain tudást és a folyamatokat. A projektcsúcsokat, a speciális igényeket és a skálázódást pedig külsős partnerek bevonásával kezelik. Így megmarad a stabilitás, de nem veszítik el a rugalmasságot sem.A tanácsunk: Ne dönts érzelmi alapon vagy pusztán az óradíjak összehasonlításával. Nézd a teljes képet (TCO), a projekt időzítését és a kockázatokat. Egy rosszkor hiányzó tesztelő sokkal többe kerülhet, mint a „legdrágább” külsős szakértő.

Megosztás

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

Kapcsolódó cikkek

Nincs elég tesztelő? Ez az 5 fájdalmas következmény a projektre

Bevezető „Spóroljunk a tesztelésen, majd a fejlesztők megnézik egymás kódját.” Hányszor hallottuk már ezt a mondatot projektindító megbeszéléseken? Logikusnak tűnhet: a fejlesztő ért a legjobban a kódhoz, miért fizetnénk külön embert arra, hogy „kattintgasson”? Ez a gondolkodásmód azonban olyan, mintha a könyvelőt kérnénk meg, hogy auditálja a saját mérlegét. Papíron minden rendben lesz, de a

Miért nem skálázódik QA nélkül egy IT projekt?

Bevezető A szoftverfejlesztés világában létezik egy visszatérő, fájdalmas forgatókönyv, amit szinte minden startup alapító és technológiai vezető átél legalább egyszer. Ez a történet mindig ugyanúgy kezdődik: eufóriával. A projekt elején minden olajozottan működik. A csapat kicsi, agilis, és mindenki mindent tud a rendszerről. A fejlesztők reggel megírják a kódot, délben tesztelik a saját gépükön, délután

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

Scroll to Top
Passed
Adatvédelmi áttekintés

Ez a weboldal sütiket használ, hogy a lehető legjobb felhasználói élményt nyújthassuk. A cookie-k információit tárolja a böngészőjében, és olyan funkciókat lát el, mint a felismerés, amikor visszatér a weboldalunkra, és segítjük a csapatunkat abban, hogy megértsék, hogy a weboldal mely részei érdekesek és hasznosak. Adatkezelési tájékoztató