Tesztautomatizálás – ISTQB a gyakorlatban

Blog

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