Bevallok valamit, ami nem hangzik jól egy tesztelési szolgáltatást nyújtó cégtől:
Nem minden cégnek kell kiszervezni a szoftvertesztelést.
Vannak helyzetek, ahol a belső QA csapat a legjobb megoldás.Vannak helyzetek, ahol a vegyes modell működik. És vannak helyzetek - ezekről szól ez a cikk - ahol a kiszervezés nem csak olcsóbb, hanem egyszerűen jobb minőségű eredményt ad.
A különbséget nem az árazás dönti el. A döntési keretrendszer ennél érdekesebb.
Először a mítoszok
"A kiszervezett QA olcsóbb."
Néha igen. Néha nem. Több éven keresztül futó projekteknél a megrendelő többszörös árat fizet a tanácsadóknak, mint amennyibe a belső csapat kerülne. Ha hosszú távú, állandó tesztelési kapacitásra van szükség - a belső csapat valóban olcsóbb lehet.
"A kiszervezett QA rugalmasabb."
Ez igaz - de csak akkor értékes, ha a tesztelési igény valóban változó. Stabil terhelés esetén a rugalmasság felárat fizetsz valamiért, amit nem használsz.
"A kiszervezett QA kevésbé megbízható."
Ez a leggyakoribb kifogás - és a legkevésbé helytálló, ha a partner kiválasztása megfelelő volt. Érdemes megbízható, a piacon jó hírnévvel, stabil és nagy operációval bíró partnerekkel szerződést kötni. A minőség nem a foglalkoztatási formán múlik - hanem a szakértelmen és a domain ismereten.
Most, hogy a mítoszokat félretettük - nézzük meg mikor érdemes tényleg kiszervezni.
1. helyzet: Csúcsterhelés, amit nem érdemes állandó kapacitásra méretezni
Van egy szoftver bevezetési projekt. 3 hónap alatt le kell tesztelni az egész rendszert - funkcionális tesztelés, integrációs tesztelés,UAT koordináció. Aztán a projekt véget ér és a tesztelési igény visszaesik a töredékére.
Erre nem érdemes 3 senior QA-t felvenni. A toborzás 2-3hónap, az onboarding 1 hónap - és mire produktívak lennének, a projekt csúcsa elmúlt.
Tapasztaltuk ezt közelről. Egy pénzügyi nagyvállalatnál szoftverbevezetés előtt hirtelen megnőtt a tesztelési kapacitásigény. 3 senior QA szakértőt állítottunk munkába 10 napon belül - a projekt tesztelési fázisa határidőre lezárult, a kritikus hibák az éles bevezetés előtt kerültek felszínre. Utána a kapacitás skálázódott vissza. Ezt belső csapattal nem lehetett volna megoldani.
Mikor alkalmazható: egyszeri vagy időszakos projekt, ahol a csúcs igény nem indokol állandó belső kapacitást.
2. helyzet: Hiányzó domain tudás - és nincs idő betanítani
Ez az eset pénzügyi szektorbeli projekteknél különösen kritikus.
Egy biztosítási termék tesztelése nem ugyanolyan, mint egyáltalános webapplikáció tesztelése. A kárbejelentési folyamat kivételes esetei, a biztosítási díjkalkuláció logikája, a lízingszerződés életciklusa - ezeket nem lehet rövid briefingben átadni. Ha a tesztelő nem ismeri az üzleti logikát, kritikus hibák maradnak felszín alatt.
Egy biztosítói mobilalkalmazás tesztelésénél láttuk a különbséget. A belső fejlesztői tesztek zöldek voltak - a külső QA az első napon megtalálta, hogy egy bejövő hívás megszakítja a kárbejelentési folyamatot és elveszíti az addig beírt adatokat. A belső tesztelők ezt nem tesztelték, mert nem gondoltak rá - a külső QA gondolt rá, mert tudta hogyan használják a valódi felhasználók.
Mikor alkalmazható: speciális domain tudást igénylőprojektek, ahol a betanítás ideje nem rendelkezésre álló.
3. helyzet: Független szemre van szükség - nem belső ellenőrzésre
Van egy helyzet, amit ritkán mondanak ki hangosan: a belső fejlesztőcsapat tesztelői idővel "elvakul". Ismerik a rendszert,t udják hogyan készült, és öntudatlanul elkerülik azokat az utakat, ahol a rendszer hibázik.
Ez nem hanyagság - ez a confirmation bias természetes működése. Az ember azt teszteli, amit keresni tud, nem azt amit nem tud keresni.
Külső fejlesztőkkel dolgozó ügyfeleknél ez fokozottan igaz.Ha az IT partner fejleszti és teszteli is a rendszert - ki ellenőrzi azellenőrt? Nincs érdekeltség a hibák megtalálásában, ha a hibák a saját munkát minősítik.
Egy pénzügyi nagyvállalatnál pontosan ez volt a helyzet. Az IT partner fejlesztett és tesztelt - az éles bevezetés után derültek ki azok ahibák, amelyeket egy független QA megtalált volna. A kiszervezett független tesztelés nem a fejlesztő ellen szól - hanem az ügyfél érdekét védi.
Mikor alkalmazható: külső fejlesztői partnerrel dolgozó projektek, ahol a tesztelés függetlensége kritikus.
4. helyzet: A tesztelési kompetencia nem core tevékenység- de a minőség kritikus
Ez a leggyakoribb és legkevésbé bevallott helyzet.
Sok pénzügyi szektorbeli nagyvállalatnál a szoftverfejlesztésés tesztelés nem core tevékenység - de az általuk üzemeltetett rendszerek minősége kritikus. Egy biztosítói kárbejelentő rendszer hibája nem csak IT probléma - ügyfélelégedettség-romlás, compliance kockázat, reputációs kár egyszerre.
Ezeknek a szervezeteknek nem éri meg felépíteni és fenntartani egy teljes körű belső QA kompetenciát - de a minőség biztosítása nem opcionális. A kiszervezés itt nem költségcsökkentés - hanem stratégiai döntés: a minőség felelősségét egy specializált partnerre bízzák, aki ezt core tevékenységként végzi.
Mikor alkalmazható: ahol a szoftverminőség üzletileg kritikus, de a QA kompetencia felépítése és fenntartása nem stratégiai prioritás.
Mikor NEM érdemes kiszervezni
Az objektivitás kedvéért - négy helyzet, ahol a belső csapat jobb:
Folyamatos, stabil tesztelési igény - ha minden sprintben ugyanannyi QA kapacitás kell, a belső csapat hosszú távon olcsóbb, és jobban integrálódik.
Mélyen beágyazott rendszer tudás szükséges - ha arendszer olyan komplex és egyedi, hogy az onboarding hónapokba telik, a belső szakértő értékesebb.
Agilis csapat, nagyon szoros integráció - ha a QA a fejlesztési csapat napi szintű tagja és a sprint ceremóniák résztvevője, a belső integráció nehezebben pótolható.
Saját QA kompetencia stratégiai célként - ha a szervezet tudatosan épít belső tesztelési tudást, a kiszervezés ezt assíthatja.
A döntési keretrendszer
Négy kérdés, amelyre igenlő válasz esetén érdemes kiszervezést fontolni:
Az első: változó-e a tesztelési kapacitásigény? Ha van csúcs és völgy - a kiszervezés rugalmassága értékes.
A második: hiányzik-e a domain tudás belülről? Pénzügyi szektorbeli projekteknél ez különösen kritikus kérdés.
A harmadik: szükséges-e a függetlenség? Ha a fejlesztő és a tesztelő ugyanaz a szervezet, a függetlenség kérdéses.
A negyedik: core tevékenység-e a QA? Ha nem - a specializált partner valószínűleg jobb minőséget ad ugyanannyiért.
Amit a FrontX-nél máshogy csinálunk
A FrontX tesztelési szolgáltatása egy dologban különbözik a piaci átlagtól: domain tudást hozunk, nem csak tesztelési kapacitást.
A QA szakértőink ismerik a biztosítói, banki és lízing folyamatok logikáját. Salesforce bevezetéstől mobilalkalmazásig dolgoztunk pénzügyi szektorbeli tesztelési projekteken. Ez azt jelenti, hogy az onboarding rövid, a hibák relevánsak - és nem csak azt ellenőrizzük, hogy a gomb megnyomható, hanem azt is, hogy a mögötte lévő üzleti folyamat helyesen fut le.
Ha szoftver bevezetési projekted van ahol a tesztelési kapacitás vagy a domain tudás kérdéses - szívesen konzultálunk: frontx.hu/kapcsolat
Gyakran ismételt kérdések
Mikor érdemes kiszervezni a szoftver tesztelést? Négy fő helyzetben érdemes kiszervezést fontolni: változó tesztelési kapacitásigény esetén (projekt csúcsterhelés), ha hiányzik a belső domain tudás, ha független tesztelésre van szükség külső fejlesztői partnertől, vagy ha a QA nem , de a minőség kritikus. Stabil, állandó tesztelési igény esetén a belső csapat hosszú távon olcsóbb, és jobban integrálódik.
Mi a különbség a kiszervezett és a belső QA csapat között? A belső QA csapat mélyebben integrálódik a fejlesztési folyamatba, és hosszú távon olcsóbb lehet stabil igény esetén. A kiszervezett QA rugalmasabb kapacitást biztosít, friss szemmel közelít a rendszerhez, és - ha apartner specializált - domain tudást hoz, amit belülről nehéz felépíteni. A legjobb döntés az aktuális igénytől függ.
Mennyibe kerül a szoftvertesztelés kiszervezése? A szoftver tesztelés kiszervezésének költsége T&M alapon a bevont QA szakértők tapasztalatától és a projekt komplexitásától függ. A kiszervezés valódi megtakarítása a rugalmasságban és az onboarding idő megtakarításában rejlik, nem feltétlenül az óradíjban.
Hogyan biztosítható a minőség kiszervezett tesztelésnél?A minőség három dolgon múlik: a partner domain tudásán, a tesztelő tapasztalatán és a folyamat strukturáltságán. Konkrétan: előre egyeztetett SLAparaméterek és minőségi KPI-ok, rendszeres státuszjelentések, és olyan partner kiválasztása, aki ismeri az üzleti szektort - nem csak a technológiát.
Mi a shift-left tesztelés és miért fontos kiszervezett modellben? A shift-left tesztelés azt jelenti, hogy a QA nem a fejlesztési fázis végén lép be, hanem a projekt elejétől jelen van - specifikáció review-tól a sprint közbeni tesztelésig. Kiszervezett modellben ez különösen fontos: a külső QA partnernek korán be kell kapcsolódni, hogy a domain tudás és a rendszer ismeret időben felépüljön.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és datawarehouse vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. LinkedIn | FrontX blog
