Az eszköz kiválasztásánál is érvényesül az az alapelv, miszerint érdemes minél hamarabb megvalósítani a tesztelést is egy projekten. Már a tervezési fázisban el lehet kezdeni felépíteni egy tesztkészletet, illetve megvizsgálni a specifikációk és rizikók alapján, hogy milyen területeket kell majd mindenképpen tesztelni, melyek lesznek ezekből automatizálhatóak. Lényeges különbség lehet, hogy böngészőben futtatott webalkalmazásokról, asztali alkalmazásokról, esetleg mindkettőt érintő end-to-end tesztekről van-e szó.
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 asztali alkalmazások kezelése nem minden keretrendszerrel elérhető, ezt jellemzően a „nehézsúlyú”, különálló alkalmazások teszik lehetővé – például a Micro Focus (korábban HP) által fejlesztett Unified Functional Testing (UFT) vagy a Ranorex keretrendszer. Mindkettő drága enterprise program, azonban egy készen használható eszköz, ami akár felvétel-lejátszás módszerrel is képes nagyobb bonyolultságú és jobban paraméterezhető teszteket előállítani, mint például a szabadon elérhető Selenium IDE. További előnyük, hogy a böngészőn belül futó folyamatok mellett, a legtöbb asztali alkalmazás elemei is manipulálhatóak, meg tudunk valósítani akár több alkalmazáson át futó teszteseteket is. A keretrendszer által támogatott programnyelveken bővíthetjük, felülírhatjuk a meglévő funkciókat, megvalósíthatunk teljesen kulcsszó-vezérelt struktúrát (keyword driven testing – a tesztek olyan kulcsszavakból vagy akciókból épülnek fel, amelyek működését mi írjuk meg a kódban, és társítjuk hozzájuk a felhasználandó tesztadatokat).
Ha tisztán böngészőben futtatott webalkalmazásokról van szó, akkor kevesebb kötöttségünk van a keretrendszer kiválasztásában. Több ingyenesen is felhasználható, illetve open-source megoldás létezik, amelyek jellemzően a fejlesztés oldaláról közelítik a feladatot – a tesztek létrehozása sokkal inkább hasonlítható a klasszikus alkalmazásfejlesztéshez, mint mondjuk egy standalone framework esetén, ahol a program által biztosított grafikus felületen dolgozhatunk. Nekünk kell felépíteni a választott programnyelven és környezetben azt a megoldást, amit a tervezett tesztelési folyamat megkíván.
A következő
cikkekben konkrét példákkal szeretném illusztrálni, hogy a cégen belül jelenleg
milyen megoldásokkal, felhasznált eszközökkel dolgozunk!
A fő projektemen legnagyobbrészt a Ranorex-szel dolgozom, egy logisztikai területen lévő partner alkalmazását teszteljük, a nehézsúlyú megoldások egyik képviselője. Olyan feladatok teszik indokolttá a használatát, mint például böngészőn kívüli PDF fájlok ellenőrzése, letöltési és importálási műveletek. Bár a lehetőség adott, a fejlesztés során nem használjuk a record-and-playback eszköztárat, a teszteseteket keyword-driven módszer szerint definiált modulokból építjük fel. A tesztelt alkalmazás sajátos elemeinek és elemcsoportjainak kezelésére számos kiterjesztést fejlesztett a csapat, amelyekkel kiegészítjük a keretrendszer eszköztárát és egyes alapértelmezett műveleteket saját metódusokkal helyettesítünk. Az alkalmazások elemei egy hierarchikus struktúrában, webalkalmazások esetén a DOM (Document Object Model) szerint tárolhatóak, ami alapján hivatkozhatunk rájuk az egyes modulokból. A létrehozott C# solution jól kezelhető külső fejlesztőkörnyezetben is, Visual Studio segítségével végezzük a verziókezelést (git, korábban TFS rendszerben), illetve ezen keresztül tudjuk az Azure test plan elemeivel összekapcsolni az elkészült automatizált teszteket. A csoport CI/CD környezetében kezelve, minden este több, mint 450 automatizált teszt fut le, amivel gyors és rendkívül jó felbontású visszajelzést tudunk adni a fejlesztők felé, illetve támogatni tudjuk a manuális tesztelők munkáját is.
