Tesztautomatizáló eszközök kiválasztása

Hogyan válasszunk automatikus eszközt a projektjeinkhez? Mennyire van megkötve a kezünk a különböző fejlesztési keretrendszerek használatával? Lehetséges, hogy több eszköz között kell döntenünk. Mindenképpen csakis függettlen forrásból származó véleményt vegyünk figyelembe a döntésünk meghozatalánál. Ha nem tudunk választani, az lesz a legjobb, ha mindegyik eszköznek adunk egy esélyt… 

Évekkel ezelőtt, 1999 tájékán írtam egy cikket a GUI automatizáló teszteszközökr ől. Nemrég kaptam egy e-mailt valakitől, aki olvasta a cikket, melyben segítséget kért tőlem a kiértékeléssel kapcsolatban. Mivel úgy éreztem, válaszom mások számára is hasznos lehet, így írtam a témáról még egy cikket. 

Sok idő telt már el az előző értekezésem óta, mely idő alatt rengeteg minden változott ebben a témában, így ez alkalommal más oldalról közelíteném meg. Hiszen napjainkban jóval több lehetőség áll rendelkezésünkre, mint akkoriban, és számuk minden egyes nap elteltével egyre csak nő. 

1999-ben megalkottam egy hatékony kiértékelési folyamatot, közreműködtem vállalatoknál üzleti eszközök kiválasztásában, és idővel beigazolódott, hogy az ebbe fektetett rengeteg idő és pénz nem volt hiábavaló. Ugyanis túl nagy ára lett volna egy elhibázott döntésnek. 

Elvégre, minden kiválasztott eszközhöz licencet kellett vásárolni, melyek az eszközök cseréjével újbóli megvételre kerültek, míg a régiek feleslegessé váltak, ennek finanszírozása azonban nem volt sem olcsó, sem megengedhető. Ezt a költséget csak fokozta az a tény, hogy az egyes rendszerekre írt tesztek más rendszerekkel inkompatibilisek voltak, így ezeket sem lehetett tovább használni az új eszközökkel. Amikor tehát új eszköz bevezetésére került sor, az pontosan azt jelentette, hogy a régit minden hozzákapcsolódó fejlesztéssel együtt ki kellett dobnunk. Mindezek tudatában, hónapokban volt mérhető az az idő, mely alatt megtaláltuk a legmegfelelőbb eszközöket, egyben az értelmét a 8 számjegyű beruházásoknak. 

De mára a piac megváltozott, a nyílt forráskódú eszközök felülmúlják a kereskedelmi (fizetős) eszközöket, emellett a licenceket is el lehet felejteni. Persze a kereskedelmi eszközök is szép számmal jelen vannak, a dolog viszont annyiban változott, hogy ma már előbb kezdek el keresgélni a nyílt forráskódú eszközök között, és csak ezután nézem meg a fizetősöket. 

Most pedig a cikk azon pontjához érkezett az olvasó, melyben útmutatást kap az eszköz- kiválasztással kapcsolatban. Ha olyan eszközt szeretnénk, amely képes funkcionális tesztek automatizálására (ellentétben a unit teszteléssel), mindenképpen szükség lesz egy keretrendszerre és egy driver-re. 

A keretrendszer felel a tesztek formai meghatározásaiért, kapcsolatot teremt a tesztek és a tesztautomatizáló kódok között, végrehajtja azokat és jelentéseket készít az eredményekről. 

A driver az interfész manipulálásáról gondoskodik. 

Példának hoznám fel a saját projektemet, az www.entaggle.com-ot, melynél a Cucumber keretrendszert és a Capybara driver-t használom. 

Az, hogy melyik keretrendszert milyen driver-ekkel használjuk, a saját döntésünk. 

Térképezzük fel a szóba jöhető keretrendszereket!

Tesztek formátuma

Az első dolog amely fontos lehet a választás során, az a nyelvi támogatás a tesztek kifejezésére vagy a kódírásnál. (pl.: angol) 

Ez a választás az egész csapat munkáját befolyásolja, nem kizárólag a programozókét és tesztelőkét, mivel minden olyan embernek, aki részt vesz a projektben, képesnek kell lennie legalább a funkcionális tesztek értelmezésére. 

Ha sikerült ilyet találnunk, akkor készen is lennénk, mivel a keretrendszer eleget tesz a követelményeinknek. Összefoglalva a funkcionális teszteléshez választott keretrendszernek olyannak kell lennie, amely olyan tesztformátumokat támogat, amellyel együtt tud dolgozni az egész csapat. 

Tehát ahelyett, hogy megpróbálnánk kitalálni, hogy mi lehet az, amit az érdekeltek látni szeretnének, inkább kérdezzük meg őket. Minden ilyen esetben kérjük ki a vállalati szféra véleményét, és alaposan győződjünk meg arról, hogy megfelelő lesz-e az adott környezet számukra, nem pedig presztízsből mondják rá azt, hogy jó lesz. Erre egy jó módszer lehet, ha szembesítjük őket egy kóddal vagy kódrészlettel, és felmérjük, mennyire értik annak lényegi részét. Amennyiben azt tapasztaljuk, hogy nehézséget jelent ez számukra, gondolkozzunk el egy másik keretrendszer alkalmazásán. 

Ne feledjük el, attól még, hogy nem kódokat, hanem kifejezéseket használunk a tesztek megírásához, nem lesz semmivel sem butább a rendszer, csupán áthidalja és egy szintre emeli a fejlesztők-tesztelők és a laikusok munkájának gyorsaságát, így ez előny lehet, nem pedig hátrány. 

Mikor ezeket magyarázom másoknak, néha megkérdezik tőlem: 

“Ok, rendben, de melyik az a tesztautomatizáló eszköz, aminek a használatát a LEGEGYSZERŰBB megtanulni? ” 

Általában Ők a “Legegyszerűbb” alatt a “felvétel-lejátszást” értik. 

Az ilyen típusú és logikájú rendszerek választása igen hívogató lehet, de ez a könnyedség olykor a fejlesztés falakba ütközését jelentheti, amelyet gyakran nem lehet áttörni. Minden ilyen keretrendszer rendelkezik felvétel-lejátszás (makró jellegű) lehetőséggel, ám ezek nem mindig nyújtanak átfogó megoldást az adott problémára, így célszerű olyan rendszert választani, amely ezek mellett más lehetőségekben is bővelkedik. 

Tehát a nyelvi kifejezésekkel írt tesztek az együttműködésben segítenek. De láttam már olyan Java-ban és JUnit-ban írt elfogadási teszteket Selenium alatt futni, melyek ugyancsak az együttműködést biztosították. A lényeg az együttműködésben, nem pedig a teszt formátumában van. 

Az viszont tény, hogy vannak előnyei annak, ha a teszteket kódokkal fejezzük ki. 

Hogyha ugyanolyan keretrendszert alkalmazunk a unit és a funkcionális tesztelésre, akkor az absztrakciós réteget ki tudjuk iktatni, így csökkentjük a bonyolult tesztek komplexitását a szakavatott emberek számára, így könnyebben tudnak teszteket írni és gyorsabban tudják frissíteni azokat. 

Számtalan példát láttam arra, hogy Javával dolgozó rendszerekkel előbb érték el ezt, mint az angol nyelvet használó rendszerekkel.

A programozási nyelv

Következő szempont a kódgyártás nyelve.

Nyelv	Nyelvi kifejezésket támogató rendszerek	Kód alapú rendszerek
Java	Robot Framework, JBehave, Fitnesse, Concordion	JUnit, TestNG
Ruby	Cucumber	Test::Unit, RSpec
.NET	Specflow	NUnit

Az idő múlásával, ahogy említettem, temérdek eszköz áll rendelkezésünkre, és még távolról sem értünk a lista végére. Még sok más eszköz szerepel az AA-FTT táblázatában. () Az AA-FTT az Agile Alliance Functional Testing Tools csoport. Ez egy programja az Agile Alliance-nek. A táblázatban a csoport tagjainak tudása szerepel. Emellett segítséget kérhetünk az AA-FTT mail listán is (http://tech.groups.yahoo.com/group/aa-ftt/). 

Szóval, miért is vegyük fontolóra a kódgyártás nyelvét? Én annak a híve vagyok, hogy törekedjünk egy olyan rendszer választására, mely lehetővé teszi, hogy a teszt megírásához az automatizáló kódot és a gyártási kódot is ugyanazon a nyelven írjuk. Okai:

• A programozók már ismerik a nyelvet. Ez egy óriási áldás, így könnyen be tudnak kapcsolódni a funkcionális tesztek automatizálásba.
• Talán egy igazi programozási nyelv, amely támogatja az automatizált újraszervezést és más hasznos dolgokat. Az automatizált tesztkódok fenntarthatósága érdekében igyekezzünk megszüntetni a duplikációkat és szilárdítsuk meg az addigi elveket.
• Ez növeli annak a valószínűségét, hogy képesek legyünk megkerülni a GUI paraméterezését különböző feltételekkel és adatokkal. Számos esetben használhatjuk a unit teszt kódjait a funkcionális tesztelésnél. Pl.: Megoszthatjuk az adatokat generáló kódjainkat a unit tesztek és az elfogadási tesztek között, mellyel ismét csak csökkennek az erőforrás igényei az automatizált tesztek létrehozásának és fenntarthatóságának.

Az ökoszisztéma

Ha már eddig a keretrendszerről beszéltünk, érdemes belegondolni abba is, hogy milyen környezetben kell működnie az adott rendszernek. Azt tudom tanácsolni, hogy mondjunk le az olyan rendszerek használatáról, melyek nem képesek együttműködni az adott forráskódkezelő rendszerünkkel (SCM), a buildelő folyamatunkkal vagy a folyamatos integrációt biztosító rendszerünkkel (CI). Amennyiben ezek zökkenőmentesen zajlanak, úgy megtaláltuk a megfelelő rendszert.

Driverválasztás

A driver csak egy könyvtár, amely tudja, hogyan manipulálja a tesztelendő interfészt. Lehet, hogy nem csak egy driver-re lesz szükséged, ez annak a környezetnek a függvénye, amelyben tesztelsz. Lehet, hogy külön kell egy driver a webes alkalmazásokhoz és ezen felül kell még egy a Windows-os alkalmazásokhoz is. 

Ne feledjük, hogy milyen csodálatos dolog, hogy napjainkban ilyen eszközök állnak rendelkezésünkre, és igyekezzünk kihasználni az ebben rejlő lehetőségeket. 

A driver-ek kiválasztásánál vegyük figyelembe a technikai hátteret is. Nehéz jó tanácsot adni ezen a téren, mivel én is csak azokról az eszközökről tudok véleményt mondani, amelyeket már ismerek, ám ennél jóval több létezik. Mostanában webes alkalmazásokkal dolgozom, így a Selenium / WebDriver-t használom. 

Egy driver kereséséhez használhatod az AA-FTT táblázatot, vagy a kérdezhetsz a levelezési listától is.

Kísérlet

Ne aggodalmaskodjunk sokat azon, hogy milyen eszközöket választunk. Mérlegeljük, melyek felelnek meg az általunk megjelölt kritériumoknak, és melyek azok, amik a gyakorlatban sem okoznak csalódást. Leginkább úgy tudjuk megtenni ezt, ha kipróbáljuk magukat az eszközöket. Ez manapság már nem jelent akkora költséget. 

Mégis hogyan lehetséges ez? Először is, sok cég gondolja úgy, hogy a licenc költség nem probléma a nyílt forráskódú eszközök miatt. Ha ezek között a rendszerek között történik a váltás, akkor nagyobb arra az esély, hogy a tesztek a másik rendszerrel is együtt tudnak működni, akár egy kis változtatás árán is. 

Így bátran kísérletezhetünk anélkül, hogy ez pénzbe kerülne. Bárhogy is döntünk, ne gondolkodjunk rajta hónapokig, hogy melyiket válasszuk, inkább kezdjünk el dolgozni az egyikkel. Tudvalevő, hogy a tapasztalatszerzés jobb az elmélkedésnél. 

Végezetül, ha egy nagyobb cégnél dolgozunk, problémát jelenthet a teszteszközök sokszínűsége is. Ebben az esetben érdemes csökkenteni az eszközök számát, ami az egyes munkatársak számára is áttekinthetőbbé teszi a rendszert. De legyünk óvatosak az azonnali szabványosítással és legyünk figyelemmel a kiválasztásnál. Volt rá példa, hogy az egyik nagyvállalat egyetlen, egyszerűbb eszközt választott a gazdaságosságra hivatkozva. Ez lehetővé tette a képzés egységesítését is. Azonban a nyílt forráskódú rendszerek világában a gazdaságosság és a használhatóság nem mindig van egyenes arányban. Inkább a problémákra keressünk külön-külön megoldást az általánosítás helyett. Az eszközválasztásnál tehát egyszerre kell nézni a megtérülést és a hatékonyságot. 

Szintén érdemes megjegyezni, hogy a tesztelési keretrendszer egységesítése mellett legalább olyan fontos a driver-ek egységesítése is. 

A tanácsom, hogy minden esetben körültekintően járjunk el a tesztautomatizáló eszközök kiválasztásánál, mert már a szempontok mérlegelésénél bebiztosíthatjuk sikerünket egy adott projektben. 
Sok szerencsét és jó automatizálást…

Forrás:http://testobsessed.com/?s=automation&submit.x=0&submit.y=0

Szerző: Elisabeth Hendrickson