Nagyságrendek a tesztautomatizálásban

Sok csapat fókuszál az automatizálásra úgy, hogy a lehető legegyszerűbb megoldást próbálja, megkeresi az egész csapatnak a piacon elérhető eszközök segítségével. Egyeseknek ez csak egy csomó automatizált unit tesztet, míg másoknak GUI-szintű automatizált tesztekből épített hatalmas teszthalmazt jelent. Amíg a fejlesztők a mindennapi munkájukhoz hasonló automatizálást részesítik előnyben, addig a tesztelők azokat az eszközöket, amelyek közelebb állnak az ő normál rutinszerű teszteléseikhez. A legrosszabb lehetőség, ha egy csapat úgy lát hozzá az automatizálás megvalósításához, hogy megragadja a legközelebbi kalapácsot és jól meglengeti.

Ez biztosan jó szándékú, de az automatizálás adhoc megközelítése gyakran vezet hiányos lefedettséghez és nem túl hatékony végrehajtáshoz. Egyes tesztek előállítása és karbantartása drágább, mint kellene, mások pedig gyengébbek, mint a szükséges, mert a csapat az alkalmazás nem megfelelő szintjén hajtja végre ezeket a teszteket.

Következik egy heurisztikus megközelítés, hogy segítsen a különböző automatizálási nagyságrendek keresztezésén alapuló tesztelésed megsegítésén. Ez nem egy hatékonyságot mérő módszer. Inkább egy egyszerű szimat, ami megmondja, hogy mikor lesz szükséged egy kis plusz időre, hogy meggyőződhess róla, az automatizált tesztelési erőfeszítéseidet a megfelelő szintre koncentráltad-e.

A Tesztautomatizálás harminc másodperces összefoglalója

A legtöbb agilis csapatnál az automatizált unit tesztek használata bevált gyakorlat. Néhány csapatnál ez a szélesebb körű teszt-vezérelt fejlesztési módszer része. Ezek a tesztek gyakran az osztály-, és metódus-szintű aggodalmakra fókuszálnak, valamint a fejlesztés támogatására és nem feltétlenül azért futnak le, hogy alapos tesztelést végezzenek és megtalálják a problémákat.

A unit tesztek mellett, sok csapat automatizált elfogadási teszteket is kialakít. Ezek a tesztek gyakran az adott történet elfogadási feltételeihez vannak kötve egy adott iteráción belül. Néha unit teszteknek látszanak (gyakran nem mozgatják meg a felhasználói felületet), de hajlamosak inkább az üzleti szempont felé irányulni. Az automatizált elfogadási tesztek gyakran nem csak fejlesztők által készülnek, hanem párszor az aktuális felhasználók által (akár az ügyfél képviselője által), vagy a tesztelők által.

Mivel a fejlesztés alatt a termék növekszik, a csapatok időközönként másfajta automatizált teszteket fejlesztenek, ami egyre inkább hasonlít a hagyomány GUI-szintű tesztautomatizálásra. Ezek a scriptek a termék több területét fedik le és inkább a forgatókönyvre, mint konkrét történetre fókuszálnak. Sok esetben a fejlesztők és a tesztelők hozzák létre és tartják karban a teszteket.

Az automatizálás negyedik típusa idővel magától alakul ki: Scriptek halmaza a termék ellenőrzésére. Ezek lehetnek egyszerű ping-ek a termék környezetére, hogy megbizonyosodjanak arról, az alkalmazás működik és ésszerű időn belül válaszol. Lehetnek mélyre menőbb tesztek, melyek biztosítják, hogy a legalapvetőbb funkcionalitás, vagy a third-party szolgáltatások az elvártnak megfelelően működnek.

Például, ha én egy vasúti projekten dogoznék, elvárnám, hogy Rspec legyen a unit teszteknél, Cucumber a felhasználói elfogadási tesztekre, Selenium a GUI-szintű automatizálásra, és talán New Relic a termék monitorozásra. Egy Java környezetben valószínűleg Junit-hoz, Concordion-hoz, HP Quality Centerhez és OpenNMS-hez fordulnék. A specifikus eszközök nem annyira fontosak, mint az automatizálásra vetett fókusz.

Azonosítsuk, hol túl gyenge, vagy túl erős a lefedettség

A legtöbb csapat ritkán törekszik arra tudatosan, hogy egyensúlyba helyezze az automatizálási erőfeszítéseket a kiemelt területeken. Tapasztalataim szerint, amikor a csapat már öt főn felülire nő, nehéz együtt vitatkozni olyan tesztelési kérdésekről, mint az automatizált tesztek lefedettsége. Amikor a csapat összeül, gyakrabban fontosabb témáról van szó.

Hogy felvillanyozzunk egy beszélgetést az automatizált teszt lefedettség témájában, kidolgoztam a következő heurisztikát, hogy segítsen megtippelni, mikor kell odafigyelnünk arra, mit- és hogyan automatizáljunk. Ezzel gyakran felderítek egy sor hiányosságot. Speciális nagyságrendeket figyelek a tesztjeimben. Ideális esetben ezt látni:

• 1000 unit teszt
• 100 automatizált felhaználói eflogadási teszt
• 10 GUI-szintű automatizált teszt
• 1 termékmonitorozási script

Ezek a nagyságrendek mind relatívak. Ha van tízezer unit tesztem, akkor ezer automatizált felhasználói elfogadási teszttel számolok és így tovább lefelé. Ezzel szemben, ha csak 100 unit tesztem lenne, akkor nem számolnék többel, mint egy marék elfogadási teszttel és semmi mással. Ahogy az alapkód növekszik, a szükséges lefedettség érdekében a szükséges tesztek száma is növekedni fog, tehát a konkrét számok nem annyira fontosak, mint a relatív méretarányuk.

Néhány csapat számára, még mindig kérdőjeles, hogy az adott helyen, még ha meg is van ez a négy automatizálási típusuk, használhatóak-e. Nem ritka, hogy csak egy, vagy kétféle automatizálási típusuk van és a többit figyelmen kívül hagyják. Tapasztalataim szerint kevés az a csapat, amelyik a teljességre törekvően mind a négy területre egyszerre gondol. Amikor elkezded nézni ezeket a számokat, gyakran eszedbe jut a kérdés „Mennyi az elegendő?”, és „Ezek a tesztek éppenséggel mit tesztelnek?”.

Az automatizálásod egyensúlyba hozása

Úgy gondolom, hogy a nagyságrend egy nagyszerű témaindító, de ha egyszer a csapat a lefedettséggel kezdi a beszélgetést, a fókusz gyorsan a kódok, adatok, forgatókönyvek, vagy másféle lefedettségre irányul. Gyakran kezdjük a relatív mutatókkal: Mennyi ideig tart minden egyes teszt halmaz lefuttatása? Milyen gyakorisággal kell őket futtatni? Elkezdjük nézni a különféle típusú problémákat (ha vannak), amik a tesztekben megtalálhatóak.

A cél az, hogy az automatizálás felé tereljük a beszédtémát. Hogyan lehetséges, hogy 1000 GUI-szintű teszted van, de nincs egy automatizált elfogadási teszted sem? Valószínűleg a legtöbb hiba, ami megtalálható ezekkel a GUI-szintű tesztekkel, könnyedén megtalálható az elfogadási tesztek szintjén. Az elfogadási teszteket valószínűleg gyakrabban lehet futtatni és olcsóbb fenntartani. Ha nincs egy GUI-szintű teszted sem, akkor valóban lefeded a többivel a felhasználói felület funkcionalitását?

Ahogy elkezded azonosítani azokat a területeket, ahol túl gyenge, vagy túl erős a lefedettség – a heurisztika alapján – a következő lehetőségeket vedd figyelembe:

• Azok a területek, amiket teljes mértékben figyelmen kívül hagytál. Ezeknél érdemes elkezdeni felépíteni a lefedettséget.
• Azok a területek, ahol egy nagyságrend kiesett. Kérdezd meg magadtól miért. Vajon szándékos volt? Ezek a tesztek a megfelelőek? Ezen a területen túl erős a lefedettség, vagy a többi területen gyenge?
• A tesztek amiket „magasabb” szinten írtál (a felhasználói interface-hez közelebb), kiválthatóak és még eredményesebben kezelhetőek „alacsonyabb” szinten (közelebb a kódhoz).

Ahogy elkezded a hézagok és területek kijelölését – ahol túl gyenge, vagy túl erős a lefedettséged – vedd rá a csapat többi tagját is, hogy megvitassátok mi a legjobban járható út a probléma megoldására. Elképzelhető hogy a termék típusa miatt a heurisztika nem fog működni nálad. Nem probléma. Dolgozz együtt a csapattal, hogy kitaláljátok, milyen típusú mix lehet a legmegfelelőbb számotokra. Ezeket a számokat rengeteg tényező szerint lehet alakítani, a cél a jobb teszt automatizálás kialakítása, kidolgozása.

Forrás: http://www.agileconnection.com/article/orders-magnitude-test-automation?page=0%2C0

Szerző: Michael Kelly