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őlszó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-3 hó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ás igé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. (Persze a szakértő cégeknél is kérdés, hogy éppen van-e 3 tesztelő szabadon...de nagyobb valószínűséggel, mint házon belül..)
Mikor alkalmazható: egyszeri vagy időszakos projekt, ahol a csúcsigény nem indokol állandó belső kapacitást, vagy esetleg még nem dőlt el, hogy szeretnénke belső tesztelőt alkalmazni.
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, KGFB termék díjstruktúrája- ezeket nem lehet rövid briefingben átadni. Ha a tesztelő nem ismeri az üzleti logikát, kritikus hibák maradnak felszín alatt, felszínes lesz a tesztelés. (PErsze lehet azt mondani, hogy legyen részletes a teszt terv illetve a specifikáció, de a gyakrolat azt mutatja, hogy a specifikus tudást nehéz pótolni....)
Egy biztosítói mobil alkalmazás tesztelésénél láttuk a különbséget. A belső fejlesztői tesztek felületesek 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 avalódi felhasználók.
Mikor alkalmazható: speciális domain tudást igénylő projektek, ahol a betanításhoz szükséges idő nem áll rendelkezésre. (A domain lehet a tesztelői szaktudás, lehet az üzleti domain tudás is.)
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, tudják hogyan készült, és öntudatlanul elkerülik azokat az utakat, ahol a rendszer hibázik. (Saját tapasztalatom, amikor még üzleti elemzőként dolgoztam, fejlesztettünk egy telefonos IVR rendszert, én több körben, hosszasan teszteltem, minden szuperül működött....Majd átadtuk egy tapasztalt tesztelő kolléganőnknek, aki azonnal "ész nélkül" elkezdte összevissza nyomkodni a telefon gombjait, amire azonnal lefagyott a rendszer...Hát én ezt nem próbáltam, csak a specifikáció szerint mentem végig a menükön....:-) )
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 az ellenő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 a hibá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. (Persze a kérdés megközelítés kérdése is. Ha a megrendelő szeretné egy kézben a felleőséget, akkor ez nem megoldás...de véleményünk szerint sokszor jó szétválasztani a szerepköröket íéy módon is.)
Mikor alkalmazható: külső fejlesztői partnerrel dolgozó projektek, ahol a tesztelés függetlensége kritikus. (Nagy komplexitás vagy szeretnénk elkerülni a beszállítói "lock-ot" stb.
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 rendszerekminő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. (Esetleg még nincs ilyen komptenetcia, amit nem célszerű és reális egy nagyon kritikus projketnél kiépíteni.)
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 a rendszer olyan komplex és egyedi, hogy az onboarding hónapokba telik, a belső szakértő értékesebb. (Esetleg olyan mértékben üzleti titok a rendszerek tartalma, hogy nem lehet kiszervezni.
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ó. (VAgy nem szeretnénk a felelőségeket szétválasztani.
Saját QA kompetencia stratégiai célként - ha a szervezet tudatosan épít belső tesztelési tudást, a kiszervezés ezt lassíthatja.
A döntési kritériumok, 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 hosszab, rövidebb alacsonyabb terhelés- 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 kiszervezése 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ízinges folyamatok logikáját. Salesforce bevezetéstől mobil alkalmazásig dolgoztunk pénzügyi szektoros tesztelési projekteken. Ez azt jelenti, hogy az onboardin grö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 szoftverbevezeté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 szoftvertesztelé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 core tevékenység, 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 csapatkö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 a partner 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? Aszoftvertesztelé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. Egyébiránt a Bluebird Salary Guide alapján a tesztelők fizetése bruttó 600.000 Ft-tól indul, és a speciális tapasztalattal rendelkező, senior szakemberek fizetése vetekszik a fejlesztői bérekkel.
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 SLA paraméterek és minőségi KPI-ok, rendszeres státusz jelenté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ésif á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 ésa 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
