Tesztautomatizálás – ISTQB a gyakorlatban

Az informatika világában a különböző minősítések fontos szerepet játszanak. Egyre kevésbé csak a klasszikus szakirányú végzettségek, sokkal inkább az olyan akkreditált szakirányú vizsgák, amelyek az adott technológia és/vagy módszertan ismeretét és használatát igazolják. A tesztelés jellemzően a szoftverfejlesztésen belüli feladatként jelent meg, ahogyan azonban elkezdett önálló tevékenységként is erősödni, felmerült az igény a területen szerzett tudás és tapasztalat széles körben elfogadott igazolására. Jelenleg az ISTQB talán az egyik legismertebb, a szoftvertesztelés területén nemzetközileg is akkreditált minősítéseket kiállító szervezet, amely a tesztautomatizálással kapcsolatban is megfogalmazott egy egységes elméleti anyagot. A probléma, hogy hogyan tudunk egy erősen elméleti képzést, képesítést a gyakorlatban hasznosítani?

A cikksorozatban szeretném bemutatni a tesztautomatizálást, közelebb hozni az olvasóhoz ezt a számomra igen kedves határterületet! Az általános ismeretterjesztésen kívül, be fogok mutatni olyan cégen belül is használt technológiákat és megoldásokat, amelyekkel a mindennapokban hozzáteszünk egy-egy projekt haladásához.

Az International Software Testing Qualification Board (magyar szervezete a Hungarian Testing Board) elsősorban a tesztelés elméleti részét hivatott összefoglalni olyan módon, hogy az évtizedek alatt felgyűlt tapasztalatokból összeállítottak egy széles körben elfogadott fogalomtárat és módszertani vezérfonalat.

Ennek megfelelően elsőre rendkívül száraz anyagokkal találkozik az ember, azonban az egyes alapelvek és módszerek sokat hozzátesznek egy tesztelő munkájához – gyorsan azonosíthatóvá válik egy-egy tankönyvi alaphelyzet a projekt munkájában, jelentősen hatékonyabban tudunk tervezni. Egy bonyolult rendszer esetén rendkívül fontos a helyes modellalkotás, egy elsőre átláthatatlannak tűnő folyamat-háló jobban kezelhetővé válik, ha le tudjuk bontani a megfelelő egységekre, miközben a tesztjeink minősége is megfelelő marad.
Ebben a cikkben szeretnék példát hozni ezekre a tesztelési alapelvekre, röviden illusztrálni  őket, illetve bemutatni a tesztautomatizálásra vonatkozó értelmezésüket! Így jobb képet kaphatunk arról, hogy a mindennapi munkában hol jelennek meg, illetve egy ilyen minősítéssel rendelkező munkatárs vagy jelölt esetén is releváns információnk lehet a munkamódszerről.

Az egyik első alapelv, hogy a kimerítő tesztelés nem lehetséges. A komplexitást figyelembe véve egyszerűen nincsen értelmezhető lehetőség arra, hogy ténylegesen minden egyes sor kódot, logikai utat, előállítható kondíciót teszteljünk. Az üzleti oldal által megjelölt rizikók és a közösen megfogalmazott prioritások fényében kell a megfelelő teszt-lefedettséget elérni. Erre egy kitűnő megoldásnak ígérkezik a tesztautomatizálás, hiszen ha sokkal gyorsabban és automatikusan futtathatunk teszteket, akkor előállítható a teljes lefedettség. A tapasztalat viszont azt mutatja, hogy nem lehet mindent automatizálni és nem is kell mindent automatizálni. Az elsődleges cél pontosan a „kimerítő” tesztelés megszüntetése, vagyis a tesztelők által végzett monoton és rendszeres feladatainak átvétele, a munkájuk támogatása. Egy jól kivitelezett automatizált regressziós tesztkészlettel és a manuális tesztelők proaktív, tapasztalat alapú módszereivel egy összességében magas szinten lefedett, a lehető legtöbb kritikus pontot érintő folyamatot tudunk létrehozni.

A tesztelés kontextusfüggő. Minden program esetén fontos mérlegelni, a tervezett felhasználás ismeretében, hogy milyen területeket priorizáljunk. Teljesen más követelményeknek kell megfeleljen egy légiirányító program és egy kisvállalkozás tájékoztató weboldala, valószínűleg egészen eltérő erőforrás kerül mozgósításra a két esetben. A személyes elfogultságomat félretéve, a tesztautomatizálás első és legfontosabb kérdése: kell ez nekünk? Főleg egy már régebb óta futó projekt esetén kiemelt jelentősége van az előzetes vizsgálatnak, hogy rendelkezésre áll-e kellő erőforrás a kivitelezésre és összeségében megéri-e a befektetés. Kis komplexitás és alacsony rizikó esetén a minőségbiztosítás agilis tesztelőkkel együtt működik legjobban, de ahogy egyre több tesztelési folyamat jön létre, érdemes később újra megvizsgálni az automatizálás létjogosultságát. Több projekten tapasztaltam, hogy külső utasításra kezdtek el automatizált teszteket megrendelni akkor is, ha a projekt maga nem igényelte vagy maguk a folyamatok nem voltak automatizálhatóak – sajnos ilyenkor könnyen keserű szájízzel válik el a két fél, fontos az előzetes tervezés és az objektivitás. Ugyanakkor ha már a tervezési szakaszban szempont a tesztelés és van lehetőség automatizálással is kalkulálni, akkor nagyon hatékonyan lehet kialakítani a minőségbiztosítást, eleve úgy, hogy mindenki a legalkalmasabb területen dolgozzon.

A tesztelés csak a hibák jelenlétét mutatja. Kifejezetten az automatizálás területén, csak azokat a hibákat tudjuk megtalálni, amelyeknek az észlelésére felkészítjük a tesztjeinket. A legtöbb keretrendszer tudja kezelni, „el tudja kapni” azokat a váratlan hibákat, amelyek a tesztfutás közben előfordulnak, ugyanakkor az ellenőrzőpontokat és feltételeket nekünk kell meghatározni. Csökkentjük a nem-megtalált hibák valószínűségét, de a triviális kivételek kivételével (pl. szerverhiba miatt nem betölthető az oldal, lefagy a számítógép), a pozitív feltételek mellett definiálnunk kell az adott hibát is. Ez a gyakorlatban azt jelenti, hogy általánosan az automatizált teszt része a funkció, ami bármilyen váratlan hiba esetén képernyőképeket készít, illetve az ellenőrzőpontokon a rendszer különböző állapotának megfelelően szöveges üzeneteket ír az elkészülő report-ba.

A hibák hiányának téves észlelése. Ez a nehezen fordítható alapelv (absence-of-errors fallacy) arra utal, hogy önmagában az összes hiba megtalálása és kijavítása nem feltétlenül eredményez használható szoftvert. Egy sarkított példa, hogy ha a könyvelést vezető program számok beírása után lefagy, ezért kijavítjuk és csak szövegesen leírva lehet számjegyeket tárolni, akkor a program hibátlanul, de minősíthetetlenül fog működni.

A tesztautomatizálásra fordítottan értelmezve is megállja a helyét, a hibák meglétének téves észlelése is problémákhoz vezethet egy projekt munkájában. Jellemzően egy rendszer teljesítményében vehetünk észre olyan hibákat, amelyek egy automatikus teszt futása során hibát jelenthetnek, de a valós ügyfél általi felhasználásban nem zavaróak. Fontos meghatározni például az egyes weboldalak betöltésének maximális idejét, így ezekkel a tesztekkel is releváns problémákat tudunk jelezni.

Felhasznált irodalmak:

Software Testing – An ISTQB ISEB Foundation Guide (Brian Hambling)

www.istqb.org

Bemutatkozik: Kocsis Zoli

Ismerjétek meg Kocsis Zoltán kollégánkat egy rövid interjún keresztül.

Szuper helyezést értél el többször is Magyarország legnagyobb onlineinformatikai versenyén, Angular frontend fejlesztés kategóriában. Legutóbb például a 346 induló versenyző közül, tied lett az előkelő 15. helyezés.  

    • Tervezel még indulni?

Kétszer is indultam és szerencsére mindkétszer sikerült jól szerepelnem a versenyben. Az még kérdéses számomra is, hogy fogok-e a jövőben is indulni. 

    • Ha egy teljesen laikusnak össze kellene foglalnod röviden a frontend lényegét, mit mondanál?

Legegyszerűbben talán azt, hogy minden, amit a böngészőben lát a felhasználó és amivel interakcióba tud lépni. A weboldalak, webalkalmazások megjelenése és működése. 

    • Általában a megjelenés vagy a működés a hangsúlyosabb rész?

Ez nagyban függ az elvégzendő feladattól, de a munkám során elég komplex webalkalmazásokon kell dolgoznom és azt mondanám hogy kb.: 60%-70% JavaScript (/TypeScript), 15% Html, 15% Css (/Scss). 

    • Téged leginkább mi vonz a frontend fejlesztésben?

Tetszik, hogy látom, átlátom egy-egy ilyen alkalmazás működését, megérthetem jobban a webes világot, mivel ez ma már jóformán megkerülhetetlen. Ott van velünk a mindennapokban. 

    • Munka után mi jelenti számodra az igazi kikapcsolódást?

Nagyon szeretek barkácsolni, ebben is meg tudom találni a kreativitást, ahogy a munkában is. Élvezem, ha sikerül egy bonyolultabb szerkezetet építenem. De például egy tolókapu készítése vagy egy kis térkövezés is jó kihívás volt számomra. 😊 

Jó megoldások home office-on innen és túl

A beilleszkedés időszakában személyes, irodai, „együtt dolgozós” időt biztosítani.  Applikációt is vehetünk már az „onboarding” személyesebbé tételéhez! Bármilyen jól szabályozottak is a folyamatok, nem fedik le teljesen azt, hogy a munkavállaló megtanulhassa: mi így dolgozunk, így közelítjük meg a problémákat, így kommunikálunk egymással, a vállalati kultúránk hogyan mutatkozik meg a mindennapokban.

Soft skillek egyre fontosabbá válnak. Az a jó hír, hogy a soft skillek tanulhatóak, fejleszthetőek!

Már a kiválasztásnál célszerű tudatosan egyre több figyelmet fordítani a soft skillekre a szakmai tudás mellett. Hiába a szakmai tudás, ha a csapat munkáját megnehezíti egy kolléga.

 Képzések szervezése a meglévő munkatársaknak, nem csak a time managementről, hanem a konfliktuskezelésről, a burnout elkerüléséről, a kommunikációról, work-life balance-ról és a relaxálásról. Sok helyen ezt rendszeres csoportfoglalkozás keretén belül oldják meg.

 A kölcsönös bizalom nagy kincs a munka világában (is).

Az elköteleződés, az, hogy gyorsan és hatékonyan oldjunk meg krízishelyzeteket, konfliktusokat, hogy csapatként működjünk – mindez lehetetlen bizalom nélkül. A közös, nem a munkához kötődő tevékenységek csodát tesznek ezen a téren.

Olyan ötletekről hallok mostanában, mint borkóstoló estek, sörözés, grillezés, jótékonysági, segítő munka együtt, sport, vetélkedő délutánok.

 A „wellbeing” fontossága, felértékelődése, az eddigi hagyományos cafetéria juttatások mellett megjelenő új lehetőségek:

  • masszázs a munkahelyen
  • jóga, pilates órák az irodában
  • vagy akár, hogy a munkavállalók már személyes, független life coach-ot választhatnak, amelyet a cég támogat

Az „új normál” fontos lehetőség a fejlődésre.  Lehetőség arra, hogy ne egy újrahasznosított múltból építsünk jövőt magunknak. Lehetőség akkor, ha észrevesszük, hogy már nem játszhatunk a régi szabályok szerint.  Az „új normál”-ban fontosabb az, hogy jól csináljuk a dolgokat, mint az, hogy engedjünk a sürgősség noszogatásának.