10 munkahelyi tipp a hatékonyabb teszteléshez
Nemrégiben felkértek rá, hogy tartsak egy előadást a szoftvertesztelés alapjairól, ahol az ISTQB (International Software Testing Qualification Board) alap- és emelt szintű ismeretanyagából állítottam össze egyfajta „best of”-ot, valamint ki kellett térnem arra is, hogy általánosságban véve milyen módszerekkel lehet javítani egy cég tesztelési folyamatait.
Minden fejlesztő cégnél, ahol komolyan veszik a fejlesztést többé-kevésbé letesztelik a készülő terméket, a tapasztalatom szerint azonban óriási különbségek vannak abban, hogy mennyire veszik komolyan magát a tesztelést (mások az elvárt és alkalmazott módszerek, mivel sok helyen nincsenek is nagyon tisztában azzal, hogy egyáltalán miből lehetne építkezni – ennek megfelelően a tesztelői fizetések között is meglehetősen nagy a differencia).
Hogy egy cégen belül a tesztelési folyamatok jól működjenek, ahhoz az egyénnek és a cégvezetésnek egyaránt hozzá kell járulnia. Éppen ezért mindkét oldalról érdemes megvizsgálni, melyik fél mit tud hozzátenni ahhoz, hogy a tesztelés jobban működjön.
Mit tegyek, mint tesztelő?
1. Élvezd a munkád!
Hatalmas közhely, hogy igazán jót alkotni csak azon a területen lehet, amit szeretünk, és a cím is paradoxon, hiszen senkinek nem lehet megparancsolni, hogy szeresse azt, amit csinál. Nem hiszek azoknak az életmód-guruknak, akik azt mondják, hogy élvezd a munkád, mert ez általában nem így működik, és ha rövid időre mégis sikerülne fellelkesülnünk, az általában nem lesz tartós.
Ugyanakkor a szoftvertesztelői munka is olyan, mint a legtöbb munkakör, vagy elfoglaltság: ha érdekel bennünket, bőven ad rá lehetőséget, hogy izgalmassá és élvezetessé tegye azt az időt, amit eltöltünk vele. A tesztelés számos IT és egyéb területet érint, a fejlesztéstől kezdve az adatbázis kezelésen át a webes ergonómiáig, ráadásul ez egy kreativitást és logikus gondolkozást igénylő szakma, ami – ha jól csináljuk, és a munkaadó is kellően motivál bennünket – kifejezetten élvezetes is lehet. Ha kezdők vagyunk, lapozzunk csak fel néhány angol nyelvű elektronikus könyvet, és máris megbizonyosodhatunk róla, hogy tesztelőként milyen sok különböző irányban tudjuk szakmailag tovább képezni magunkat (usability szakértő, biztonságtechnikai szakember, tesztautomatizáló mérnök, stb.).
2. Tanulj tesztelni!
Aki az informatikából próbál megélni – rendszergazdaként, programozóként, web fejlesztőként, vagy bármilyen rokon szakma lelkes művelőjeként – nyilván rájött már, hogy az általános iskola informatika óráján megtanultakra nem fog tudni ráépíteni egy egész életet átívelő szakmai karriert (ez rám hatványozottan igaz, hiszen mi informatika órán általában a Prehistorikkal játszottunk). Tesztelni sem lehet egyszer megtanulni, és az sem fogja a munkaerőpiacon számított értékünket növelni, ha x éven keresztül nagyjából ugyanazt csináljuk, szakmai fejlődés nélkül.
Ha a munkahely nem is mindig kínálja tálcán az új ismereteket, senki sem fogja megtiltani nekünk, hogy szakmai lapokat olvassunk (aTesztelés a gyakorlatban állítólag egész jó), a témába vágó blogokra iratkozzunk fel, vagy hogy ingyenes és fizetős szakkönyvet szerezzünk be, ami bőségesen rendelkezésünkre áll, legalábbis angol nyelven. A folyamatos tanulás (de legalábbis érdeklődés) egyik legfontosabb alappillére lesz a tesztelői karrierünknek.
3. Bizonyítsd, hogy tudod!
A munkánkat hosszú távon egyéni és csapatban nyújtott teljesítményünk alapján fogják megítélni, de előfordulhatnak helyzetek, amikor azonnal bizonyítanunk kell: igen, mi képesek vagyunk az adott feladat elvégzésére. Álláshirdetésekben egyre gyakrabban követelik meg a szoftvertesztelő jelölttől, hogy legalább alap szintű ISTQB minősítéssel rendelkezzen (időnként a magasabb szintű bizonyítványt is kérik). Mivel ez nem egy olcsó vizsga – főleg tanfolyammal együtt –, és alap szintű vizsgán is a vizsgázók negyedét, emelt szinten nagyjából felét kiszórják, egy meglévő ISTQB minősítés elég komoly garancia arra, hogy a birtokosa legalább az elméleti háttér alapjaival tisztában van.
Persze ha nem szándékozunk munkahelyet váltani, akkor is érdemes megkérni a munkáltatót, hogy támogassa az ez irányú továbbtanulási törekvéseinket, hiszen az jó alapot szolgáltathat a későbbiekben a tesztelés hatékonyságának növelésére a cégen belül.
4. Ne csak tesztelni tanulj!
Szoftvert tesztelni kicsit olyan, mint zongorán játszani: mindenki képes rá, de hozzáértés nélkül pocsék lesz az eredmény. Jó hír azonban, hogy zongorázni megtanulni sokkal nehezebb, a teszteléshez ugyanis semmilyen velünk született különleges képességre nincs szükség (például zenei érzék), csupán szorgalom kell hozzá, ami elhatározás kérdése. Pontosabban fogalmazva: el kell határoznunk, hogy jobban meg akarjuk ismerni azt a rendszert, amivel tesztelőként dolgozunk.
Cégenként, sőt, projektenként is változó, hogy pontosan mihez is kell értenünk, de általánosságban elmondható, hogy a HTML jelölőnyelv magabiztos használata elengedhetetlen, ahogy a hozzá kapcsolódó „rokonterületek” – CSS, JavaScript, XML – alapos ismerete is az. Emellett pedig legalább nagy vonalakban érdemes valamilyen programozási nyelvvel is megismerkedni, hiszen így egyrészt mi magunk is bele fogunk tudunk nézni a kódba (code review), másrészt ez után már a tesztautomatizálással is elkezdhetünk foglalkozni. És ahogy egyre több és több ismeret birtokába kerülünk, úgy leszünk egyre megbecsültebb szakemberek a saját szakmánkon belül.
5. Keress közösséget!
Valamelyik nap elfogott a nosztalgiázhatnék, és előkerestem néhány, a ’90-es években készült lemezújságot, amelyek közül néhányban én is publikáltam (a lemezújság, más néven diskmag olyan DOS alatt futó, általában 1 floppy-s „magazin” volt – több tucat létezett belőle –, amibe fiatal geek-ek irkáltak a legkülönbözőbb témákban). Imádtam azokat az időket!
Ma, amikor már egy háztartásban három különböző internet előfizetéssel lehet éjjel-nappal szörfözni a világhálón (nem kell megvárni, míg a postás meghozza a floppy-t ), nem okoz különösebb nehézséget csatlakozni teszteléssel foglalkozó Facebook és LinkedIn csoportokhoz, feliratkozni hasonszőrű hírlevelekre és fórumokra. Sőt, kipróbálhatjuk magunkat crowd testing-gel (tömeges teszteléssel) foglalkozó weboldalakon is, ahol regisztráció után mi is jelentkezhetünk konkrét projekt tesztelésére, ebben az esetben pedig már nem csupán tapasztalattal leszünk gazdagabbak, de pénzt is kapunk a munkánkért.
Mit tegyek, mint vezető?
1. Erősítsd a kommunikációt!
A nem megfelelő kommunikáció (vagy a kommunikáció hiánya) minden közösségben problémákat okoz, és ez természetesen a munkahelyen is jelentősen meg tudja nehezíteni a munkavégzést, ami felesleges idegeskedést és elvesztegetett órákat jelent. Tesztelő-fejlesztő kontextusban gyakori, hogy a fejlesztő nem tekinti feladatának, hogy a tesztelési munkát segítendő megfelelő információkkal lássa el a tesztelő kollégát, akinek ilyenkor vagy a kelleténél többször kell a fejlesztő „nyakára járnia”, vagy többet kell improvizálnia, ami általában együtt jár azzal, hogy hibák kerülnek be a tesztdokumentumokba – ezek mind feleslegesen égetnek el projektre szánt (és kifizetett) értékes órákat.
Ezért minden elkészült (és tesztelendő) dokumentációt – rendszerterv, high level specifikáció, stb. – érdemes azonnal átbeszélnie a dokumentáció készítőjének (fejlesztő) és a tesztelőnek. Így a dokumentáció automatikusan felülvizsgálásra kerül (review) mindjárt két ember által, a tesztelő pedig birtokába kerül azoknak az ismereteknek, amelyekkel gyorsabban és hatékonyabban tudja felépíteni a tesztdokumentumokat (teszt terv, teszt forgatókönyv, tesztjegyzőkönyv, stb.).
A megbeszéléseknek persze nem szabad csupán az előkészítő és tesztelési fázisra korlátozódnia, érdemes az egyes lezárt projektek végén átbeszélni a munka során összegyűlt tapasztalatokat. Ennek segítségével jobban átlátjuk majd a következő projektnél, hogy mit kell másképp csinálni, és hol nem szabad változtatni a korábban jól bevált módszeren.
2. Automatizálj okosan!
A tesztautomatizálásra sok helyen egyfajta misztikus varázslatként tekintenek, amihez vagy nem nyúlnak hozzá, mert tartanak tőle („engem gyíkká változtatott… de már elmúlt”), vagy a másik végletként úgy tekintenek rá, mint a hétköznap délben reklámozott tévés termékre, ami minden problémára egyformán gyógyír. Tény, hogy a teszt-automatizálásba nem lehet ész nélkül belevágni, hiszen a nem megfelelően átgondolt tesztelési stratégia elég komoly kockázati tényezőt jelent, ami képes végeláthatatlan munkaórát elégetni – érdemi eredmény nélkül.
Azonban ha a tervezési fázis gondos szakértelemmel lett kivitelezve, és a kollégáknak is biztosítottuk a betanulásra és fejlesztésre szánt elégséges időt, továbbá a teszteszközöket és a tesztelendő funkciókat (dokumentumokat) is helyesen választottuk meg, az automatizált szkriptek megírásánál pedig szempont volt a karbantarthatóság, akkor hosszabb távon garantáltan és jelentősen gyorsíthatóak lesznek a tesztfolyamatok, ami kifizetődővé teszi az ez irányú pénz- és időráfordítást.
3. Ne csak formális legyen a tesztelés!
A szoftvertesztelés általánosságban véve egy rendkívül pontosan dokumentált folyamat – annak is kell lennie, különben egy megtalált hiba nehezen lesz reprodukálható. Ezért szokták megkövetelni, hogy az egyes tesztlépéseket is tartalmazó tesztesetek röviden, ugyanakkor közérthetően fogalmazzanak, ami az egyes hibák kapcsán felvett hibajegyeknél is ugyanúgy kritérium (utóbbinál számos egyéb paramétert is meg kell adnunk, mint tesztelés ideje, futtatás környezete, súlyosság, stb.).
A tesztelendő termék forgatókönyvvel (előre megírt tesztlépésekkel) történő, folyamatosan ismétlődő tesztelése szükséges lehet, de semmiképp sem elégséges, hiszen egy idő után csak ugyanazokat a hibákat fogjuk megtalálni – feltéve, hogy a fejlesztő nem javítja ki őket –, a tesztdokumentum ugyanis csak a hibák egy bizonyos százalékát képes felfedni.
A rejtett hibák megtalálásához szükség van a tesztelő intuíciójára és kreativitására is, ezért a hagyományos tesztelés ki kell egészíteni a kevésbé formális tapasztalat alapú teszteléssel (experience-based testing). Ennek egyik formája lehet a felderítő teszt (exploratory testing), ahol jellemzően a tesztelő az általa is kevésbé ismert funkciókat próbálja megvizsgálni – ez a módszer tanuláshoz is kiváló, ha például egy kevésbé (vagy egyáltalán nem) dokumentált alkalmazást kell feltérképezni.
Másik technika a hibasejtéses tesztelés (error guessing), amikor korábbi tapasztalatok, és/vagy meglévő ismeretek alapján nagyjából sejtjük, hogy nagy valószínűség szerint hol fogunk hibát találni, és kifejezetten arra a területre fókuszálunk.
4. Párban szép az élet!
Nagyobb projekteknél szükséges, de kisebbeknél is megfontolandó legalább két tesztelő bevonása a tesztelési feladatokba (amennyiben nincs külön tesztmenedzser a cégnél, az egyik tesztelő kollégát kell kijelölni tesztfelelősnek). Ilyenkor az ugyanazon projekteken egyszerre dolgozó kollégák nem csak motiválják egymást, de felülvizsgálják (review) és ki is javítják a közös tesztdokumentumban keletkezett anomáliákat, „elakadás” esetén pedig könnyebben fognak megoldást találni, így rövidebb ideig fog egy helyben állni a projekt. Váratlan betegszabadság esetén nem kell szüneteltetni a projektet és a betanítással sem kell idegesen kapkodni, hiszen mindig lesz, aki képben lesz az adott teendőkkel (feltéve, hogy nem egyszerre betegedik meg az egész cég).
Ráadásul ha nagyobb tesztelői csapat van a cégnél, és tisztában vagyunk az egyes kollégák kompetenciájával/szakterületével (jó csapatjátékos, szakértője az adott területnek, tud automatizáló szkripteket írni, monotonitástűrő, stb.), a párokat/csapatokat is hatékonyabban ki lehet választani.
5. Segítsd a tanulást!
Középiskolás voltam, amikor a nyári gyakorlatomat egy számítógépes boltban töltöttem, szervizesként. Amikor a főnököm rajtakapott, hogy az általa kölcsön adott száraz szakkönyv tanulmányozása helyett a Golden Axe törpéjével csapkodom a játék negatív karaktereit azt mondta, hogy aki nem akar tanulni, az ne akarjon informatikával foglalkozni, inkább menjen el hentesnek, mondván a disznóvágás terén nem jelentkeznek hetente újabb trendek. Ekkor ismét kezembe vettem a könyvet és a nap hátralévő részében azt olvasgattam (majd otthon végigvittem a nap közben megkezdett játékot, emlékeim szerint).
Talán az informatikusi pályán a legfontosabb, hogy folyamatos képzéssel naprakészen tartsuk a tudásunkat, ha nem szeretnénk nagyon lemaradni – aki pedig céget vagy csapatot igazgat, azzal teszi a legjobbat, ha támogatja a kollégák ez irányú törekvéseit. Szervezett tanfolyamok és házon belül megtartott oktatások segíthetik a kollégákat új teszteszközök és módszerek megismerésében, ami egyszerre növeli a tesztelői szakértelmet, erősíti a cég tesztelői kompetenciáját, és teszi hatékonyabbá a mindennapi munka során alkalmazott tesztelést. Ez egy olyan befektetés, aminek végül mindenki a nyertese lesz.
Szerző: Dienes Zsolt
A szerző
-
Informatikusi pályáját ECDL modulok oktatásával kezdte, a webes alkalmazásfejlesztés különböző területeivel 2006 óta áll szorosabb kapcsolatban. Korábban grafikai tervezéssel, front-end fejlesztéssel, az utóbbi pár évben teszteléssel foglalkozik hivatásszerűen. Jelenleg tesztelési szakértőként dolgozik egy alkalmazásfejlesztő cégnél, és Magyarország egyik vezető mobilszolgáltatójánál. Szabadidejét csodálatos feleségével, imádnivaló kislányával, valamint tekintélyes Sega Mega Drive játékgyűjteményével igyekszik eltölteni.
Kapcsolat: www.szoftverteszter.hu