Bevezetés
Először is tisztázzuk, mi érték az ügyfélnek? Az, hogy ha a felület, amin a felhasználók kapcsolatba lépnek a cégével, hibátlanul működik. Éles működés esetén ez egy alapvető dolog, nem lehet kérdéses. Fejlesztés során is sok esetben ez határozza meg a prioritást. Emellett egy fejlesztés során nem szeretné, ha sok új hiba kerülne elő már letesztelt, átadott funkciókban (ezt hívjuk regressziós hibának) mivel ez előre nem tervezett költséget, és időbeni csúszást jelent. Hogyan szeretné ezt elérni? Teszteléssel, ez mára már szintén alapvetés helyesen. Innen egy következő lépés az ügyfél szemében, ha ezt a tesztelést automatizáljuk. Hiszen, ha automatizált a tesztelés, akkor több hibát tudunk kiszűrni, kevesebb erőforrással, igaz? Rövidtávon nem igaz, hosszútávon igen.
Tegyük fel, hogy megérkezik Automatizáló Antal, a projektre, és várja a feladatot. A megrendelő szemében a felület működése teremt értéket, ezért ennek fényében adja ki a feladatot. A felületen keresztül valós folyamatokat szeretne tesztelni, ezeket szeretné legelőször automatizálni. Teljesen jogos, hiszen neki ez az érték.
Mit mond a szakember? Hogy felületet automatizálni sok idő, átfogó keretrendszer építésével lehet leghatékonyabban megoldani. Ez időbe kerül, illetve magát a fejlesztést is befolyásolja. Ezzel szemben, ő inkább automatizálna API-kat. Viszont azt a megrendelő nem érzi értéknek, akkor minek csináltatna ilyet?
Nézzük meg a felületi tesztek automatizálását
Amikor elkészül egy adott funkció specifikációja, azon jóesetben párhuzamosan elkezd dolgozni a fejlesztő, vele együtt pedig a tesztelő is elkezdi a funkció manuális teszttervezését, megírja a teszteseteket, tesztadatokat gyárt, meghatározza a tesztelési körülményeket. Ez azt eredményezi, hogy amint a fejlesztő kész van a funkcióval, és kitelepíti azt a tesztkörnyezetre, a tesztelő már egy előre meghatározott terv alapján tud dolgozni, és csak a tesztfuttatási idő telik el aközött, hogy telepítettük, addig, hogy tudjuk, van e hiba a funkcióban.
Ez az automata tesztek fejlesztésénél is így van… Így van?
Igen, és nem. A specifikáció legtöbb esetben nem tartalmaz minden információt, amire a felületi automata tesztek elkészítéséhez szükség van, ezek a fejlesztés folyamán véglegesednek. Így gyakorlatban, bár a tesztesetek készen állnak arra, hogy automata teszteket „fejlesszünk” belőlük, csak a megvalósítás, és kitelepítés után fogjuk tudni implementálni az adott tesztet. És ez az idő a döntő faktor, hiszen, időbe telik automatizálni egy új fejlesztést, és akkor fejlesztés közbeni regresszióra valószínűleg kevésbé lesz alkalmas, hiszen mindig lemaradásban vagyunk a manuális teszteléshez képest.. Összegezve, minél több időbe telik egy adott teszt automatizálása, annál később fogjuk tudni futtatni, illetve ezzel együtt annál később fogja javítani a programunk minőségét.
Felületi tesztek helyet
Mit ajánlunk? Ne felületet automatizáljunk, hanem API-okat. API-t automatizálni sokkal gyorsabb, olcsóbb, és az üzleti logika nagy részét ugyanúgy le tudjuk vele fedni. Túl szép, hogy igaz legyen? Nyilván nem ilyen egyszerű, de nézzük meg mélységében.
Mi az API? Az API egy közvetítőréteg a felület (Frontend), és a feldolgozást végző réteg (Backend) között. (Van ahol REST/API-ként hivatkoznak rá, de jelen cikk igaz a SOAP, és MQ kapcsolatokra is). Lényegében, amit felületen felvisz a felhasználó adatot, az mind egy API üzenet formájában fog eljutni a Backend, és az adatbázisok irányába.
Akkor ez azt jelenti, hogy az API-k tesztelésével kiváltható a felületi tesztelés? Igen, és nem. Az adatbevitelek, folyamatok tekintetében csak és kizárólag API tesztre hagyatkozva 100% os lefedettséget érhetünk el. Viszont vannak funkciók, amiket frontenden valósítunk meg, pl felületi validációk, különböző animált funkciók (pl információs doboz, ami egér jelenlétére jelenik meg) amik mind fontos részei a végleges rendszernek, és ezért üzleti értékkel bírnak a megbízóinknak.
Néhány üzletileg fontos funkció is csak a felületen van leprogramozva. Gyakran alkalmazott felületi logika, hogy egy értéktől függően változik a beviteli form. (Például az országválasztó után, az ország megyéi látszódnak csak egy legördülőben.)
Példa
Bár látjuk, hogy a felületen szoktak megvalósítani üzleti logikálkat, de miért ajánlom mégis, hogy első körben ne a felület automatizálását helyezzük prioritásba?
Egyrészt az üzleti logika nagy részét nem a felület tartalmazza, hanem a backend, másrészt nézzük meg egy egyszerű példán, hogy hogyan néz ki egy felületi tesztautomatizálás és ugyanennek az API-s tesztelése.
Az alábbi példában bemutatok két Robot Framework nyelven automatizált tesztesetet. (Csak egy minta kódot mutatok, nem konkrét oldal tesztjét). Mindkettő ugyanazt a funkciót teszteli, egyik felületen keresztül, a másik azon az API-n keresztül, amit az adott felület meghív, amin keresztül az adatokat feldolgozásra továbbítja. Tehát üzleti-, és funkcionális szempontból is egymással megegyező tesztekről van szó. Természetesen ezek nem teljes tesztesetek, például ellenőrzések, validációk nincsenek benne, amik egy valós tesztben bele kell, hogy kerüljenek. Az első, felületen keresztül végzi el egy regisztrációhoz szükséges adatok megadását, a második ugyanezt API hívással.
Két dologra szeretném felhívni a figyelmet. Az első, hogy a felületi automata teszt hosszabb, több ellenőrző lépést, utasítást tartalmaz (Meg kell győződnünk róla, hogy az adott elem megjelent, kattintható, mielőtt adatokat írunk bele). Ez is mutatja, hogy hosszabb idő elkészíteni egy ilyen tesztet, de a második szempont még inkább kiemeli.
Ha megnézitek, minden egyes adatbevitel, és interakció (kattintás, adat beírása, stb) objektumának van egy úgynevezett „locator”-a. Ez határozza meg, hogy pontosan hol, és hogyan találja meg az automata teszt az objektumot az oldalon. Ezek a locatorok szinte sosem szerepelnek a specifikációban, ezeket a fejlesztés folyamán dolgozza ki a fejlesztő. Éppen ezért, ezeket felkutatni mindig manuális, és elég hosszadalmas, pepecs munka. Ezt könnyítheti meg, ha eleve automatizálásra gondolva írják a frontend fejlesztők a felületet. Ebben az esetben, egységes elnevezés sablont használva, ez a hátrány minimálisra szorítható vissza.
Nem akartam azzal bizonyítani igazamat, hogy a felületi tesztet túlbonyolítom, így egy olyan oldalt használtam alapul, ahol az egyes felületi elemek (frontend component)-eknek van egyedi azonosítójuk, és egységes nevezéktannal rendelkeznek. Ha erre a két tulajdonságra figyelünk a felületünk implementálása során, azzal már sokat könnyíthetünk az automatizáló kolléga munkáján, így gyorsabb, stabilabb automata tesztjeink lesznek.
Viszont még ha egységesen, és emiatt relatív könnyen megtalálható lokátorokat használunk akkor is fennáll a veszély, hogy bármilyen módosítás esetén „eltörik” a teszt, nem fog rátalálni egy objektumra, és így fals negatív teszteredményt fogunk kapni.
Az API-ok egy fejlesztés folyamán ritkábban változnak, ennek ellenére változtatások eredményeképpen ezek is el tudnak romolni. Mivel viszont az API funkciók leírói szinte mindig (90%) része a specifikációnak, így azokat egyenesen a specifikációból lehet frissíteni, annak változása esetén akár azonnal. Emiatt, az API teszteket akár a fejlesztéssel párhuzamosan is megírhatjuk, míg a felületi teszteknél a tapasztalat azt mutatja, hogy meg kell várni a tesztkörnyezetre való telepítést, és csak utána tudjuk pontosan meghatározni a lokátorokat, megírni az automata tesztet. Így a felületi tesztautomatizálás időbeli lemaradást fog eredményezni.
Időbeli erőforrás alakulásának összehasonlítása
„Sima” sprint
Az első képen egy klasszikus sprint idővonalát rajzoltam fel. Specifikáció után indul a sprintünk, implementálással párhuzamosan zajlik a teszttervezés, majd implementálás után tesztelés, hibajavítás, és az így elkészült csomagot adjuk ki release-re.
Sprint felületi tesztautomatizálással
A második képen hozzávettem még felületi automatizálást is. Amint láthatjuk, mivel a felületi teztekhez szükséges információk egy része az implementáláskor véglegesedik, ezért később kezdhetjük el a tesztek készítését. Emiatt az adott sprint tesztjei már csak akkor fognak elkészülni, és futtatásra kerülni, amikor már letelt a sprintünk, tehát az automata tesztelés ilyen esetben egy sprint lemaradásban lesz.
Sprint API automatizálással
A harmadik képen API teszteket automatizálunk. Mivel a specifikációból kiderül minden információ, ezért már a manuális teszttervezéssel párhuzamosan készítheti az automatizáló kolléga a teszteket, és implementáció után, futtathatóak is. Ebben az esetben optimistán jeleztem, hogy a manuális tesztelőknek még egy rövid felfedező jellegű regressziós tesztelésre is marad/maradhat ideje, ahol azokar a felületi elemekre koncentrálhatunk, amiket az API teszteléssel nem tudunk tesztelni, ezzel csökkenthetjük a regressziós hibák számát.
Mit tanácsolunk?
- Új funkciót mindenképpen tesztelj manuálisan. Az automata tesztelés nem váltja ezt a lépést ki.
- Prioritásban helyezd előre az üzleti logikát tesztelő API tesztek automatizálását
- Fektess le szabályokat a specifikációkra vonatkozólag, amivel elősegíted a felületi automatizálást
- Ha ezek megvannak, automatizáld le azokat a felületi teszteket, ahol az API tesztek nem fedték le a számodra fontos funkciókat.
Köszönöm, hogy elolvastad, remélem hasznosnak találtad.
