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.
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