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 valóságban időzített bombákon ülünk.
A dedikált tesztelő (vagy Quality Assurance mérnök) hiánya a projekt költségvetésében nem „megtakarított profit”, hanem elhalasztott kiadás, ami később kamatostul, gyakran a projektet veszélyeztető mértékben tér vissza.
Nézzük azt az 5 kritikus pontot, ahol a projekt vérezni kezd, ha nincs megfelelő tesztelői kapacitás.
1. A Rework (Bumeráng-effektus) drága örvénye
A szoftverfejlesztés egyik alaptörvénye: minél később találunk meg egy hibát, annál drágább kijavítani.
Tesztelő nélkül a folyamat jellemzően így néz ki:
- A fejlesztő lefejleszti a funkciót. Szerinte „kész”.
- Nincs validáció, a kód bekerül a közös ágba.
- Két héttel később, egy demón vagy élesítés előtt derül ki, hogy a funkció nem működik bizonyos peremfeltételekkel, vagy elrontott egy másik modult.
- A fejlesztőnek, aki már fejben egy teljesen más feladaton dolgozik, vissza kell térnie a két héttel ezelőtti kódhoz. Újra fel kell vennie a fonalat, ami hatalmas kontextusváltási (context switching) költséggel jár.
A QA szerepe, hogy ezt a kört rövidítse le percekre vagy órákra. Ha a hiba még a fejlesztés napján kiderül, a javítás töredékannyi időbe és pénzbe kerül. A tesztelő nélküli projektekben a fejlesztői kapacitás 30-40%-a is elmehet a „bumerángként” visszatérő hibák javítására – ez pedig a létező legdrágább hibajavítási mód.
2. Csapatfeszültség és motivációvesztés
A fejlesztők – tisztelet a kivételnek – nem szeretnek tesztelni. Ők alkotni szeretnek, problémákat megoldani, logikát építeni. A manuális tesztelés, a végeláthatatlan űrlapkitöltés vagy a különböző böngészőkben való kattintgatás számukra monoton és demotiváló munka.
Ha a tesztelést a fejlesztőkre kényszerítjük („cross-testing”), két dolog történik:
- Felületes lesz a tesztelés: Mivel „túl akarnak lenni rajta”, csak a „happy path”-t (a helyes működési utat) ellenőrzik, a hibák nagy része rejtve marad.
- Kirobban a „Blame Game”: Amikor beüt a hiba, elkezdődik a mutogatás. „Miért nem nézted meg?” „Mert siettem a saját feature-ömmel!” Dedikált felelős (QA) nélkül a minőségért mindenki felelős – ami a gyakorlatban azt jelenti, hogy senki.
Hosszú távon ez a senior fejlesztők elvesztéséhez vezethet, akik inkább keresnek egy olyan munkahelyet, ahol a szakmájukra koncentrálhatnak, és van professzionális QA csapat mögöttük.
3. Reputációs kockázat: Amikor az ügyfél a tesztelő
Ez a legrosszabb forgatókönyv, és sajnos a leggyakoribb a tesztelőhiányos projekteknél. Ha házon belül senki nem szűri a hibákat, akkor a végfelhasználók fogják megtalálni azokat.
Gondoljunk bele:
- Egy webshopnál, ha a kosárba tétel gomb nem működik mobilon, a vásárló nem fog hibajegyet írni. Egyszerűen átmegy a konkurenshez.
- Egy B2B szoftvernél az első éles hibák után a megrendelő bizalma meginog. „Ha már az alapok sem működnek, mi lesz később?”
A bizalom elvesztése sokkal drágább, mint bármilyen tesztelői bérköltség. A reputációt évekig tart felépíteni, de egyetlen rosszul sikerült, teszteletlen élesítéssel le lehet rombolni. Ez már nem IT technikai probléma, hanem közvetlen üzleti kár.
4. Lassuló Time-to-Market (Piacra lépés ideje)
Paradoxnak tűnhet: ha nem kell tesztelni, gyorsabban haladunk, nem? Nem.
Rövid távon talán gyorsabbnak tűnik a fejlesztés (nincsenek „idegesítő” hibajegyek, amik megakasztanák a folyamatot), de közép távon a projekt drasztikusan lelassul. Miért? Mert a csapat állandó tűzoltásban (firefighting) ég. Ahelyett, hogy az új funkciókat fejlesztenék a roadmap szerint, az előző sprintekből visszamaradt, élesben felbukkant hibákat („hotfixeket”) kell javítaniuk.
A tervezhetőség megszűnik. A projektvezető nem tudja megmondani, mikor lesz kész az új verzió, mert a csapat kapacitását felemésztik a váratlan hibák. A tesztelés hiánya nem gyorsítja, hanem kiszámíthatatlanná teszi a piacra lépést.
5. Dokumentáció hiánya és a „Tribal Knowledge” (Törzsi tudás) veszélye
Kevesen gondolnak rá, de a tesztelői munka egyik legértékesebb mellékterméke a dokumentáció. A megírt tesztesetek (Test Case-ek), a tesztelési forgatókönyvek és a bug reportok valójában a rendszer élő, naprakész leírásai.
QA nélkül gyakran elmarad a specifikáció aktualizálása. A rendszer működése csak a fejlesztők fejében létezik („Tribal Knowledge”). Mi történik, ha a projekt kulcsfejlesztője felmond vagy megbetegszik? Viszi magával a tudást. Senki nem tudja pontosan, hogyan kellene működnie egy bonyolult üzleti logikának, hiszen nincs róla se specifikáció, se teszteset, ami leírná az elvárt működést.
A tesztesetek hiánya óriási kitettséget (Vendor Lock-in vagy Person Lock-in) jelent a cégnek. Egy új fejlesztő betanítása hetek helyett hónapokig tarthat, mert nincs mihez nyúlnia.
Összegzés: A minőség ingyen van?
Philip Crosby, a minőségbiztosítás egyik úttörője mondta: „Quality creates money.” (A minőség pénzt termel.) De még pontosabb a másik idézete: „Quality is free. It’s not a gift, but it is free. What costs money are the unquality things — all the actions that involve not doing jobs right the first time.” (A minőség ingyen van. Nem ajándék, de ingyen van. Ami pénzbe kerül, az a minőség hiánya – mindazok a dolgok, amikor nem végezzük el a munkát jól már elsőre.)
A tesztelő alkalmazása nem luxus, amit csak a nagyvállalatok engedhetnek meg maguknak, hanem a fenntartható szoftverfejlesztés alapköve.
Van megoldás, ha nincs keret teljes állású kollégára: Nem feltétlenül kell azonnal senior QA mérnököt felvenni teljes állásba.
- Staffing / Outsourcing: Béreljen tesztelőt csak a projekt kritikus szakaszaiban.
- Részmunkaidő: Egy junior tesztelő vagy egyetemista is rengeteg terhet levehet a fejlesztők válláról.
- Automatizálás: Befektetés, ami később térül meg, de kiválthatja a manuális tesztelés egy részét.
Ne feledjük: A tesztelés hiánya mindig többe kerül a végén, mint a tesztelés ára. Csak a számlát nem a QA csapat küldi, hanem az elégedetlen ügyfelek és a frusztrált fejlesztők.
