Bevezetés
Minden szoftverfejlesztési projekt életében eljön az a pont, amikor a csapat vezetője, a projektmenedzser vagy a cégtulajdonos a homlokára csap: „Nekünk azonnal tesztelők kellenek!” A hibák szaporodnak, a fejlesztők túlterheltek, az ügyfél pedig egyre türelmetlenebbül dobol az asztalon. Ilyenkor tűnik logikus és gyors megoldásnak a külsős szakértő bevonása. Felhívunk egy partnert, kérünk két senior tesztelőt, és várjuk a csodát.
De vajon tényleg ilyen egyszerű a képlet?
A tapasztalatunk azt mutatja, hogy a külsős erőforrás bevonása kétféleképpen végződhet: vagy egy hatalmas lendületet adó sikertörténet lesz, vagy egy frusztrációval teli, drága kísérlet. Ahhoz, hogy az előbbi történjen, tisztán kell látnunk, mire való egy külsős tesztelő, és mire nem.
Ebben a cikkben rendet teszünk a fogalmak között, és megmutatjuk, hogyan lehet úgy bevonni külsős szakembereket, hogy az valóban értéket teremtsen az üzlet számára.
A nagy tévhit: „A tesztelő majd minőséget csinál”
Kezdjük egy fontos alapvetéssel, ami gyakran okoz félreértést a megrendelői oldalon. Fontos különbséget tenni a szoftvertesztelő és a minőségbiztosítás (Quality Assurance – QA) fogalma között.
A tesztelő feladata a vizsgálat. Ő az, aki „megrázza a pofonfát”, aki megpróbálja elrontani a rendszert, aki ellenőrzi, hogy a szoftver úgy működik-e, ahogy azt a specifikációban leírták. Ő a hibákat (bugokat) találja meg.
A minőségbiztosítás (QA) viszont egy sokkal tágabb fogalom: az egész folyamat minőségéről szól, aminek a tesztelés csak egy (bár kétségkívül fontos) része.
A tévhit ott kezdődik, amikor a döntéshozó azt várja, hogy a külsős tesztelő megérkezésével a „project minősége” egy csapásra javulni fog. Ez sajnos nem így működik. A tesztelő nem tud minőséget beépíteni a szoftverbe, ha az alapoktól rosszul lett megtervezve vagy megírva. Ő csak fényt derít a problémákra. Olyan ez, mint egy lázmérő: megmutatja, hogy baj van, de önmagában nem gyógyítja meg a beteget.
Ha külsős partnert vonunk be, ne csodafegyvert várjunk, aki megoldja a fejlesztési folyamataink hiányosságait. Olyan szakembert várjunk, aki tükröt tart, és segít láthatóvá tenni a kockázatokat, mielőtt azok az éles környezetben robbannának fel.
„Majd a tesztelő kitalálja” – avagy a mélyvíz esete
Gyakori jelenség, hogy a külsős kollégát a projekt legkritikusabb szakaszában, a tűzoltás közepette szerződtetik le. „Itt a hozzáférés, itt a szoftver, teszteld!” – hangzik a rövid utasítás. Aztán telnek a napok, és a várt eredmények elmaradnak. A tesztelő „triviális” hibákat jelent, vagy olyan dolgokat kifogásol, amik valójában üzleti döntések eredményei.
Miért történik ez?
Gondoljunk bele egy egyszerű példába. Képzeljük el, hogy egy kiváló vendégséfet hívunk az éttermünkbe, mert a konyhánk úszik a rendelésekkel. A séf megérkezik, de senki nem mondja meg neki, hol van a só, hol a serpenyő, mi az étlap koncepciója, és kik a törzsvendégek. Hiába Michelin-csillagos a tudása, az első órákban csak botladozni fog, és lehet, hogy sótlanul küldi ki a levest, mert nem találta a fűszereket.
Ugyanez igaz a szoftvertesztelésre is. A hatékony teszteléshez nem elég a technikai tudás. Érteni kell az üzleti logikát (Domain Knowledge). Ha a tesztelő nem érti, miért működik úgy a program, ahogy, és ki fogja használni, akkor nem tudja érdemben validálni a működést. Csak gombokat fog nyomkodni, de nem a valós felhasználói viselkedést szimulálja.
Mikor NEM segít a külsős tesztelő? (Intő jelek)
Van néhány olyan szituáció, amikor a külsős erőforrás bevonása szinte borítékolhatóan pénzkidobás lesz. Ha az alábbi „red flag”-eket (vészjelzéseket) tapasztalod a projektedben, először a házad táján kell rendet tenned, mielőtt segítséget hívsz.
Ha kaotikusak a belső folyamatok
Nincs specifikáció? Nincsenek leírt követelmények? „Majd szóban elmondjuk”? Ez a tesztelő rémálma. Ha nincs mihez viszonyítani a működést, a tesztelő csak vaktában tapogatózik. Ilyenkor nem tesztelőt kell hívni, hanem egy Business Analystet (üzleti elemzőt) vagy egy QA Lead-et, aki segít rendbe tenni a követelménykezelést.
Ha kizárólag tűzoltásra használjuk
A release előtt 3 nappal beeső tesztelő a leghálátlanabb szerep. Ilyenkor már nincs idő a hibák javítására. A tesztelő csak a „rossz hírt hozza”: közli, hogy a termék tele van hibával. A menedzsment ilyenkor gyakran a tesztelőre haragszik („miatta nem tudunk élesíteni”), pedig ő csak a hírvivő. A minőségellenőrzést a folyamat elején kell elkezdeni, nem a végén.
Ha nincs dedikált gazdája
A külsős szakembernek kérdései lesznek. Sok kérdése. „Ez a gomb miért piros?” „Mi történik, ha a felhasználó megszakítja a fizetést?” Ha nincs egy dedikált belső kapcsolattartó (legyen az fejlesztő, PO vagy PM), aki válaszol ezekre, akkor a tesztelő órákig vagy napokig ülhet egy blokkoló probléma felett. A drága óradíj pedig ketyeg a semmire.
Mikor ér aranyat a külsős erőforrás?
Természetesen nem véletlen, hogy a tesztelői outsourcing (kiszervezés) virágzó iparág. Vannak helyzetek, amikor ez a létező legjobb üzleti döntés. Nézzük meg, mikor térül meg sokszorosan a befektetés!
Speciális tudásigény esetén
Vannak olyan tesztelési típusok, amikre nem érdemes főállású embert tartani, mert ritkán van rájuk szükség, de akkor nagyon. Ilyen például:
- Terheléses tesztelés (Performance Testing): A Black Friday előtt meg akarjuk nézni, bírja-e a webshop a tízszeres forgalmat. Ehhez speciális eszközök és mély technikai tudás kell.
- Biztonsági tesztelés (Security Testing): Etikus hackerek bevonása, hogy keressenek réseket a pajzson. Ilyenkor a külsős szakértő olyat tud, amit a belső csapatunk nem, és pont annyi időre jön, amíg elvégzi a speciális feladatot.
Skálázódáskor (Scaling)
A cég növekszik, jön egy nagy projekt, egy új piacra lépés. Hirtelen megnövekedett a munkaigény, amit a belső 2 fős tesztelői csapat nem bír el. Felvenni új embert 3-4 hónap. Egy staffing partnertől kérni 3 tesztelőt: 2 hét. A rugalmasság itt versenyelőnyt jelent.
A „Vakfoltok” ellen
Ismerős az „üzemi vakság” fogalma? A belső fejlesztők és tesztelők, akik évek óta ugyanazt a rendszert nézik, hajlamosak átsiklani bizonyos hibák felett. „Ez mindig így működött, csak frissíteni kell kétszer.” Egy külsős szem friss perspektívát hoz. Ő úgy néz a szoftverre, mint egy új felhasználó. Olyan logikai bukfenceket és kényelmi (usability) problémákat is kiszúr, amikhez a belsősök már túlságosan hozzászoktak.
Módszertani megújuláshoz
Ha azt érezzük, hogy a belső folyamataink elavultak (pl. még mindig Excelben vezetjük a hibákat, nincs automatizálás), egy tapasztalt külsős szakértő bevonása katalizátor lehet. Ő nem csak tesztel, hanem (jó esetben) „best practice”-eket, iparági sztenderdeket hoz magával. Megmutatja, hogyan lehetne jobban csinálni, és betanítja a belső csapatot.
A siker kulcsa: A professzionális Onboarding
Ha elhatároztuk, hogy bevonunk külsősöket, egyetlen dolgon múlik a siker: az Onboardingon (Beillesztésen). És itt nem arra gondolunk, hogy kap-e belépőkártyát és laptopot (bár az is fontos).
A szakmai beillesztés a projekt sikerének záloga. Egy jó onboarding tesztelői szempontból a következőket tartalmazza:
- Kontextus: Nem csak a „mit”, hanem a „miért”-et is átadjuk. Mi a termék célja? Kik a felhasználók? Mi az üzleti modell?
- Hozzáférés: Már az első napon működő hozzáférések a dokumentációhoz (Jira, Confluence), a tesztkörnyezethez és a kommunikációs csatornákhoz (Slack, Teams).
- Támogatás: Kijelölünk egy „Buddy”-t (egy belső embert), akihez bármikor fordulhat „buta kérdésekkel” is.
Az az idő, amit az első 1-2 hétben a külsős kolléga betanítására szánunk, nem elvesztegetett idő. Ez befektetés. Egy jól onboardolt tesztelő a második héttől önállóan dolgozik, és tehermentesíti a csapatot. Egy magára hagyott tesztelő hónapokig csak kérdezni fog, és akadályozza a haladást.
Összegzés
A külsős tesztelő bevonása nem varázslat, hanem egy menedzsment eszköz. Erőforrás, amit – mint minden erőforrást – menedzselni kell. Nem helyettesíti a jó vezetést, a tiszta folyamatokat és a definiált követelményeket. Ugyanakkor, ha egy érett projektbe, felkészült csapat mellé érkezik egy profi külsős partner, az felerősíti a pozitív folyamatokat, és olyan stabilitást ad a fejlesztésnek, ami üzleti szinten is mérhető: kevesebb hiba élesben, elégedettebb ügyfelek, nyugodtabb alvás a menedzsmentnek.
Ha bizonytalan vagy benne, hogy a Te projekted érett-e már a külsős tesztelésre, vagy inkább még a belső QA folyamatok rendbetételére (tanácsadásra) lenne szükséged, érdemes szakértővel konzultálni. Egy jó partner nem csak „testeket” ad el, hanem segít felmérni a terepet, és a valós problémára ad megoldást – legyen az egy tesztelő, egy QA Lead, vagy csak egy őszinte tanács.
